32 bitnél hosszabb IPv4 kompatibilis címek: A+P címzés

Az előző posztban hivatkozott egyik szerző, Steven M. Bellovin publikációi közt egy érdekes dologra akadtam: A better approach than carrier-grade-NAT. IPv4 exhaustion / IPv6 témakörben nagyjából mindenki arra számít, hogy előbb-utóbb, dual stackkel vagy anélkül, de megjelennek a Carrier Grade NAT-ok (CGN), azaz a szolgáltatók a saját hálózatukon közbeiktatnak egy NAT lépést, hogy minél kevesebb publikus IPv4 cím kerüljön közvetlenül felhasználóikhoz. Bár ez nem ördögtől való ötlet, azért annyira nem is kellemes dolog. Gondoljunk csak bele, hogy amikor egy NAT-on osztozunk esetleg több száz egyéb felhasználóval, milyen kérdések vetődhetnek fel:

• Limitált számú párhuzamos session nyitására lesz lehetőségünk, valószínűleg kevesebbre, mint CGN nélkül, hiszen a CGN eszközön rendelkezésre álló TCP/UDP portok száma számos felhasználó közt oszlik szét.
• Az UPnP, port forwarding (DNAT) felejtős, hacsak nem tudjuk meggyőzni a szolgáltatót, hogy nekünk ezt vagy azt a külső portot adja át fixen, ami lássuk be, nem túl valószínű.
• A CGN külső IP-je egy esetleges rossz belső CGN szomszédság miatt felkerülhet ilyen-olyan tiltólistákra.
• Nehéz kérdés a CGN esetén a nyomon követhetőség a végfelhasználóig, bár ez elsősorban nem az ügyfelek, hanem a szolgáltatók problémája, mindenesetre az ügyfelek megbízható azonosítása érdekében igen gyakori CGN NAT tábla mentésekre lenne szükség.

De vajon hogyan élhetnénk túl az IPv6 elterjedéséig hátralévő időszakot? Hogyan lehetne többet kihozni az IPv4-ből? Van-e jobb módszer a CGN-nél? Az belinkelt tanulmány szerzői azzal az ötlettel álltak elő 2008-ban, hogy ki lehetne bővíteni a IPv4 címtartományt bitek átcsoportosításával a TCP/UDP portszámokból. Ez lenne az address + port címzés (A+P), ahol a hálózati címbe beleszámítana a TCP vagy UDP forgalom multiplexelését lehetővé tevő portszám mező valahány bitje.

Az ötlet persze zseniális, de alapvetően patkolás, nem megoldás, és azon túl, hogy ez is igényel változásokat mind CPE oldalon, mind a szolgáltatói eszközökben, a legtöbb CGN-es kérdést nem tudja megoldani. Előrelépés egyedül a DNAT témában lenne, hiszen az A+P-vel minden végfelhasználóra juthatna valamekkora fix szeletke az átcsoportosított portszám bitektől függően, amellyel szabadon rendelkezhetnének. Ugyanakkor nem választhatnának akármilyen portot a kívülről elérhető szolgáltatások számára, hiszen az adott szolgáltatáshoz tartozó well-known portok egyáltalán nem biztos, hogy abba a szeletkébe esnek, ami az adott felhasználónak jutott.

Az A+P címzés inkább tűnik egy érdekes ötletnek, mint ténylegesen megvalósítható dolognak, jelzi ezt az is, hogy az elmúlt pár évben nem volt nagy visszhangja a javaslatnak, összességében mégis szórakoztató volt végiglapozgatni, ki gondolta volna, hogy IPv4 címzés témában még lehet újat mondani?

NAT detektálás és szűrés

Bizonyára másokban is felmerült már, hogy miképp lehet egyszerűen kiszűrni a NAT-os eszközök forgalmát. Általában ezek adminisztratív szemszögből vizsgálva elég nyűgös holmik, amelyekkel akár a RADIUS authentikációt vagy az access switchek port security beállításait (pl. hogy egy portról csak egy MAC címet tanuljon meg a switch) is át lehet verni.

A NAT a külvilág számára nem transzparens, a külső szemlélő számára egyetlen MAC címről  és egyetlen IP-ről érkezik minden NAT mögötti hostról a forgalom, maga a NAT-ot végző host persze lehet, hogy minden biztonsági feltételnek megfelel, a NAT mögötti eszközök azonban általában nem. A NAT-os eszközt sem hálózati szakember szokta konfigurálni, gyakran csak arról van szó, hogy a biztonságra nem túl sokat adó felhasználók -- rosszabb esetben kollégák -- szeretnének egyszerűbben hozzáférni bizonyos erőforrásokhoz, így összekötnek egy SOHO IPv4 NAT routerrel két hálózatot, például a vendégek számára fenntartott internetet subnetet mondjuk valamelyik belső subnettel. Így a SOHO routeren keresztül, ha az tud statikus route-okat (szinte mind ilyen) egyszerre férnek hozzá belső erőforrásokhoz valamint a Facebookkal, Napiszarral, akármivel felturbózott internethez. Máskor az egyetlen MAC címre redukált hozzáférést többszörözik meg egy NAT-os host segítségével, és akkor még nem is beszéltünk olyan gondokról, amikor a NAT-hoz wi-fi is társul. Akárhogy is, azért az ilyesmi előbb-utóbb valakinek feltűnik, rosszabb esetben a SOHO router DHCP szervere "elszabadul", vagy éppen az válik érdekessé, hogy egy-egy host milyen gyanúsan sokat forgalmaz, és akkor derül ki róla, hogy NAT-ol még jó pár egyéb host számára.

A NAT detektálása külön művészet, több módszer létezik rá, egy dolog azonban közös bennük: nagyjából mind megbízhatatlan. Nyolc-kilenc éve jelentek meg a NAT detektálásról az első komolyabb tanulmányok, az egyik sokat hivatkozott publikáció a "Detecting NAT devices using sFlow", melyben a szerző (Peter Phaal) rögtön két módszert is bemutat. Az IP TTL alapú módszer igen egyszerű, abból indul ki, hogy az egyes OS-ek TTL kezdőértéke jól tudható, a mostanában használt Windowsok például 128-as TTL-lel indítják útnak a csomagjaikat, a Linuxok 64-gyel (egyéb default TTL értékek itt), így a hálózatunk topológiájának ismeretében viszonylag egyszerű meghatározni, hogy a topológia adott helyén milyen TTL-eket kellene látnunk a IP fejlécekben. Nyilván, ha ezeknél épp eggyel kevesebbet látunk, az beszédes, és könnyen lehet, hogy egy NAT routeren áthaladva lett a TTL mező értéke eggyel kisebb, mint a normál hostokról származó csomagok TTL mezejének értéke.

A másik módszer az IP ID mező értéke alapján történő statisztika készítése, amivel meg lehet becsülni, hogy mennyi host található egy-egy NAT eszköz mögött. Az IP ID módszer azonban leginkább Windows rendszerekkel működik jól, ugyanis ezeken kiszámítható az IP ID mező kezelése, a rendszer mindig eggyel növeli az értéket. Linuxon sessiononként random a kezdőérték, míg például az OpenBSD alatt minden egyes csomagban random az IP ID értéke. Az IP ID mezőre építő megoldásról egyébként külön értekezik a Columbia Egyetem egyik professzora, Steven M. Bellovin is az "A Technique for Counting NATted Hosts" című munkájában.

További módszer az eszközeinken áthaladó forgalmon végzett passzív OS fingerprinting, ennek lényege, hogy egy adott host nem fog rövid időn belül különféle OS-ekre jellemző tulajdonságokat mutatni, amennyiben mégis így történik, valószínű, hogy NAT-os eszközről van szó. Az OS fingerprinting és az IP ID módszer hátránya, hogy ezek sokkal inkább illenek mondjuk egy auditor eszköztárába, viszonylag erőforrásigényesek, ráadásul nem lehet őket real time szűrésre felhasználni. Ezzel szemben az IP TTL módszer egyszerű, mint az ék, és ha ismerjük a ránk bízott hálózatokat, akár real time szűréseket is be tudunk vezetni, bízva abban, hogy felhasználóink nem birizgálják a TTL kezdőértéket. IOS-ben extended ACL szükséges a TTL-re építő szűréshez, Linux alatt, a Netfilterben pedig külön modul (-m ttl) áll rendelkezésünkre.

Végül vannak természetesen törekvések komplex módszerek kialakítására is, amelyekben a fenti eljárások mindegyikét használják egymással párhuzamosan, hogy megbízhatóbb eredményeket kapjanak, egy ilyenről olvashatunk a "NetFlow Based System for NAT Detection" című szösszenetben.

BGP neighbor ellenőrzés FortiOS alatt

Igen rugalmas a Fortigate eszközök webes felülete, valóban szinte mindent el lehet intézni a webGUI-n keresztül, a BGP routeolás épp a kivételek közé tartozik, legalábbis keresgéltem egy ideig menüben rejtett opciókat, amivel több információt ki lehetne szedni a BGP-ről, aztán persze, mint oly sok egyéb esetben is, a vége CLI lett. Érdekes különben összevetni, hogy mennyire hasonlít az IOS show ip bgp neighbors x.x.x.x kimenetére a parancs FortiOS alatti párja:

FORTIGATE $ get router info bgp neighbors 10.10.10.10

BGP neighbor is 10.10.10.10, remote AS 65200, local AS 65100, external link

  BGP version 4, remote router ID 10.1.1.1

  BGP state = Established, up for 05w5d16h

  Last read 00:00:28, hold time is 180, keepalive interval is 60 seconds

  Configured hold time is 180, keepalive interval is 60 seconds

  Neighbor capabilities:

    Route refresh: advertised and received (old and new)

    Address family IPv4 Unicast: advertised and received

    Address family IPv6 Unicast: advertised and received

  Received 295328 messages, 159 notifications, 0 in queue

  Sent 297947 messages, 170 notifications, 0 in queue

  Route refresh request: received 0, sent 0

  Minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast

  BGP table version 7017, neighbor version 6997

  Index 0, Offset 0, Mask 0x1

  Community attribute sent to this neighbor (both)

  Outbound path policy configured

  Route map for outgoing advertisements is *SET-COMMUNITY-OUTroot

  1 accepted prefixes

  66 announced prefixes

 For address family: IPv6 Unicast

  BGP table version 1, neighbor version 1

  Index 0, Offset 0, Mask 0x1

  0 accepted prefixes

  0 announced prefixes

 Connections established 44; dropped 43

Local host: 10.10.10.1, Local port: 7864

Foreign host: 10.10.10.10, Foreign port: 179

Nexthop: 10.10.10.1

Nexthop global: ::

Nexthop local: ::

BGP connection: non shared network

Last Reset: 05w5d16h, due to BGP Notification sent

Notification Error Message: (CeaseUnspecified Error Subcode)

A legfontosabb sorok egy az egyben az IOS kimenetét imitálják. A BGP peer IP-je után, szintén az IOS-es mintára, biggyeszthetünk mindenféle kiegészítőket, például, hogy mit hirdetünk a szomszéd felé, mit kapunk tőle, stb.:

FORTIGATE $ get router info bgp neighbors 10.10.10.10 ?
<WORD>    (advertised-routes|received prefix-filter|received-routes|routes)

NAT444 dual stack modell az átálláshoz

Újabb modell az IPv6 átálláshoz, ami jelenleg nincs még fent a Wikipedián sem: NAT444. Persze annyira azért nem új (januári), és forradalmi dolgokat nem érdemes várni tőle, leginkább maga az elnevezés volt újdonság nekem még most, májusban is. Ahogy az is, hogy a NAT64 mintájára egyre több helyen lehet olvasni NAT44-ről is, ami nem más, mint a megszokott IPv4 NAT, aminek ugye mindkét oldalán IPv4-es címek vannak, innen a 44. No, a NAT444 lényegében ugyanez, csak kétszer: az IPv4-es csomagoknak két NAT táblán kell átküzdeniük magukat, az első a szolgáltató által biztosított IPv4/IPv6 dual stack végberendezés, a második pedig az LSN (Large Scale NAT) vagy más néven CGN (Carrier Grade NAT) eszköz a szolgáltatónál. Rendes NAT444-es ábra sem volt sehol, így rajzoltam egyet én:

Bár nincs belső információm a hazai szolgáltatóktól, azért szemernyi kétségem sincs afelől, hogy ebből a modellből az LSN/CGN rész előbb-utóbb meg fog valósulni az otthoni felhasználók számára, vagy akár olyasmit is elképzelhetőnek tartok, hogy a szolgáltatók drágábban adják majd az LSN/CGN nélküli előfizetéseket mint a szolgáltatói NAT-os és/vagy IPv6-os előfizetéseket. Ami viszont a dual stack végberendezések (SOHO router) tömeges elterjedéseset illeti, itt azért vannak kétségeim, évtizedes távlatban bizonyára reális lehet, hogy a felhasználók jelentős százalékánál megjelennek ilyen eszközök.

Visszatérve a NAT444-re: komoly hátránya, hogy viszonylag bonyolult CPE eszközre van szükség ahhoz, hogy a végfelhasználó hozzáférhessen mind az IPv4-es, mind IPv6-os erőforrásokhoz (ez az átmenet alatt az alapvető elvárás), ráadásul ehhez a végfelhasználó eszközein (PC, notebook, egyéb kütyük) is dual stack kell, hogy fusson.

BGP gondok Juniper és Fortigate eszközök közt

Másfél hete volt egy igen kellemes leállásunk. Az ERP rendszerünk ki van szervezve külső szolgáltatóhoz, ahová rendeltünk egy bérelt vonalat és van egy backup VPN tunnelünk is. Ez elvileg ugye teljesen kerek, a bérelt vonal és a VPN-hez használt internet két különböző szolgáltatótól jön, BGP-t futtatunk mindenhol, a megoldás ki volt tesztelve átadáskor, gond egy szál sem, minden ment, a BGP peerek látták egymást bérelt vonalon és a VPN-en is, a bérelt vonal megszakításakor a forgalom gond nélkül átállt a backup VPN-re, ráadásul a peer-ek maguk is redundáns eszközök, szóval nagyjából tankönyvi megoldás volt, látszólag.

Na, ehhez képest két hete pénteken világvége volt, megállt az ERP site felé a bérelt vonal, mert valahol Észak-Európában elvágtak egy optikát, a backup VPN tunnel pedig hiába működött, az ERP site-ról nem jöttek a BGP frissítések, így nem volt elérhető az ERP rendszerünk.

Villámgyors megoldásként néhány jól irányzott statikus route jól jött volna, de a site-to-site VPN ki van szervezve (network teamen kívüli, felülről jött döntés), a VPN eszközeinkhez kizárólag read only hozzáférésünk van, csak a VPN szolgáltató helpdeskjén keresztül kérhetők módosítások. A másik oldal, az ERP site szintén ki van szervezve, az ottani VPN eszköz része az ERP szolgáltatáscsomagnak, szintén csak (egy másik) helpdesken keresztül érhető el. Na most el lehet képzelni, hogy micsoda tempóban oldódnak meg az ilyen helpdesk kérések, főleg ha két, egymástól független szolgáltatónak kell együttműködnie. Nagyjából mire megjavult a bérelt vonal, addigra állt össze a BGP peering is az ERP site és a VPN hubunk közt. A network team meg begyűjtött egy kb. hatórás ERP leállást.

Az az érdekes, hogy senki nem tudja, mitől állt meg a backup VPN-en a BGP. Illetve nem is állt meg teljesen, a VPN hubtól érkező prefixeket ERP site-on futó eszköz látja, viszont az ERP site-ról nem érkezik semmi a VPN hubhoz. A VPN hub egy Fortigate 620B cluster, az ERP site-on pedig valamilyen Juniper holmikon futó virtuális eszközöket kaptunk VRRP-ben. Az ERP-s network supportosok szerint a Juniper virtuális eszközünkön nincs olyan parancs, mint az IOS-ben show ip bgp neighbors x.x.x.x advertised-routes, így nem tudják megnézni, hogy mit küldenek adott BGP peer felé. A Forigate eszközön pedig eltűnt a neighborök közül a Juniper eszköz.

Megoldás gyanánt mind a Fortigate mind a Juniper eszközökön újraindították a BGP processzt, amitől a dolog megjavult (tehát nem tűzfalas gond volt), de nem vagyok meggyőződve arról, hogy ez hosszú távon is működőképes lesz. Ma kaptunk backup VPN éles tesztelésre egy kis időt, és ma éppen minden működött úgy, ahogy kell, de nem volt igazán meggyőző az ERP szolgáltatónknál dolgozó networkös kolléga, aki a múltkori állás okaival kapcsolatban annyit mondott, hogy "bad luck". Statikus route lesz a vége, már látom előre.

PPPoE VLAN interfészen Vyatta alatt

Délután hosszasan vesződtem azzal, hogy egy VDSL modem mellé bekonfiguráljak egy Vyatta 6.2-es rendszert. Nem voltak nagy igények, csak a szokásosnak mondható dolgok, SPI tűzfal, NAT, DHCP, ilyesmi. Az egyetlen szokatlan dolog, hogy a Vyatta rendszerben egyetlen NIC-en, VLAN-okkal szerettem volna megoldani a LAN és a WAN kapcsolatot. Az interfész konfiguráció tehát első blikkre kb. így nézett ki:

interfaces {
    ethernet eth0 {
        duplex auto
        hw-id aa:aa:aa:aa:aa:aa
        speed auto
        vif 2 {
            pppoe 0 {
                connect-on-demand
                default-route auto
                mtu 1492
                name-server auto
                password DSLpassword
                user-id DSLusername
            }
        }
        vif 3 {
            address 192.168.0.1/24
        }
    }
    loopback lo {
    }
} 

Mondanom sem kell, nem ment. De hát mi a fene baja lehet? A modem elérhető volt a 2-es VLAN-on, a LAN oldalon is rendben volt a 3-as VLAN, a tesztkliens LAN oldalon megkapta DHCP-vel a szükséges adatokat a Vyattától, de valamiért a PPPoE nem jött össze. Persze rögtön kipróbáltam, hogy közvetlenül a modembe dugom a tesztklienst: csatlakozott. Jó, akkor lépjünk tovább, a tesztkliens VLAN2-ben, switchen keresztül vajon csatlakozik-e? Persze, így is működik. Hm... vajon a Vyatta-hoz használt trönk port jó? VLAN2 és VLAN3 is tagged, ahogy a Vyattán konfiguráltam? Ezzel sem volt gond. Akkor talán a Vyatta rendszerben használt NIC problémás? Neeem, simán kezeli a VLAN-okat, nincs vele gond.

Turkáltam a Vyatta doksikban, ez, ha lehetséges, még kevesebb eredménnyel zárult, hiába van a rendszerhez 1000+ oldal dokumentáció, arról, hogy Ethernet interfészen hogy lehet PPPoE-t beállítani, nem sokat mesélnek, a DSL-es példák is egytől egyig az előfizetéses SE verziójú Vyattában használható DSL modemkártyák beizzításáról szólnak, PPPoE over VLAN sehol.

Rendben, gondoltam, ha nincs más, akkor belenézünk tcpdumppal. Igen ám, de mibe? Kiderült, hogy a fizikai interfészen egy árva PPPoE-vel kapcsolatos bit sem megy át, se PADI, se PADO, semmi, hiába próbálgatom a connect interface pppoe0 parancsot. Itt azért már gyanús volt, hogy valami vyattás hülyeségbe szaladtam bele, talán nem is támogatott lehetőség a PPPoE over VLAN vagy hasonló.

Végül a Google kiköpte a választ, nem a PPPoE over VLAN a hiba forrása. Persze azóta elkevertem a linket, és már nem emlékszem, hogy mire kerestem pontosan, de mindegy is, a lényeg, hogy egy vyatta.org-os fórumbejegyzésben egy Vyatta alkalmazott leírta, hogy már egy ideje gond van ezzel a connect-on-demand dologgal, és ha azt kiszedjük a konfigból, minden jó lesz. És tényleg, a delete interfaces ethernet eth0 vif 1 pppoe 0 connect-on-demand parancs kiadása után minden a helyére került. Megjegyzem, ez azért bénaság egy olyan feltörekvő networkös cégtől, amelyik a vállalati piacra szeretne betörni. Kíváncsi lennék, hogy vajon csak az ingyenes Vyatta szoftververziókban van-e ilyen hiba vagy az előfizetéses változatokban is?

Reguláris kifejezések a különféle network OS-ekben (1.)

Az előző posztban említett kézi hálózatfelderítés során többször is alkalmaztam IOS alatt reguláris kifejezéseket a különféle parancsok kimenetének szűrésére, nem kell bonyolult dolgokra gondolni, csak nagyjából ilyesféle szűrésekre:

DEVICE#sh mac-address-table | include Gi1/0/1
   1    0001.e674.baa6    DYNAMIC     Gi1/0/13
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1
   1    0001.e6a2.02b6    DYNAMIC     Gi1/0/13
   1    0002.e33c.5203    DYNAMIC     Gi1/0/13
   1    0002.e33c.5316    DYNAMIC     Gi1/0/15
   1    0002.e34f.08fd    DYNAMIC     Gi1/0/13
   1    0002.e34f.0a42    DYNAMIC     Gi1/0/13
   1    0002.e352.8dbb    DYNAMIC     Gi1/0/13
   1    000f.fe02.3f48    DYNAMIC     Gi1/0/13
   1    000f.fe30.880e    DYNAMIC     Gi1/0/13
   1    000f.fe31.920d    DYNAMIC     Gi1/0/15

DEVICE#sh mac-address-table | include Gi1/0/1$
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1


Nyilván egyértelmű a különbség azok számára is, akik nem ismerik a regexpeket. A $ kifejezés a keresendő minta végéhez illeszkedik, tehát az az megelőző szöveges mintának a sorvégeken kell szerepelnie, ezért nem jelenik meg egy olyan sor sem a második példában, amelynek a végén nem pontosan a "Gi1/0/1" karaktersor áll. Ez persze az egyik legegyszerűbb példa, számtalan egyéb dolgot bevethetünk még, a regexpek használatának lehetősége átszövi az IOS-t, legtöbbször persze a különféle show kimeneteket szűrjük meg velük, de vannak más alkalmazási lehetőségek is, többek közt ilyen a BGP AS-path szűrés. Vajon mi a helyzet az egyéb OS-ekben?

A márciusban kiadott legújabb FortiOS-ben (4.0MR3) a CLI referencia kézikönyv szerint az alábbi területeken nyílik lehetőségünk regexp használatra:

• Data Leakage Prvention (DLP) szabályok definiálásakor
• BGP AS-path szűrésre
• Különféle e-mail szűrésekhez (e-mail cím alapú levélszűrésre, spamszűrőkben, MIME header szűrésre)
• Weboldalak tartalom- illetve URL alapú szűrésére
• CLI-ben a get, show és diagnose parancsok kimenetének szűrésére (a szokásosnak mondható include, exclude parancsok helyett itt egyszerűen csak grep a szűrő parancs)

A H3C/3Com örökséget tovább vivő HP Networking termékekben szintén megtalálható a regexp támogatás, hogy pontosan mire is használható, arról a  "Reguláris kifejezések a különféle network OS-ekben" következő részében lesz szó.