DHCP VPN-en át: hidaljuk a broadcastot, vagy továbbítsuk?

Egy új laptop az alagút túloldalán nem kap címet, miközben ugyanaz a laptop a központban működik. A szokásos első feltevés, hogy az alagút blokkolja a DHCP-t. Gyakrabban a broadcastnak soha nem volt útja: a beállítatlan kliens a 255.255.255.255 címre küld, és egy közönséges IP-útválasztó nem továbbítja ezt a csomagot. Az alagút pontosan azt teszi, amit egy irányított alagút tesz.

Két terv változtathat ezen, és nem egyenértékűek. Az egyik viszi a broadcastot; a másik továbbítja a kérést.

A broadcast soha nem halad át az útválasztón

Egy cím nélküli DHCPv4 kliens a 0.0.0.0 címről küld a korlátozott broadcast címre, UDP 67 és 68 porton. Ez a csomag a tervezés szerint a saját linkjén marad. Egy útválasztó, amely továbbítaná, elárasztaná minden általa kiszolgált szegmenst.

Így egy irányított telephelyek közötti alagút a továbbítót egy kiszolgálóhoz kapcsolja. Nem terjeszti ki a kliens broadcast tartományát, és egyetlen tűzfal-szabály sem fogja ezt elérni.

Mit terjeszt ki valójában az áthidalt alagút

Egy szándékosan áthidalt VPN a támogatott topológiáján belül vihet Ethernet broadcastot, és akkor a DHCP helyi forgalomként átjuthat. Ez valódi lehetőség, de 2. rétegbeli tervezési döntés. A hiba tartományát és a hozzáférési határt is kiterjeszti a broadcast mellett.

Az áthidalás azt is megváltoztatja, hogy egy broadcast vihar, egy ARP vizsgálat vagy egy rosszindulatú DHCP kiszolgáló mit érhet el. Ha nem csatlakoztatná a távoli irodát ugyanahhoz a switch-hez, ne hidalja át az alagutat csak a címek kiosztásáért. Tesztelje ezt a hatássugarat, mielőtt engedélyezi.

Nagyobb döntés ez, mint egy cím biztosítása, és szándékosan kell meghozni.

Inkább továbbítsa a kérést

A szokásos válasz egy továbbító a kliens helyi hálózatán. Fogadja a broadcastot, unicast kéréssé alakítja, és a saját címét a átjáró-cím mezőbe teszi. A kiszolgáló erre a továbbító címre válaszol.

Egy szemléltető távoli iroda esetén a továbbító az iroda LAN-ján van, a kiszolgáló pedig a telephely VPN-jén keresztül érhető el. Állítsa be a tartományt ahhoz az irodához, a továbbító és a kiszolgáló azonosítóit, valamint a teljes visszautat. Az UDP 67 átengedése az alagúton nem mondja meg a kiszolgálónak, melyik készletet használja.

Az a továbbító, amely továbbít, de soha nem kap választ, általában visszaúti probléma. Ellenőrizze a visszautat a továbbító címéhez, mielőtt módosítja a tartományt.

Válassza külön a DHCP-t az ARP-tól és az alagút címzésétől

A DHCP UDP/IP fölött fut. Etherneten a gazdagép ARP-t is használhat annak ellenőrzésére, hogy egy jelölt cím már használatban van-e. Ez az ütközésellenőrzés külön link-lokális művelet, nem a DHCP üzenetek szállítása. Azt állítani, hogy a DHCP lényegében ARP, téves; azt állítani, hogy a kettő soha nem függ össze, túl tág.

A VPN kliens az alagútcímét a VPN protokolltól vagy a kiszolgáló saját készletéből is megkaphatja, nem csak DHCP broadcastból. Egy DHCP nevet tartalmazó beállítás leírhatja a kiküldött kliensbeállításokat, nem egy továbbított DHCP csomagot. Ellenőrizze a kiszolgáló készletét, mielőtt feltételezné, hogy a DHCP egyáltalán érintett.

Rögzítse a fogadó hálózatot, a kiosztás tulajdonosát, a tartományt, hogy létezik-e továbbító, és a kimaradás alatt várható viselkedést. Ezután teszteljen egy új bérletet és egy megújítást ezen a modellen keresztül. Ha két telephely ugyanazt a kezeletlen készletet szolgálhatja ki, van egy ütközés, amely az első barangoló laptopra vár.