Přidejte hostům v LAN zpáteční trasu VPN přes DHCP volbu 121

Vzdálení klienti VPN se připojí, server v LAN odpoví a odpověď odejde přes běžný internetový router a tam zahyne. Jeden server lze opravit statickou trasou, ale celou podsíť jich je lepší řešit tam, kde už dostávají svou síťovou konfiguraci. Volba 121 DHCPv4 distribuuje přesně takový typ trasy k cíli a to je část, kterou lidé obvykle pokazí ve chvíli, kdy zapomenou výchozí trasu. Příznakem je jednosměrný provoz: požadavky dorazí a odpovědi zmizí.

Nejprve pojmenujte tři adresy

Vezměte konkrétní LAN: 192.168.50.0/24 s běžným výchozím routerem na 192.168.50.1 a samostatnou branou VPN na 192.168.50.2. Ověření vzdálení klienti obsazují 10.90.0.0/24.

Trasa, kterou každý zúčastněný host potřebuje, je 10.90.0.0/24 via 192.168.50.2. Cílem je fond klientů a dalším skokem je adresa brány v LAN, nikoli její adresa v tunelu.

Zakódujte ji jako beztřídní statickou trasu

Volba 121 nese dvojice prefixu a dalšího skoku a RFC 3442 definuje jak kódování, tak chování klienta, které z toho vyplývá. Pro existující instanci dnsmasq obsluhující pouze tuto ilustrativní LAN má konfigurace 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, ne nová služba DHCP. Na serveru obsluhujícím několik segmentů omezíte volbu značkami nebo síťovou politikou, kterou už používáte. Mějte předchozí konfiguraci po ruce, protože vrácení zpět znamená další obnovení lease, ne restart.

Neztratíte výchozí trasu

To je past. Klient, který obdrží volbu 121, musí ignorovat běžnou volbu Router, takže inzerování pouze trasy fondu VPN může nechat toho hosta úplně bez výchozí trasy. Stroj stále vypadá nakonfigurovaně a tiše ztrácí internet. Uživatelé to popisují jako výpadek sítě, i když jsou všechna rozhraní nahoře.

Zařaďte zamýšlenou výchozí trasu do stejného seznamu, jak to dělá fragment výše. Ponechte také běžnou volbu Router pro klienty, kteří beztřídní trasy neimplementují; o tom, co se komu pošle, rozhoduje vlastní zpracování voleb na serveru.

Zjistěte, co klient přijme

Host s ručně přidělenou adresou to nikdy nezachytí, protože nežádá o lease. Podpora u klientů se také liší, proto testujte na operačním systému, který skutečně používáte, místo abyste předpokládali, že každé zařízení volbu 121 respektuje. Ověřte u vlastníků těch serverů, které z nich mají statickou adresu. Tyto hosty potřebují vlastní záznamy tras, jinak se prostě nezúčastní.

Spravované služby DHCP jsou další limit. Některé cloudové sítě nedovolí správcům publikovat libovolné volby a konkurenční server DHCP ve stejném segmentu je horší než žádná volba.

Ověřte lease, pak vyhledání

Nechte vlastníka DHCP změnu použít a poté obnovte lease na klientovi. Stávající lease si drží starou konfiguraci, dokud se neobnoví, takže okamžitý výsledek není zaručen.

Na klientovi s Linuxem přečtěte skutečné trasy a potvrďte oba záznamy:

ip -4 route
ip -4 route get 10.90.0.23

Kontextové vyhledání by mělo ukázat trasu fondu přes 192.168.50.2 a výchozí přes 192.168.50.1. Pokud výchozí chybí, reprodukovali jste past výše.

Potom otestujte skutečnou výměnu

Distribuce tras není celá cesta. Samostatná brána stále potřebuje předávání, vlastnictví vzdálených peerů a přístupovou politiku, která server povoluje, a DHCP nikoho neautentizuje.

Nakonec mějte plán odstranění. Naučená statická trasa se sama neodvolá, když VPN spadne, takže zastaralý další skok může ten prefix proměnit v černou díru dlouho poté, co tunel zmizel.