A VPN-készlet nem a LAN DHCP-tartománya: miért törik el

A csábító rövidítés az, hogy a VPN-ügyfeleknek ugyanabból a tartományból osszunk címeket, amelyet az irodai DHCP-kiszolgáló használ, abban a hitben, hogy úgyis minden egy hálózat. Nem az. Az útvonalválasztott alagút unicast csomagokat szállít két végpont között, míg a LAN-készlet azért létezik, hogy a fizikai szegmensen érkező broadcast-kérésekre válaszoljon. A számok újrafelhasználása két kiosztót tesz felelőssé egy címtérér, és meghatározatlanul hagyja a visszautat.

Két kiosztó, egy címtér

A LAN DHCP-kiszolgálója tudja, mely címeket adta bérbe és melyik MAC-címnek, és ARP-val védi őket. A VPN-kiszolgálónak saját készlete van, és semmit nem tud ezekről a bérletekről. Egyik sem téved; csak soha nem mutatták be őket egymásnak.

Egy cím a LAN-készletből, amelyet a VPN-kiszolgáló kiad, már tartozhat egy nyomtatóhoz. Most két eszköz igényel egy címet ugyanazon az előtagon, és a kapcsoló továbbítási táblája dönti el, melyik válaszol.

Ez az a hiba, amellyel az emberek először találkoznak: egy ügyfél sikeresen csatlakozik, majd a rossz géphez ér, vagy csak szakaszosan éri el a megfelelőt.

Miért nem oszt az útválasztó VPN-címeket

A DHCP-felderítés broadcast, a broadcastok pedig egy útvonalválasztott határon megállnak. Hacsak a terv nem hidálja át az alagutat, vagy nem futtat megfelelő jogosultságú DHCP-relét, az ügyfél kérése soha nem ér el a LAN-kiszolgálóhoz.

Ezért a VPN-kiszolgáló maga osztja ki a címet: egy készlet a kiszolgáló konfigurációjában, egy cím peerenként egy WireGuard-telepítésben, vagy egy cím, amelyet a hitelesítési réteg továbbít egy IKEv2-telepítésben. Ezek a mechanizmusok függetlenek a LAN bérleti adatbázisától, és éppen ezért van szükségük saját tartományra.

Ugyanez a logika magyarázza, miért nem javítja meg a DHCP-tartomány módosítása azt a VPN-ügyfelet, amely soha nem kap címet. Az ügyfél nem a LAN-kiszolgálót kérdezi, és a tartomány szerkesztése nem veszi rá a kérdezésre.

Az átfedés ütközésként jelenik meg, nem lassú hálózatként

Két hálózat, amely támogatott terv nélkül osztozik egy előtagon, más probléma, mint a kettős tulajdon, és gyakran összekeverik őket. Ha a VPN-készlet külön előtag, az átfedés csak akkor számít, ha egy útvonal a rossz oldalra küldi a forgalmat. Ha a készlet a LAN-előtagon belül van, az ütközés azonnali és helyi.

A gyakorlatban ARP-válaszokat lát a rossz eszköztől, félúton visszaálló kapcsolatokat, és olyan ügyfelet, akinek a saját címét valaki más igényli. Ezek egyike sem tűnik útválasztási problémának, ezért a javítás a rossz rétegre kerül. A kettős bérlet könnyen igazolható és kellemetlen vele együtt élni. Újraindításokat is túlél, mert mindkét kiosztó ragaszkodik ugyanahhoz a címhez.

A visszaút külön probléma

Még egy tiszta, külön készlet esetén is a LAN-gazdáknak tudniuk kell, hogyan válaszoljanak egy ügyfélnek. Az alapértelmezett átjárójuk az útválasztó, és az útválasztónak szüksége van a készlethez egy a VPN-kiszolgálóra mutató útvonalra, kivéve, ha a terv inkább lefordítja az ügyfél forgalmát.

Olvassa el az útvonalat mindkét irányban, mielőtt bármit módosít. Az átjárón kérdezze meg, melyik interfészt használná a kernel egy ügyfélcímhez; az ügyfélen kérdezze meg, melyik útvonalat használja egy LAN-címhez.

Ezek a parancsok mutatják a továbbítási döntést az átjárón és a szomszédbejegyzéseket, amelyek felfedik a duplikátumot:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Ha az első parancs az alagút interfésszel válaszol, a visszaút létezik. Ha a LAN-interfésszel válaszol, az útválasztó azt hiszi, hogy az ügyfél a vezetéken van, és ARP-ot kísérel meg számára.

Léteznek áthidalt tervek, de választani kell köztük

Az alagút LAN-ba hidálása valódi terv, amelyet akkor használnak, amikor az ügyfeleknek broadcastot kell kapniuk, vagy olyan protokolloknak kell felfedezniük őket, amelyek egy szegmenst feltételeznek. Ehhez a kiszolgálónak birtokolnia kell ezt a hidálási viselkedést és a hozzá tartozó címkezelést.

Ami nem működik, az az eredmény utánzása számok másolásával. A híd nélküli közös készlet megadja az ütközést a felfedezés nélkül, ami a két elrendezés közül a legrosszabb.

Válassza a harmadik réteget külön készlettel, hacsak az alkalmazásnak tényleg nem kell a szegmens, és dokumentálja a készletet, hogy a következő adminisztrátor ne használja újra a DHCP-tartományt a rend kedvéért.