Cisco PBR


Tagek: Linux, Cisco,
Írta: toshy
Publikálva: 2012-06-27 16:05:45





CISCO Policy Based Routing




Nem tudom követ-e még valaki, de bízom még a google kereső motorjában, és talán ide téved egy két érdeklődő ember, és kitudja még az is lehet, hogy érdemben segít nekik az alábbi esetem.

A téma: Transzparens proxy
Mindezt pedig: CISCO IOS, PBR, Squid3, Netfilter iptables, Virtualbox. Segítségével

A topológia:

A CÉL
Mint látjátok, a cél a következő. Client, erősen szegényes fantázia nevü kliens gép, ip címe 10.157.204.2, internetezni akar, és pedig a 83.33.44.11 -es IP című szerver gépen található web oldalt szeretné megtekinteni. Azt szeretnénk elérni, hogy ez sikerüljön is, de a proxy gépen található squid3 -as transzparens proxy közbeiktatásával.

Az infrastruktúra:
OS
  • 2600 Software (C2691-ADVENTERPRISEK9-M), Version 12.4(5a), RELEASE SOFTWARE (fc3)
  • A client egy MS Windows 7 -es gép.
  • A Proxy egy Debian Sarge
  • A Server egy Ubuntu 12.04 -es server edition.


  • Software
    A Kliens gépen egy firefox-ra lesz szükségünk, biztos hogy nem számít a verzió száma.

    A Proxy szerveren:
  • SQUID3 Version 3.1.6
  • Netfilter Iptables

  • Szerver gépen:
  • Apache 2


  • Nagyjából ennyire van szükségünk. GNS3-ban teszteltem, virtualbox-al.
    Szerettem volna qemu -s host-okkal, de GUI-ból nem indult el a qemu konzolja, és bár különböző tap interface-ekkel össze tudnám drótozni, de most nem akartam ezzel bajlódni. A virtualbox-os megoldás első katt-ra rendben volt.

    Szóval 2-interface-el telepítettem az adott Virtualboxos host-okat, és mindenhol a második interface-en állítottam be a topológiai rajzon található IP címet. Erre azért volt szükségem, hogy tudjak telepíteni bármit ha szükségem lenne az IRL internetről. Mint utólag kiderült, ez jól is jött.
    Természetesen nem kell ezt így csinálni, de nekem kényelmes volt. Miután felhúztam az interface-eket, és be állítottam az IP címeket, ellenőrizni kell a routing táblákat, hogy a kívánt útvonalaink arra mutatnak-e amerre mi szeretnénk.
    A Kliens gépen csak arra van szükségünk ezzel kapcsolatban, hogy egy 10.157.204.1 -es default gateway-t állítsunk be.
    Ezt beállítani grafikusan nem okozhat gondot.
    Az UA routeren, és az SA routeren egy Fastethernet0/0 -t

    ip route 0.0.0.0 0.0.0.0 Fastethernet0/0


    A CD-n sem sokkal bonyolultabb. Felvesszük a két hálózatot a 10.157.204.0-t, és a 10.157.214.0 -t.

    ip route 10.157.204.0 255.255.255.0 FastEthernet1/0
    ip route 10.157.214.0 255.255.255.0 FastEthernet0/1
    


    Természetesen az életben ez nem így nézz ki, ott már valami routing protokollt használnánk, RIP-et, vagy OSPF-t, vagy EIGRP-t, de most nem a routing protokollokat akarjuk tesztelni, vagy tanulni.
    Így a célnak tökéletesen megfelel a static routing.
    No ha ezekkel a beállításokkal megvolnánk, akkor teszteljük le. Ping-el tesztelünk először, hogy a connectivity, és a routing müködik-e. Pingeljük a cliensről előbb a default GW-t, majd a 10.157.200.2 -t, majd a 10.157.200.1-t, majd a 10.157.214.1, a 10.157.214.2, és legvégül a 83.33.44.11 -t.
    Ha mindenhol megjött rendben a válasz jók vagyunk a routing működik. Nekem sajnos GNS3-ban duplex mismatch-ek jöttek elő, így minden router-en kézzel be kellet ezt állítani, de utána működött minden korrektül. Szóval ezzel a részével kész volnánk.
    Telepítsünk Apache-ot, a szerver gépre, és Squid3-at a proxy gépre. Az apache web oldalát célszerű kicsit megmódosítani, nehogy máshol járjunk, és ne tűnjön fel, így írjunk a default index.html-be valamit, h1 -es header-ek közé, akár pirossal hogy „szúrja” a szemünket, hogy hol is járunk. Ha megvan, mindjárt próbáljuk is ki a kliens gép böngészőjéből ! Mennie kell.

    Ha működik akkor célszerű a szerver gép konzolján egy

    tail -f /var/log/apache2/access.log


    indítani, hogy nyomon tudjuk majd követni ott is, milyen IP címről érkeznek a kérések. Kész. Jöhet a squid. Telepítés után én megmondom őszintén csak annyit változtattam a dolgon hogy a http_port 3128 sorhoz hozzá adtam a transparent opciót.
    Tehát így nézet ki:

    http_port 3128 transparent


    Itt is lehet indítani konzolból ellenőrzés képen egy

    tail -f /var/log/squid3/access.log


    Ki lehet próbálni. A Kliens gépen állítsuk be a proxy gép IP címét proxy szervernek 3128 -as porton. Látnunk kell hogy ugyanúgy működik, de a szerveren az access log-ban már más IP cím kell szerepeljen, mégpedig a 10.157.214.2-s. A Squid access.log -jában is kell szerepeljen a bejegyzés. Ha működik állítsuk vissza a no proxy opcióra a böngészőt. Nem vagyunk még készen, hiszen ha a router ide a proxy szerverre fog irányítani minden web-es forgalmat, akkor az a 80 -as portra fog érkezni, és apache nincs is a gépen, de ha lenne sem tudná kezelni, 404 -es hibákat dobna, ha válaszolna egyáltalán.
    Tehát kell egy redirekt amit iptables-el oldunk meg, egy sor az egész:

    iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp –dport 80 -j REDIRECT –to-ports 3128


    Ha mindez megvan jöhet a PBR, vagyis a Policy Based Routing. A CD-n csinálunk egy access listát amibe én a következőket raktam:

    ip access-list extended web-traffic
      10 deny ip 10.157.214.2 any
      20 permit tcp 10.157.0.0 0.0.255.255 any eq www
    


    Tehát a proxy -ról jövő csomagokkal nem foglalkozzunk nehogy szép kis loop-ot kapjunk. A többi web-re irányuló kérést elkapjuk.
    Ezután kell a route-map:

    route-map proxy-redirect
      match ip address web-traffic
      set ip next-hop recursive 10.157.214.2
    


    Ha ez is megvan akkor tegyük rá az interface-re

    interface Fastethernet0/1
     ip policy route-map proxy-redirect
    



    Na én azt hittem , hogy itt kb ennyi, és működnie kell, majd szomorúan konstatáltam, hogy nem működik :(
    Leírom a hiba keresésem menetét, hátha valakinek az is segít.
    Szóval a routing működött, kipróbáltuk.
    A Proxy is működöt azt is kipróbáltuk, számomra egyértelműnek tűnt, hogy valamiért a PBR nem teszi a dolgát.
    Pedig de !

    Debug ip policy


    parancsra szépen nyomon követhető, hogy hány csomagot kapott el, azt simán „normal forward” -al továbbította, vagy redirect -et hajtott végre. Nálam szépen mutatta is, ezért kicsit elhűltem, hogy most akkor mi van ? Megvoltam róla győződve, hogy itt lesz a hiba.

    A Routing megy, a proxy megy, a PBR csinálja a dolgát.
    Az iptables packet counterre nem mutatta a csomagokat. Tehát vagy nem ért el addig, vagy pedig nem illeszkedett rá a netfilter szabály.
    Egyesével wireshark-al követtem nyomon a csomagokat, a következő sorrendben:

  • UA – Fa0/1
  • UA – Fa0/0
  • CD – Fa1/0
  • CD – Fa0/1
  • SA – Fa0/0
  • SA – Fa0/1

  • Innen nem mentem tovább mert nem jöttek a csomagok. Mint villámcsapás jött a megvilágosodás, hogy hát persze, a routerek a PBR folyamán nem írna át semmit a csomagban , csak át teszik egy másik interface-re, és a src valamint a dst címek maradnak. Így a következő router ami jelen esetben az SA nem tud vele mit kezdeni, hiszen nincs erre routing információja, így a default routing szabály vonatkozik rá amitől vissza küldi a CD-nek.

    Végtére is nem feltétlenül néz így ki az adott infrastruktúra ahol megcsinálnánk élesben, de ha már a teszt környezetem így nézet ki, ezért csináltam még egy PBR szabályt az SA -ra is aminek segítségével tovább rugdostam a proxy felé a csomagokat.
    Lássuk hogyan:

    ip access-list extended tovabb-route
     deny   tcp 10.157.0.0 0.0.255.255 10.157.0.0 0.0.255.255 eq www
     deny   tcp any 10.157.0.0 0.0.255.255 eq www
     permit tcp any any eq www
    
    route-map tovabb-route permit 10
     match ip address tovabb-route
     set ip next-hop 9.157.214.2
    
    interface FastEthernet0/0
     ip address 10.157.201.2 255.255.255.0
     ip policy route-map tovabb-route
    


    Innentől kezdve működött is. Gyönyörű szépen nyomon követhető volt Wiresharkban, CISCO ios debugban, és az access.log -okban.


    CÉL teljesítve.



    Szólj hozzá

    Hozzászólások(1)