Ge LAN-värdar en VPN-returväg med DHCP-alternativ 121

Fjärranslutna VPN-klienter ansluter, LAN-servern svarar, och svaret lämnar nätet via den vanliga internetroutern och dör där. En server kan lagas med en statisk väg, men ett helt subnät av dem hanteras bättre där de redan får sin nätverkskonfiguration. DHCPv4-alternativ 121 distribuerar just den sortens destinationsväg, och det är den delen folk oftast gör fel på i samma stund de glömmer standardvägen. Symtomet är enkelriktad trafik: förfrågningar kommer in och svar försvinner.

Namnge de tre adresserna först

Ta ett konkret LAN: 192.168.50.0/24 med den vanliga standardroutern på 192.168.50.1 och en separat VPN-gateway på 192.168.50.2. Autentiserade fjärrklienter upptar 10.90.0.0/24.

Vägen varje deltagande värd behöver är 10.90.0.0/24 via 192.168.50.2. Destinationen är klientpoolen, och nästa hopp är gatewayens LAN-adress i stället för dess tunneladress.

Koda den som en klasslös statisk väg

Alternativ 121 bär par av prefix och nästa hopp, och RFC 3442 definierar både kodningen och det klientbeteende som följer. För en befintlig dnsmasq-instans som bara betjänar detta illustrativa LAN är konfigurationens form:

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

Det är ett fragment, inte en ny DHCP-tjänst. På en server som hanterar flera segment, avgränsa alternativet med de taggar eller den nätverkspolicy du redan använder. Ha den tidigare konfigurationen till hands, för att rulla tillbaka betyder ännu en lease-förnyelse, inte en omstart.

Tappa inte standardvägen

Det här är fällan. En klient som tar emot alternativ 121 måste ignorera det vanliga Router-alternativet, så att annonsera bara VPN-poolens väg kan lämna den värden helt utan standardväg. Maskinen ser fortfarande konfigurerad ut och tappar internet i tysthet. Användare beskriver det som att nätet ligger nere medan varje gränssnitt är uppe.

Ta med den avsedda standarden i samma lista, som fragmentet ovan gör. Behåll också det vanliga Router-alternativet för klienter som inte implementerar klasslösa vägar; serverns egen alternativhantering avgör vad som skickas till vem.

Kontrollera vad klienten accepterar

En värd med manuell adress fångar aldrig upp detta, eftersom den inte begär en lease. Klientstödet varierar också, så testa på det operativsystem du faktiskt kör i stället för att anta att varje enhet respekterar alternativ 121. Bekräfta med dem som äger servrarna vilka som har statisk adress. De värdarna behöver egna vägposter, annars deltar de helt enkelt inte.

Hanterade DHCP-tjänster är en annan gräns. Vissa molnnätverk låter inte administratörer publicera godtyckliga alternativ, och en konkurrerande DHCP-server i samma segment är värre än inget alternativ alls.

Verifiera leasen, sedan uppslaget

Låt DHCP-ägaren tillämpa ändringen och förnya sedan leasen på en klient. Befintliga leasar behåller den gamla konfigurationen tills de förnyas, så omedelbara resultat är inte garanterade.

På en Linux-klient, läs de faktiska vägarna och bekräfta båda posterna:

ip -4 route
ip -4 route get 10.90.0.23

Det kontextuella uppslaget bör visa poolens väg via 192.168.50.2 och standarden via 192.168.50.1. Saknas standarden har du återskapat fällan ovan.

Testa sedan det verkliga utbytet

Värddistribution är inte hela vägen. Den separata gatewayen behöver fortfarande vidarebefordran, ägarskap av fjärrparter och en åtkomstpolicy som tillåter servern, och DHCP autentiserar ingen.

Till sist, håll en borttagningsplan. En inlärd statisk väg drar sig inte tillbaka när VPN:en går ner, så ett inaktuellt nästa hopp kan göra det prefixet till ett svart hål långt efter att tunneln är borta.