Giv LAN-værter en VPN-returrute med DHCP-tilvalg 121

Fjerne VPN-klienter opretter forbindelse, LAN-serveren svarer, og svaret forlader netværket gennem den almindelige internetrouter og dør der. Én server kan rettes med en statisk rute, men et helt undernet af dem håndteres bedre der, hvor de allerede får deres netværkskonfiguration. DHCPv4-tilvalg 121 uddeler netop den slags destinationsrute, og det er den del, folk normalt får galt, i det øjeblik de glemmer standarden. Symptomet er ensrettet trafik: forespørgsler ankommer, og svar forsvinder.

Navngiv de tre adresser først

Tag et konkret LAN: 192.168.50.0/24 med den normale standardrouter på 192.168.50.1 og en separat VPN-gateway på 192.168.50.2. Godkendte fjernklienter besætter 10.90.0.0/24.

Den rute, hver deltagende vært har brug for, er 10.90.0.0/24 via 192.168.50.2. Destinationen er klientpuljen, og næste hop er gatewayens LAN-adresse frem for dens tunneladresse.

Kod den som en klasseløs statisk rute

Tilvalg 121 bærer præfiks- og næste-hop-par, og RFC 3442 definerer både kodningen og den klientadfærd, der følger. For en eksisterende dnsmasq-instans, der kun betjener dette illustrative LAN, er konfigurationsformen:

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, der håndterer flere segmenter, skal du afgrænse tilvalget med de tags eller den netværkspolitik, du allerede bruger. Hav den tidligere konfiguration ved hånden, for at rulle det tilbage betyder endnu en fornyelse af lejen, ikke en genstart.

Mist ikke standardruten

Det er fælden. En klient, der modtager tilvalg 121, skal ignorere det almindelige Router-tilvalg, så hvis man kun annoncerer VPN-puljens rute, kan det efterlade den vært helt uden standardrute. Maskinen ser stadig konfigureret ud og mister lydløst internettet. Brugere beskriver det som, at netværket er nede, mens alle grænseflader er oppe.

Medtag den tilsigtede standard på samme liste, som fragmentet ovenfor gør. Behold også det almindelige Router-tilvalg for klienter, der ikke implementerer klasseløse ruter; serverens egen tilvalgshåndtering afgør, hvad der sendes til hvem.

Kontroller, hvad klienten vil acceptere

En vært med manuel adresse fanger aldrig dette, fordi den ikke beder om en leje. Klientunderstøttelse varierer også, så test på det styresystem, du faktisk kører, i stedet for at antage, at hver enhed respekterer tilvalg 121. Bekræft med dem, der ejer de servere, hvilke der har statisk adresse. De værter har brug for deres egne ruteindgange, ellers deltager de simpelthen ikke.

Administrerede DHCP-tjenester er en anden grænse. Nogle cloudnetværk lader ikke administratorer offentliggøre vilkårlige tilvalg, og en konkurrerende DHCP-server på samme segment er værre end slet intet tilvalg.

Verificer lejen, derefter opslaget

Lad DHCP-ejeren anvende ændringen, og forny derefter lejen på en klient. Eksisterende lejer beholder den gamle konfiguration, indtil de fornyes, så øjeblikkelige resultater er ikke garanteret.

På en Linux-klient skal du læse de faktiske ruter og bekræfte begge indgange:

ip -4 route
ip -4 route get 10.90.0.23

Det kontekstuelle opslag bør vise puljens rute gennem 192.168.50.2 og standarden gennem 192.168.50.1. Hvis standarden mangler, har du genskabt fælden ovenfor.

Test derefter den virkelige udveksling

Rutedistribution er ikke hele vejen. Den separate gateway har stadig brug for videresendelse, ejerskab af fjernpeers og en adgangspolitik, der tillader serveren, og DHCP godkender ingen.

Til sidst, hav en fjernelsesplan. En lært statisk rute trækker sig ikke selv tilbage, når VPN'en går ned, så et forældet næste hop kan gøre det præfiks til et sort hul længe efter, at tunnelen er væk.