VPN-cím kontra LAN DHCP-bérlet: ki osztja ki az alagút IP-jét?

A VPN-kliens olyan címet mutat, amely soha nem jelenik meg a LAN bérletfájljában. Olvassa el a klienst, az IKEv2-terhelést és az átjáró készletét, hogy megtalálja a valódi kiosztót.

Csatlakoztassa a klienst, és nézze az adaptert a Wi-Fi ikon helyett. Egy olyan cím, mint 10.80.0.14, alagúton ülhet, miközben az irodai LAN egyetlen DHCP-kiszolgálója sem jegyezte fel soha azt a bérletet. Az a folyamat, amelyik a számot választotta, dönti el, hol kezdődik a hibakeresés.

A kliensen minden ugyanúgy néz ki: egy IPv4-cím, egy maszk, néha egy alapértelmezett átjáró. A különbség csak akkor derül ki, amikor megkérdezi, ki felel azért a címért, és ki vezet róla nyilvántartást.

Az alagút címének leolvasása a kliens oldaláról

A Windows akkor mutatja a különbséget, ha az egész blokkot olvassa, nem csak az első sort. ipconfig /all kinyomtatja az adapter leírását, a fizikai címet és egy DHCP-sort. A PPP vagy IKEv2 betárcsázós adapter általában letiltottként jelenti a DHCP-t, mert a kapcsolat a betárcsázás során tárgyalta ki a címét, ahelyett hogy LAN-kiszolgálótól bérelte volna. A DHCP-vel engedélyezett alagútadapter szokatlan, és külön vizsgálatot érdemel.

A Linux ugyanezt az információt két eszköz között osztja meg. A ip -4 addr show dev tun0 megadja a címet és az előtag hosszát. A nmcli -f IP4 connection show work feltárja, hogy az érték a kapcsolatprofilból, a linken történt DHCP-cseréből vagy tolt konfigurációból származik-e. A WireGuard a legvilágosabb eset, mert a wg-quick a felület megjelenésekor alkalmazza a konfigurációs fájl Address sorát, és csatlakozáskor egyetlen partner sem oszt ki semmit.

Az előtag is mond valamit. Egy /32 vagy egy 255.255.255.255 maszk azt jelenti, hogy az átjáró egyetlen gazdagép-címre kíván irányítani, míg egy szélesebb maszk a linken lévő alhálózatra utal valahol az alagút mögött.

Mit hordoz az IKEv2 konfigurációs terhelése

Az IKEv2-nek saját mechanizmusa van erre a feladatra. Az RFC 7296, 3.15.1 szakaszban leírt konfigurációs terhelés olyan attribútumokat hordoz, mint INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS és IPv6-os megfelelőik. A kliens nulla hosszúságú értékű attribútumot küld, ha nincs preferenciája, a válaszadó pedig visszaadja a használni kívánt értéket. Ez a csere az IKE_AUTH belsejében fut, már titkosítva, így egyetlen DHCP-sugárzás sem halad át soha az alagúton.

Két következmény adódik. Először, a címet a válaszadó vagy bármely engedélyezési háttér választja, amelyet a válaszadó megkérdez, ezért a készlet élhet az átjárón, egy RADIUS-válaszban vagy egy identitásszolgáltató leképezésében. Másodszor, a DNS-attribútum külön áll a címattribútumtól. A 10.80.0.14 fogadása semmit nem mond arról, melyik feloldó tért vissza, vagy visszatért-e egyáltalán.

A hálózati maszk attribútuma a gyakorlatban opcionális. Sok telepítés csak címet ad vissza, és a kliensre bízza egy gazdagép-útvonal telepítését, ezért ugyanaz a készlet az egyik kliensen /32-nek, a másikon /24-nek tűnhet.

Ahol a LAN DHCP-tartománya és a VPN-készlet ütkzik

A baj akkor kezdődik, amikor mindkét kiosztó ugyanarra a tartományra mutat. A 10.20.30.0/24-hez tartozó DHCP-kiszolgáló semmit nem tud a 10.20.30.128/25-höz beállított VPN-készletről, így semmi sem akadályozza meg abban, hogy 10.20.30.140-t béreljen egy nyomtatónak, miközben az átjáró ugyanazt a címet adja egy távoli kliensnek. Az ütközés napokig csendben marad, majd szakaszos duplikátumként felszínre kerül.

Az irányított telephelyek közti kialakítás magából a felépítésből elkerüli az ütközést. A fióktelepi gazdagép megtartja a helyi DHCP-kiszolgálótól kapott címet. A két átjáró alagútfelületei saját linkcímeiket hordozzák, és az útválasztási tábla dönti el, hogyan utaznak a csomagok. A távoli hozzáférésű kliensek címei harmadik kategóriát alkotnak, és nem szabad őket összekeverni az átjáró linkcímeivel.

Az alagút LAN-ra hidalása megszünteti ezt az elkülönítést. Ha a kialakításnak valóban egyetlen sugárzási tartomány kell, a VPN végpontjának ugyanazokban a kiosztási döntésekben kell részt vennie, mint a DHCP-kiszolgálónak, relén vagy közös hiteles forráson keresztül, ahelyett hogy maga adna ki címeket.

Ellenőrizze, melyik folyamat birtokolja a címet

Bizonyítsa a tulajdonjogot, mielőtt megváltoztat egy tartományt. A kliensen jegyezze fel a címet és az előtagot. A LAN-on keressen a bérletadatbázisban. Az átjárón listázza a készleteket, amelyeket kiosztani konfiguráltak. A bérletfájlban talált cím egy DHCP-kiszolgálóé, ami azt jelenti, hogy az alagút hidalt vagy relézve van; a csak az átjáró készletében talált cím az alagút végpontjáé.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Jegyezzen fel négy dolgot, amint a válasz világos: melyik komponens osztja ki a kliens címét, melyik tartomány van fenntartva számára, hogyan éri el a visszatérő forgalom azt a tartományt, és mely erőforrások fogadják el. Ez a négy bejegyzés virtuális adapter-sorból működési ténnyé változtatja a dolgot.

Ismételje meg az ellenőrzést a DNS-attribútumra is, amíg ott van. Az a készlet, amely címeket ad feloldó nélkül, a kliens helyi DNS-én hagyja, ami más hiba, mint az a készlet, amely a LAN által már használt címet adja.

Kapcsolódó cikkek