NAT connection tracking naplózás Linuxon

Gyakran felmerülő probléma, hogy miképp lehet azonosítani linuxos SRC NAT mögötti gépeket megbízhatóan. Az ugye viszonylag egyértelmű, hogy címfordítást végző rendszeren valamit kezdenünk kell a kernel által vezetett conntrack táblával, amihez van egy sztenderd interfész minden Linuxon: a /proc/net/ip_conntrack-ből mindig ki lehet olvasni az éppen aktuális bejegyzéseket. Ez azonban igencsak behatárolt lehetőség. Tegyük fel, hogy percenként mentjük a táblázatot! Még így is igen könnyen lehetnek olyan NAT-olt kapcsolatok, amelyek az előző lekérdezés óta épültek ki, de azóta már kikerültek a conntrack táblázatból, ezért a percenkénti logjainkban semmilyen nyomuk nem marad, arról nem is beszélve, hogy rengeteg felesleges információt is eltárolunk, mert a conntrack bejegyzések jelentős része - a megnyitott, kiépített TCP sessionök - tipikusan több percen át élnek, és ezeket mindig újra és újra tárolgatjuk a percenkénti logokban.

Jobb lenne az eseményalapú megközelítés, csak akkor naplózni a conntrack bejegyzéseket, ha új kapcsolat épül ki, vagy ha az adott conntrack bejegyzés kikerül a conntrack táblázatból. Szerencsére ilyesmi létezik Linuxra, a szoftvercsomag neve conntrack-tools, a benne lévő eszközök pedig kiváló, dinamikus, userspace interfészt biztosítanak a kernel conntrack táblájához. A csomag két fontos eleme a conntrack és a conntrackd nevű program. Az előbbivel listázni, naplózni, létrehozni, módosítani, törölni lehet conntrack bejegyzéseket, az utóbbi (a démon) pedig redundáns NAT rendszerek közt képes a conntrack információk szinkronizálására. A conntrack naplózás tesztjéhez az alábbi topológiát használtam:

A "denobula" beállításait nem vittem túlzásba, egy teljesen alap Ubuntu 10.04 LTS telepítést kell elképzelni, ahol két paranccsal beállítható a 10.1.1.0/24 subnetből érkező csomagok forráscímeinek NAT-olása az eth0-ra aggatott külső IP-re, feltételezve, hogy az alapértelmezett ACCEPT iptables policy-ket senki és semmi nem állította át:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -s 10.1.1.0/24 -j MASQUERADE

Az interfészeket kell még beállítani, az /etc/network/interfaces fájlba kerüljenek a következők:

auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet static
address 10.0.2.15
netmask 255.255.255.0
gateway 10.0.2.2

iface eth1 inet static
address 10.1.1.1
netmask 255.255.255.0

Majd állítsuk be a DNS-t, végül húzzuk fel az interfészeket (újraindítás után ez már az init alatt megtörténik az előbbi auto bejegyzés miatt):

echo "nameserver 8.8.8.8" > /etc/resolv.conf
ifup eth0
ifup eth1

Következik a lényeg, a conntrack-tools telepítése (valójában csak a conntrack csomag szükséges ahhoz, amiről ebben a posztban szó lesz):

apt-get update
apt-get install conntrack conntrackd

A "denobula" beállítása ezzel meg is van, a tesztkörnyezetből még hiányzik a NAT mögötti kliens, az "andoria", ez bármi lehet, Live CD-s Linux, akármi, a lényeg, hogy konfiguráljunk rajta egy 10.1.1.2/24-es IP-t, majd a 10.1.1.1-et gatewaynek, valamint egy DNS szervert (pl. 8.8.8.8). Ezek után nincs más hátra, mint beröffenteni a NAT-os gépen a connttrack programot, a sok opció közül most a -E lesz az, amire szükségünk lesz, további opcióként megadtam a -o id,timestamp-et, így az egyes bejegyzések pontos időbélyege és az adott NAT-olt kacsolat belső ID-je is látszani fog a kimenetben:

root@denobula:~# conntrack -E -o id,timestamp,extended
[1331710267.511683]        [NEW] ipv4     2 tcp      6 120 SYN_SENT src=10.1.1.2 dst=74.125.232.247 sport=39059 dport=80 [UNREPLIED] src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39059 id=3607679456
[1331710267.513939]        [NEW] ipv4     2 tcp      6 120 SYN_SENT src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 [UNREPLIED] src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 id=3607679216
[1331710267.513992]     [UPDATE] ipv4     2 tcp      6 60 SYN_RECV src=10.1.1.2 dst=74.125.232.247 sport=39059 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39059 id=3607679456
[1331710267.514021]     [UPDATE] ipv4     2 tcp      6 60 SYN_RECV src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 id=3607679216
[1331710267.514047]     [UPDATE] ipv4     2 tcp      6 432000 ESTABLISHED src=10.1.1.2 dst=74.125.232.247 sport=39059 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39059 [ASSURED] id=3607679456
[1331710267.514076]     [UPDATE] ipv4     2 tcp      6 432000 ESTABLISHED src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216
[1331710272.506759]     [UPDATE] ipv4     2 tcp      6 120 FIN_WAIT src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216
[1331710272.507065]     [UPDATE] ipv4     2 tcp      6 60 CLOSE_WAIT src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216
[1331710272.507135]     [UPDATE] ipv4     2 tcp      6 30 LAST_ACK src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216
[1331710272.507208]     [UPDATE] ipv4     2 tcp      6 120 TIME_WAIT src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216

A kimenetben megtalálhatók a kért paraméterek, az első mező a timestamp, az utolsó mező a conntrack ID, a sorok egyébként elég beszédesek, minden sorban a második mező a conntrack esemény, amiből összesen három létezik, a NEW értelemszerűen egy új conntrack bejegyzés létrejöttekor generálódik, az UPDATE egy már létező bejegyzésben valamiféle változást jelez, például az UPDATE bejegyzésekben a TCP állapotátmenet-változások kiválóan követhetők. A harmadik, DESTROY nevű esemény pedig azt jelzi (a fenti példában épp nincs ilyen), hogy egy bejegyzés kikerül a conntrack táblából.

Ez a fajta eseményvezérelt kimenet már egészen közel van ahhoz, hogy használható legyen, két apróságra térnék még ki. Az első, hogy az STDOUT-ra küldött log nem tekinthető valódi log-nak, valahova át kell irányítanunk, a következő példában a tee-t használom, amivel így, ahogy van, ott lehet hagyni egy ötös vagy hatos szöveges terminálon, úgysem nyúl hozzá soha senki ;). A másik dolog, hogy általában az UPDATE eseményekre nincs szükség, hiszen az ilyesfajta logoknak az a lényege, hogy ki lehessen hámozni belőlük, hogy egy SRC NAT mögötti gép mettől meddig, milyen külső IP-vel, hová kommunikált, ehhez pedig elég a bejegyzés létrejöttét (NEW) és a bejegyzés végét (DESTROY) naplózni, ami közben történt a bejegyzéssel, nem érdekes. A "végső" NAT naplózó parancs tehát, amit természetesen ezer módon tovább lehet még fejlesztgetni, így néz ki:

conntrack -E -o id,timestamp,extended -e NEW,DESTROY | tee /var/log/ctrack.log

ISR router funkciók MikroTiken

Tesztelésre nálam van egy MikroTik eszköz (RouterBoard 493-as), 5.11-es RouterOS-szel, 9 darab tetszés szerint konfigurálható (Layer 2 / Layer 3) Ethernet interfésszel és egy WiFi interfésszel. Soha nem használtam még MikroTiket meg RouterOS-t korábban, egy picit irigykedve olvasgattam mások tapasztalatairól fórumokon, erre-arra, hogy ez linuxos cucc, mennyire megbízható, olcsóbb, mint a Cisco, ezt is tudja, azt is tudja.

Azért be kell vallanom, nem volt túl rózsás a kezdet, ugye a webes GUI meg a WinBox nevű windowsos konfiguráló csodák eleve nem is nagyon izgattak, hiszen ha használni fogunk MikroTiket, akkor az olyan környezetben lesz, ahol csak CLI jöhet szóba, és a CLI-t azt bizony szokni kell mondjuk egy IOS vagy bármi hasonló után. A hivatalos CLI dokumentáció sincs túl bő lére eresztve, úgyhogy MikroTik vonalon  sokat segít, ha az ember konzolkábelt ragad, és megpróbál mindenféle konfigurációkat összerakosgatni. Meglehet, hogy lesz még néhány hasonló poszt.

Elsőre arra gondoltam, hogy egy viszonylag általános ISR (Integrated Services Router) konfigurációt dobok össze: bridge a LAN portokon, SRC NAT, esetleg egy DNAT, WiFi (WPA2-PSK), WAN oldalon DHCP kliens, LAN oldalon DHCP szerver, NTP kliens... De még mielőtt belekezdenénk: a soros konzolport sebességét toljuk fel a terminálkliensünkön a sztenderd 9600-ról 115200-ra, ennél a típusnál ugyanis ez az alapértelmezés (gyors- és gépírók előnyben :)). A első dolog, amit érdemes beállítani, az a hostnév, itt persze véletlenül sem hostnévnek hívják:

/system identity
set name=TESZTROUTER

Jöhet a bridge interfész létrehozása. Fontos tudni, hogy ezen a boardon switch chip is van, így nem szoftverből történik a kapcsolás, hanem ASIC alapon megy, ami mindenképp dicséretes. A portok tetszőleges csoportját össze lehet bridge-elni, ebben a konfigurációban az ether1 porton kívül minden egyéb port a LAN oldali bridge groupban lesz:

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 disabled=no interface=ether2
add bridge=bridge1 disabled=no interface=ether3
add bridge=bridge1 disabled=no interface=ether4
add bridge=bridge1 disabled=no interface=ether5
add bridge=bridge1 disabled=no interface=ether6
add bridge=bridge1 disabled=no interface=ether7
add bridge=bridge1 disabled=no interface=ether8
add bridge=bridge1 disabled=no interface=ether9
add bridge=bridge1 disabled=no interface=wlan1

Adjunk a WAN és LAN oldali interfészeinknek címet, a WAN port az ether1 lesz, a LAN oldalon pedig a bridge1 interfész fogja kiszolgálni a klienseket:

/ip dhcp-client
add default-route-distance=1 disabled=no interface=ether1
/ip address
add address=10.100.202.1/24 disabled=no interface=bridge1

A következő lépés a DHCP szerver beállítása LAN oldalon. Ehhez létre kell hozni egy IP poolt, azt hozzárendelni egy DHCP szerverhez (TEST_DHCP_SRV), illetve egy interfészhez (bridge1). Csak alapinformációkat adunk át a klienseknek, a default gw és egy Google DNS IP minden, amit az IP címen kívül megkapnak egy félórára. Egy pici csavart azért vittem bele, hogy megnézzem a static (v. reserved) DHCP funkciót is, a 00:0C:42:B5:8C:48-as MAC című kliensünk mindig a 10.100.202.200-as IP címet fogja megkapni:

/ip pool
add name=TEST_DHCP_POOL ranges=10.100.202.200-10.100.202.254
/ip dhcp-server
add name=TEST_DHCP_SRV address-pool=TEST_DHCP_POOL disabled=no interface=bridge1 lease-time=30m
/ip dhcp-server network
add address=10.100.202.0/24 dns-server=8.8.8.8 gateway=10.100.202.1
/ip dhcp-server lease
add address=10.100.202.200 disabled=no mac-address=00:0C:42:B5:8C:48


Következzék a NAT beállítása: egyrészt szeretnénk a 10.100.202.0/24-ben lévő LAN oldali klienseket betenni SRC NAT mögé, másrészt a WAN IP-re érkező TCP 2323 kapcsolatokat DNAT-tal áttesszük az imént static DHCP-re állított LAN oldali host 23-as TCP portjára. Itt mind a SRC, mind a DST NAT esetében olyan parancsváltozatokat használtam, amelyekkel el lehet kerülni a külső IP-re való hivatkozást (mivel ebben a konfigurációban dinamikus a WAN IP-cím), de természetesen a RouterOS kelléktárában vannak ennél komolyabb NAT szabályokat is lehetővé tevő eszközök:

/ip firewall nat
add action=masquerade chain=srcnat disabled=no out-interface=ether1
add action=dst-nat chain=dstnat disabled=no protocol=tcp dst-port=2323 to-port=23 to-addresses=10.100.202.200

Érdemes szinkronizálni a rendszer óráját valami közeli NTP szerverrel:

/system clock
set time-zone-name=Europe/Budapest
/system ntp client
set enabled=yes mode=unicast primary-ntp=148.6.0.1

Végül következhet a WiFi beállítása. Először egy biztonsági profilt kell létrehoznunk, amit utána rá lehet aggatni az SSID-nkre. A "TEST_PROFILE_WIFI" profil WPA2-PSK authentikációt használ és AES titkosítást, a profilt használó "TEST_MIKROTIK" SSID-t 802.11b, g és n szabványt ismerő klienseknek szórjuk az 1-es csatornán (2412 MHz):

/interface wireless security-profiles
add name=TEST_PROFILE_WIFI authentication-types=wpa2-psk group-ciphers=aes-ccm group-key-update=5m mode=dynamic-keys wpa2-pre-shared-key=12345678
/interface wireless
enable wlan1
set name=wlan1 mode=ap-bridge band=2ghz-b/g/n bridge-mode=enabled frequency=2412 hide-ssid=no security-profile=TEST_PROFILE_WIFI ssid=TEST_MIKROTIK

Ebben a formában a konfigurációnk még nem igazán internetképes, mindenféle biztonsági problémák lehetnek vele, alapból például fut a RouterOS-en a telnet szolgáltatás, tűzfalat is kellene konfigurálni, jelszót beállítani az admin usernek stb. de kezdetnek megteszi, a többit talán majd egy másik alkalommal.

DNAT szabályok tűzfalazása Vyatta alatt

Rég nem volt már teljes egészében Vyattának szentelt írás az oldalon, a napokban épp szóba is került a rendszernek egy érdekesebb tulajdonsága a munkahelyemen, így most semmi sem tarthat vissza attól, hogy mindazt, amiről ott szó volt, közzé ne tegyem. Alapvetően egyszerű dologról van szó, a Vyatta port forwarding vagy DNAT lehetőségéről, ami kombinálva némi szűréssel, könnyen káromkodásba fordulhat (megjegyzem, minden Linux rendszeren ugyanezen szisztéma szerint működik a DNAT). Mi is ez az egész pontosan? Íme a Vyatta dokumentációból kiollózott ábra, mely az egyes NAT alrendszerek, a routing folyamat és a tűzfalazás viszonyát szemlélteti:

Az ábrán a témánk szempontjából két fontos dolgot láthatunk, az egyik az, hogy a DNAT (destination NAT, avagy port forwarding, esetleg szolgáltatás publikálás) minden egyéb feldolgozási folyamat, routeolás, szűrés előtt történik meg egy beérkező csomagon. Ezzel szemben az SNAT (source NAT) a legutolsó lépés, ami csak a routeolás és a tűzfalazás után történik. A szűrés szempontjából az SNAT sima ügy, bejön a klienstől a csomag mondjuk a 192.168.0.100-as forrás IP-vel, a célcím nem a Vyatta rendszer (Dest=local? No), a tűzfal szépen átkergeti az IN, majd az OUT irányú szabályokon, végül az SNAT dobozkában leszerelik róla a 192.168.0.100-as feladói címet és ráhegesztik mondjuk feladóként az 1.2.3.4 publikus címet, illetve ezt fel is jegyzik egy táblázatba, hogy a visszatérő forgalmat le lehessen kezelni és eljusson az eredeti feladóhoz.

A DNAT egy kicsit más, arról van ugye szó, hogy az 1.2.3.4-re irányuló, pl. TCP 80-as forgalmat valójában nem a Vyatta webszervere emésztgeti, hanem a mögötte lévő NAT-olt hálóban mondjuk a 192.168.0.101-es host. Bemegy a DNAT dobozba a 1.2.3.4:80-ra küldött üzenet, odabent átalakul, és ami kijön, annak már 192.168.0.101:80 lesz a célja. Persze a dobozban ezt a csereberét megintcsak jól feljegyzik. Ezek után a routing megmondja, hogy ez a 192.168.0.101 a Vyatta LAN oldalán található cím (Dest=local? No), átmegy az IN, majd az OUT szűrőn, és kimegy a LAN-ba.

Mindez azért érdekes, mert az ember - főképp, ha vállalati tűzfalak GUI-jához szokott - a tűzfalszabályok írásakor alapból nincs NAT üzemmódban, és egy ilyen DNAT-olt 80-as portot simán úgy vesz fel a Vyatta tűzfalszabályokban, hogy a külső IP címmel számol, az 1.2.3.4:80-ra engedi be a népeket, pedig mire a tűzfalhoz eljut az 1.2.3.4:80-as csomag, addigra az már keresztülverekedte magát a DNAT-on, és 192.168.0.101:80 van benne.

Következzék egy konkrét konfig példa, ami kívülről elérhetővé teszi az 1.2.3.4:22-es és 1.2.3.4:80-as TCP portokat, a különbség annyi, hogy az SSH a Vyattán fut, a HTTP viszont NAT mögött, másik hoston. A Vyatta külső interfészének (eth0) bejövő szűrőjében mégis egy privát, belső IP cím szerepel:

firewall {
    name INET_to_INTERNAL {
        default-action drop
        rule 100 {
            action accept
            description "Allowing HTTP traffic to internal host 101"
            destination {
                address 192.168.0.101
                port 80
            }
            protocol tcp
        }
    }
    name INET_to_LOCAL {
        default-action drop
        rule 100 {
            action accept
            protocol icmp
        }
        rule 200 {
            action accept
            description "SSH access on port 22"
            destination {
                address 1.2.3.4
                port 22
            }
            protocol tcp
        }
    }
}
interfaces {
    ethernet eth0 {
        address 1.2.3.4/24
        firewall {
            in {
                name INET_to_INTERNAL
            }
            local {
                name INET_to_LOCAL
            }
        }
    }
    ethernet eth1 {
        address 192.168.1.1/24
    }
    loopback lo {
    }
}
protocols {
    static {
        route 0.0.0.0/0 {
            next-hop 1.2.3.1 {
            }
        }
    }
}
service {
    nat {
        rule 100 {
            description "DNAT for HTTP on 192.168.0.101"
            destination {
                address 1.2.3.4
                port 80
            }
            inbound-interface eth0
            inside-address {
                address 192.168.0.101
            }
            protocol tcp
            type destination
        }
        rule 200 {
            description "SNAT for internal subnet"
            outbound-interface eth0
            outside-address {
                address 1.2.3.4
            }
            source {
                address 192.168.0.0/24
            }
            type source
        }
    }
    ssh {
        port 22
        protocol-version v2
    }
}

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.

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.