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

Fjernklienter for VPN kobler seg til, LAN-serveren svarer, og svaret forlater nettet gjennom den vanlige internettrouteren og dør der. En enkelt server kan fikses med en statisk rute, men et helt subnett av dem håndteres bedre der de allerede henter nettverkskonfigurasjonen sin. DHCPv4-alternativ 121 deler ut nettopp en slik destinasjonsrute, og dette er den delen folk oftest gjør feil på idet de glemmer standardruten. Symptomet er trafikk i én retning: forespørsler kommer inn, og svar forsvinner.

Navngi de tre adressene først

Ta et konkret LAN: 192.168.50.0/24 med den normale standardrouteren på 192.168.50.1 og en separat VPN-gateway på 192.168.50.2. Autentiserte fjernklienter fyller 10.90.0.0/24.

Ruten som hver deltakende vert trenger, er 10.90.0.0/24 via 192.168.50.2. Målet er klientpoolen, og neste hopp er gatewayens LAN-adresse, ikke tunneladressen.

Kod den som en klasseløs statisk rute

Alternativ 121 frakter par med prefiks og neste hopp, og RFC 3442 fastsetter både kodingen og klientatferden som følger av den. For en eksisterende dnsmasq-instans som kun betjener dette eksempel-LAN-et, ser konfigurasjonen slik ut:

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

Dette er et fragment, ikke en ny DHCP-tjeneste. På en server som betjener flere segmenter, begrenser du alternativet med taggene eller nettverkspolicyen du allerede bruker. Ha den forrige konfigurasjonen tilgjengelig, siden en tilbakerulling betyr nok en fornyelse av leien, ikke en omstart.

Ikke mist standardruten

Her ligger fellen. En klient som mottar alternativ 121, skal se bort fra det vanlige Router-alternativet, så hvis du bare annonserer ruten til VPN-poolen, kan den verten bli stående uten standardrute i det hele tatt. Maskinen ser fortsatt konfigurert ut, men mister internett uten et ord. Brukerne kaller det nedetid i nettet mens alle grensesnitt er oppe.

Ta med den tiltenkte standardruten i samme liste, slik fragmentet ovenfor gjør. La også det vanlige Router-alternativet bli stående, for klienter som ikke støtter klasseløse ruter; det er serverens egen behandling av alternativer som avgjør hva som sendes til hvem.

Sjekk hva klienten godtar

En vert med manuelt satt adresse får aldri med seg dette, fordi den ikke ber om en leie. Også klientstøtten varierer, så test på operativsystemet du faktisk bruker i stedet for å regne med at alle enheter følger alternativ 121. Sjekk med eierne av disse serverne hvilke som har statisk adresse. Slike verter trenger egne ruteoppføringer, ellers deltar de rett og slett ikke.

Administrerte DHCP-tjenester er en annen begrensning. Enkelte skynettverk tillater ikke at administratorer publiserer vilkårlige alternativer, og en konkurrerende DHCP-server i samme segment er verre enn ingen alternativ i det hele tatt.

Kontroller leien, så oppslaget

La DHCP-eieren gjennomføre endringen, og forny deretter leien på en klient. Eksisterende leier beholder den gamle konfigurasjonen helt til de fornyes, så umiddelbare resultater er ikke gitt.

På en Linux-klient leser du de faktiske rutene og bekrefter begge oppføringene:

ip -4 route
ip -4 route get 10.90.0.23

Det kontekstuelle oppslaget skal vise ruten til poolen via 192.168.50.2 og standardruten via 192.168.50.1. Mangler standardruten, har du gjenskapt fellen ovenfor.

Deretter tester du den virkelige utvekslingen

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

Til slutt bør du ha en plan for fjerning. En innlært statisk rute trekker seg ikke tilbake når VPN-en faller, så et utdatert neste hopp kan gjøre prefikset til et svart hull lenge etter at tunnelen er borte.