A távoli VPN-kliensek csatlakoznak, a LAN-kiszolgáló válaszol, és a válasz a szokásos internetes routeren keresztül távozik, majd ott meghal. Egy kiszolgáló javítható statikus útvonallal, de egy egész alhálózatnyit belőlük jobb ott kezelni, ahol már megkapják a hálózati konfigurációjukat. A DHCPv4 121-es opciója pontosan ilyen célútvonalat oszt ki, és ez az a rész, amit az emberek általában elrontanak abban a pillanatban, amikor megfeledkeznek az alapértelmezésről. A tünet egyirányú forgalom: a kérések megérkeznek, a válaszok eltűnnek.

Először nevezze meg a három címet

Vegyünk egy konkrét LAN-t: 192.168.50.0/24 a szokásos alapértelmezett routerrel 192.168.50.1-en és egy külön VPN-átjáróval 192.168.50.2-n. A hitelesített távoli kliensek a 10.90.0.0/24-at foglalják el.

Az útvonal, amelyre minden részt vevő gépnek szüksége van, 10.90.0.0/24 via 192.168.50.2. A cél a kliensmedence, a következő ugrás pedig az átjáró LAN-címe, nem a tunelcíme.

Kódolja osztály nélküli statikus útvonalként

A 121-es opció prefix és következő ugrás párokat szállít, és az RFC 3442 meghatározza mind a kódolást, mind az abból következő kliensviselkedést. Egy meglévő dnsmasq-példányhoz, amely csak ezt a szemléltető LAN-t szolgálja ki, a konfiguráció alakja ez:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

Ez egy töredék, nem új DHCP-szolgáltatás. Több szegmenst kiszolgáló kiszolgálón korlátozza az opciót a már használt címkékkel vagy hálózati házirenddel. Tartsa kéznél az előző konfigurációt, mert a visszaállítás egy újabb bérletmegújítást jelent, nem újraindítást.

Ne veszítse el az alapértelmezett útvonalat

Ez a csapda. Az a kliens, amely megkapja a 121-es opciót, köteles figyelmen kívül hagyni a szokásos Router opciót, ezért ha csak a VPN-medence útvonalát hirdeti meg, az teljesen alapértelmezett útvonal nélkül hagyhatja azt a gépet. A gép továbbra is konfiguráltnak látszik, és csendesen elveszíti az internetet. A felhasználók ezt úgy írják le, hogy leállt a hálózat, miközben minden interfész fel van.

Vegye fel a szándékolt alapértelmezést ugyanabba a listába, ahogy a fenti töredék teszi. Tartsa meg a szokásos Router opciót is azoknak a klienseknek, amelyek nem valósítanak meg osztály nélküli útvonalakat; a kiszolgáló saját opciókezelése dönti el, mi kinek megy.

Ellenőrizze, mit fogad el a kliens

A kézzel címzett gép soha nem veszi fel ezt, mert nem kér bérletet. A kliensoldali támogatás is változó, ezért azon az operációs rendszeren teszteljen, amelyet valóban futtat, ahelyett hogy feltételezné, minden eszköz tiszteletben tartja a 121-es opciót. Erősítse meg azokkal, akiké a kiszolgálók, melyek statikus címűek. Azoknak a gépeknek saját útvonalbejegyzésekre van szükségük, különben egyszerűen nem vesznek részt.

A felügyelt DHCP-szolgáltatások egy másik korlát. Egyes felhőhálózatok nem engedik a rendszergazdáknak tetszőleges opciók közzétételét, és egy versengő DHCP-kiszolgáló ugyanabban a szegmensben rosszabb, mint ha egyáltalán nem lenne opció.

Ellenőrizze a bérletet, majd a keresést

Kérje meg a DHCP tulajdonosát a változtatás alkalmazására, majd újítsa meg a bérletet egy kliensen. A meglévő bérletek a régi konfigurációt tartják a megújításig, ezért az azonnali eredmény nem garantált.

Egy Linux-kliensen olvassa ki a tényleges útvonalakat, és erősítse meg mindkét bejegyzést:

ip -4 route
ip -4 route get 10.90.0.23

A kontextusfüggő keresésnek a medence útvonalát 192.168.50.2-en keresztül, az alapértelmezést pedig 192.168.50.1-on keresztül kell mutatnia. Ha hiányzik az alapértelmezés, akkor reprodukálta a fenti csapdát.

Aztán tesztelje a valódi forgalmat

Az útvonalak kiosztása nem a teljes útvonal. A külön átjárónak továbbra is kell továbbítás, a távoli partnerek tulajdonjoga és egy hozzáférési házirend, amely engedi a kiszolgálót, a DHCP pedig senkit nem hitelesít.

Végül tartson fenn eltávolítási tervet. A megtanult statikus útvonal nem vonja vissza magát, amikor a VPN leesik, ezért egy elavult következő ugrás még jóval a tunel eltűnése után is fekete lyukká teheti azt a prefixet.

Kapcsolódó cikkek