Dajte hostom v LAN spätnú trasu VPN cez DHCP voľbu 121

Vzdialení klienti VPN sa pripoja, server v LAN odpovie a odpoveď odíde cez bežný internetový router a tam zahynie. Jeden server sa dá opraviť statickou trasou, ale celú ich podsieť je lepšie riešiť tam, kde už dostávajú svoju sieťovú konfiguráciu. Voľba 121 DHCPv4 distribuuje presne taký typ trasy k cieľu, a to je časť, ktorú ľudia zvyčajne pokazia vo chvíli, keď zabudnú predvolenú trasu. Príznakom je jednosmerná premávka: požiadavky prídu a odpovede zmiznú.

Najprv pomenujte tri adresy

Vezmite konkrétnu LAN: 192.168.50.0/24 s bežným predvoleným routerom na 192.168.50.1 a samostatnou bránou VPN na 192.168.50.2. Overení vzdialení klienti obsadzujú 10.90.0.0/24.

Trasa, ktorú potrebuje každý zúčastnený host, je 10.90.0.0/24 via 192.168.50.2. Cieľom je fond klientov a ďalším skokom je adresa brány v LAN, nie jej adresa v tuneli.

Zakódujte ju ako beztriednu statickú trasu

Voľba 121 nesie dvojice prefixu a ďalšieho skoku a RFC 3442 definuje ako kódovanie, tak správanie klienta, ktoré z toho vyplýva. Pre existujúcu inštanciu dnsmasq obsluhujúcu iba túto ilustratívnu LAN má konfigurácia tento tvar:

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

To je fragment, nie nová služba DHCP. Na serveri obsluhujúcom niekoľko segmentov obmedzte voľbu značkami alebo sieťovou politikou, ktorú už používate. Majte predchádzajúcu konfiguráciu poruke, pretože vrátenie späť znamená ďalšie obnovenie lease, nie reštart.

Nestratíte predvolenú trasu

To je pasca. Klient, ktorý dostane voľbu 121, musí ignorovať bežnú voľbu Router, takže inzerovanie iba trasy fondu VPN môže nechať toho hosta úplne bez predvolenej trasy. Stroj stále vyzerá nakonfigurovaný a potichu stráca internet. Používatelia to opisujú ako výpadok siete, hoci všetky rozhrania sú hore.

Zaradte zamýšľanú predvolenú trasu do toho istého zoznamu, ako to robí fragment vyššie. Ponechajte aj bežnú voľbu Router pre klientov, ktorí beztriedne trasy neimplementujú; o tom, čo sa komu pošle, rozhoduje vlastné spracovanie volieb na serveri.

Zistite, čo klient prijme

Host s ručne pridelenou adresou to nikdy nezachytí, pretože nežiada o lease. Podpora u klientov sa tiež líši, preto testujte na operačnom systéme, ktorý skutočne používate, namiesto predpokladu, že každé zariadenie rešpektuje voľbu 121. Overte u vlastníkov tých serverov, ktoré z nich majú statickú adresu. Tie hosty potrebujú vlastné záznamy trás, inak sa jednoducho nezúčastnia.

Spravované služby DHCP sú ďalší limit. Niektoré cloudové siete nedovolia správcom publikovať ľubovoľné voľby a konkurenčný server DHCP v tom istom segmente je horší ako žiadna voľba.

Overte lease, potom vyhľadanie

Nechajte vlastníka DHCP zmenu použiť a potom obnovte lease na klientovi. Existujúce lease si držia starú konfiguráciu, kým sa neobnovia, takže okamžitý výsledok nie je zaručený.

Na klientovi s Linuxom prečítajte skutočné trasy a potvrďte oba záznamy:

ip -4 route
ip -4 route get 10.90.0.23

Kontextové vyhľadanie by malo ukázať trasu fondu cez 192.168.50.2 a predvolenú cez 192.168.50.1. Ak predvolená chýba, reprodukovali ste pascu vyššie.

Potom otestujte skutočnú výmenu

Distribúcia trás nie je celá cesta. Samostatná brána stále potrebuje preposielanie, vlastníctvo vzdialených peerov a prístupovú politiku, ktorá server povoľuje, a DHCP nikoho neautentizuje.

Nakoniec majte plán odstránenia. Naučená statická trasa sa sama neodvolá, keď VPN padne, takže zastaraný ďalší skok môže ten prefix premeniť na čiernu dieru dávno po tom, čo tunel zmizol.