Gi LAN-verter en VPN-returrute med DHCP-alternativ 121

Eksterne VPN-klienter kobler til, LAN-serveren svarer, og svaret forlater nettet gjennom den vanlige internettruteren og dør der. Én server kan rettes med en statisk rute, men et helt subnett av dem håndteres bedre der de allerede får nettverkskonfigurasjonen sin. DHCPv4-alternativ 121 distribuerer nettopp den typen destinasjonsrute, og det er den delen folk vanligvis gjør feil i det øyeblikket de glemmer standarden. Symptomet er ensrettet trafikk: forespørsler kommer inn, og svar forsvinner.

Navngi de tre adressene først

Ta et konkret LAN: 192.168.50.0/24 med den vanlige standardruteren på 192.168.50.1 og en egen VPN-gateway på 192.168.50.2. Autentiserte fjernklienter opptar 10.90.0.0/24.

Ruten hver deltakende vert trenger, er 10.90.0.0/24 via 192.168.50.2. Destinasjonen er klientpoolen, og neste hopp er gatewayens LAN-adresse fremfor tunneladressen.

Kod den som en klasseløs statisk rute

Alternativ 121 bærer par av prefiks og neste hopp, og RFC 3442 definerer både kodingen og klientatferden som følger. For en eksisterende dnsmasq-instans som bare betjener dette illustrative LAN-et, er konfigurasjonsformen:

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

Det er et fragment, ikke en ny DHCP-tjeneste. På en server som håndterer flere segmenter, avgrens alternativet med taggene eller nettverkspolicyen du allerede bruker. Ha den forrige konfigurasjonen for hånden, for å rulle dette tilbake betyr enda en lease-fornyelse, ikke en omstart.

Ikke mist standardruten

Dette er fellen. En klient som mottar alternativ 121, må ignorere det vanlige Router-alternativet, så å annonsere bare VPN-poolens rute kan la den verten stå helt uten standardrute. Maskinen ser fortsatt konfigurert ut og mister internett i stillhet. Brukere beskriver det som at nettet er nede mens hvert grensesnitt er oppe.

Ta med den tiltenkte standarden i samme liste, slik fragmentet over gjør. Behold også det vanlige Router-alternativet, for klienter som ikke implementerer klasseløse ruter; serverens egen alternativhåndtering avgjør hva som sendes til hvem.

Sjekk hva klienten vil godta

En vert med manuell adresse fanger aldri opp dette, fordi den ikke ber om en lease. Klientstøtten varierer også, så test på operativsystemet du faktisk kjører i stedet for å anta at hver enhet respekterer alternativ 121. Bekreft med dem som eier disse serverne hvilke som har statisk adresse. De vertene trenger egne ruteoppføringer, ellers deltar de rett og slett ikke.

Administrerte DHCP-tjenester er en annen grense. Noen skynettverk lar ikke administratorer publisere vilkårlige alternativer, og en konkurrerende DHCP-server i samme segment er verre enn ingen alternativ i det hele tatt.

Verifiser leasen, deretter oppslaget

La DHCP-eieren bruke endringen, og forny deretter leasen på en klient. Eksisterende leaser beholder den gamle konfigurasjonen til de fornyes, så umiddelbare resultater er ikke garantert.

På en Linux-klient, les de faktiske rutene og bekreft begge oppføringene:

ip -4 route
ip -4 route get 10.90.0.23

Det kontekstuelle oppslaget skal vise poolens rute gjennom 192.168.50.2 og standarden gjennom 192.168.50.1. Hvis standarden mangler, har du gjenskapt fellen over.

Test deretter den virkelige utvekslingen

Rutedistribusjon er ikke hele veien. Den separate gatewayen trenger fortsatt videresending, eierskap til eksterne parter og en tilgangspolicy som tillater serveren, og DHCP autentiserer ingen.

Til slutt, ha en fjerningsplan. En lært statisk rute trekker seg ikke tilbake når VPN-en går ned, så et utdatert neste hopp kan gjøre prefikset til et svart hull lenge etter at tunnelen er borte.