Gje LAN-vertar ei VPN-returrute med DHCP-valet 121

Fjerne VPN-klientar koplar til, LAN-tenaren svarar, og svaret går ut gjennom den vanlege internettrutaren og døyr der. Ein tenar kan rettast med ei statisk rute, men eit heilt subnett av dei blir betre handsama der dei alt får nettverkskonfigurasjonen sin. DHCPv4-valet 121 fordeler nettopp den slags målrute, og det er den delen folk vanlegvis gjer feil i det augneblunken dei gløymer standarden. Symptomet er einvegstrafikk: førespurnader kjem inn, og svar forsvinn.

Namngje dei tre adressene fyrst

Ta eit konkret LAN: 192.168.50.0/24 med den vanlege standardrutaren på 192.168.50.1 og ein eigen VPN-port på 192.168.50.2. Autentiserte fjernklientar opptek 10.90.0.0/24.

Ruta kvar deltakande vert treng, er 10.90.0.0/24 via 192.168.50.2. Målet er klientbassenget, og neste hopp er LAN-adressa til porten framfor tunneladressa.

Kode henne som ei klasselaus statisk rute

Val 121 ber par av prefiks og neste hopp, og RFC 3442 definerer både kodinga og klientåtferda som følgjer. For ein eksisterande dnsmasq-instans som berre tener dette illustrerande LAN-et, er forma på konfigurasjonen:

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

Det er eit fragment, ikkje ei ny DHCP-teneste. På ein tenar som handsamar fleire segment, avgrens valet med taggane eller nettverkspolicyen du alt brukar. Hald den førre konfigurasjonen ved handa, for å rulle dette tilbake tyder endå ei lease-fornying, ikkje ein omstart.

Ikkje mist standardruta

Dette er fella. Ein klient som mottek val 121, må ignorere det vanlege Router-valet, så å annonsere berre ruta til VPN-bassenget kan la den verten stå heilt utan standardrute. Maskinen ser framleis konfigurert ut og mistar internett i det stille. Brukarar skildrar det som at nettet er nede medan kvar grensesnitt er oppe.

Ta med den tiltenkte standarden i same lista, slik fragmentet over gjer. Hald òg det vanlege Router-valet på plass, for klientar som ikkje implementerer klasselause ruter; tenaren si eiga valhandsaming avgjer kva som blir sendt til kven.

Sjekk kva klienten vil godta

Ein vert med manuell adresse fangar aldri opp dette, fordi han ikkje ber om ein lease. Klientstøtta varierer òg, så test på operativsystemet du faktisk køyrer i staden for å gå ut frå at kvar eining respekterer val 121. Stadfest med dei som eig desse tenarane kva som har statisk adresse. Dei vertane treng eigne ruteoppføringar, elles deltek dei rett og slett ikkje.

Administrerte DHCP-tenester er ei anna grense. Nokre skynettverk lèt ikkje administratorar publisere vilkårlege val, og ein konkurrerande DHCP-tenar i same segment er verre enn ingen val i det heile.

Stadfest leasen, deretter oppslaget

La DHCP-eigaren bruke endringa, og forny deretter leasen på ein klient. Eksisterande leasar held den gamle konfigurasjonen til dei blir fornya, så umiddelbare resultat er ikkje garanterte.

På ein Linux-klient, les dei faktiske rutene og stadfest begge oppføringane:

ip -4 route
ip -4 route get 10.90.0.23

Det kontekstuelle oppslaget skal vise ruta til bassenget gjennom 192.168.50.2 og standarden gjennom 192.168.50.1. Manglar standarden, har du attskapt fella over.

Test deretter den verkelege utvekslinga

Rutedistribusjon er ikkje heile vegen. Den separate porten treng framleis vidaresending, eigarskap til eksterne partar og ein tilgangspolicy som tillèt tenaren, og DHCP autentiserer ingen.

Til slutt, hald ein fjerningsplan. Ei lærd statisk rute trekkjer seg ikkje tilbake når VPN-en fell, så eit utdatert neste hopp kan gjere prefikset til eit svart hol lenge etter at tunnelen er borte.