Daj hostom w LAN trasę powrotną VPN dzięki opcji 121 DHCP

Zdalni klienci VPN łączą się, serwer LAN odpowiada, a odpowiedź wychodzi przez zwykły router internetowy i tam ginie. Jeden serwer da się naprawić trasą statyczną, ale całą ich podsieć lepiej obsłużyć tam, gdzie już dostają swoją konfigurację sieciową. Opcja 121 DHCPv4 rozprowadza dokładnie taki rodzaj trasy docelowej, i to jest ta część, którą ludzie zwykle psują w chwili, gdy zapomną o domyślnej. Objawem jest ruch jednokierunkowy: żądania docierają, a odpowiedzi znikają.

Najpierw nazwij trzy adresy

Weź konkretny LAN: 192.168.50.0/24 ze zwykłym routerem domyślnym na 192.168.50.1 i osobną bramą VPN na 192.168.50.2. Uwierzytelnieni zdalni klienci zajmują 10.90.0.0/24.

Trasa, której potrzebuje każdy uczestniczący host, to 10.90.0.0/24 via 192.168.50.2. Miejscem docelowym jest pula klientów, a następnym skokiem jest adres LAN bramy, a nie jej adres tunelowy.

Zakoduj ją jako bezklasową trasę statyczną

Opcja 121 przenosi pary prefiksu i następnego skoku, a RFC 3442 definiuje zarówno kodowanie, jak i wynikające z niego zachowanie klienta. Dla istniejącej instancji dnsmasq obsługującej tylko ten przykładowy LAN kształt konfiguracji jest taki:

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

To fragment, a nie nowa usługa DHCP. Na serwerze obsługującym kilka segmentów ogranicz opcję tagami lub polityką sieciową, których już używasz. Miej pod ręką poprzednią konfigurację, bo wycofanie oznacza kolejne odnowienie dzierżawy, a nie restart.

Nie zgub trasy domyślnej

To jest pułapka. Klient, który otrzyma opcję 121, musi ignorować zwykłą opcję Router, więc ogłaszanie tylko trasy puli VPN może zostawić ten host całkowicie bez trasy domyślnej. Maszyna nadal wygląda na skonfigurowaną i po cichu traci internet. Użytkownicy opisują to jako awarię sieci, choć wszystkie interfejsy są włączone.

Uwzględnij zamierzoną trasę domyślną na tej samej liście, jak robi to fragment powyżej. Zostaw też zwykłą opcję Router dla klientów, które nie implementują tras bezklasowych; o tym, co komu wysłać, decyduje własna obsługa opcji po stronie serwera.

Sprawdź, co klient przyjmie

Host z ręcznie ustawionym adresem nigdy tego nie podchwyci, bo nie prosi o dzierżawę. Wsparcie klientów też się różni, więc testuj na systemie, którego naprawdę używasz, zamiast zakładać, że każde urządzenie respektuje opcję 121. Potwierdź u właścicieli tych serwerów, które mają adres statyczny. Te hosty potrzebują własnych wpisów tras, inaczej po prostu nie wezmą udziału.

Usługi zarządzanego DHCP to kolejna granica. Niektóre sieci chmurowe nie pozwalają administratorom publikować dowolnych opcji, a konkurencyjny serwer DHCP w tym samym segmencie jest gorszy niż brak jakiejkolwiek opcji.

Zweryfikuj dzierżawę, potem wyszukanie

Poproś właściciela DHCP o zastosowanie zmiany, a następnie odnowij dzierżawę na kliencie. Istniejące dzierżawy zachowują starą konfigurację do odnowienia, więc natychmiastowe wyniki nie są gwarantowane.

Na kliencie Linux odczytaj rzeczywiste trasy i potwierdź oba wpisy:

ip -4 route
ip -4 route get 10.90.0.23

Wyszukanie kontekstowe powinno pokazać trasę puli przez 192.168.50.2 i domyślną przez 192.168.50.1. Jeśli brakuje domyślnej, odtworzyłeś pułapkę opisaną powyżej.

Potem sprawdź prawdziwą wymianę

Rozprowadzanie tras to nie cała droga. Osobna brama nadal potrzebuje przekazywania, własności zdalnych partnerów i polityki dostępu, która dopuszcza serwer, a DHCP nikogo nie uwierzytelnia.

Na koniec miej plan usunięcia. Nauczona trasa statyczna nie wycofuje się sama, gdy VPN padnie, więc nieaktualny następny skok może zamienić ten prefiks w czarną dziurę długo po zniknięciu tunelu.