Slik sender du berre eitt privat subnett gjennom VPN

Eitt privat subnett gjennom tunnelen og alt anna langs den vanlege vegen din er ein liten førespurnad med mange måtar å gjere det gale på. Det er ikkje avkryssingsboksen merkt split tunneling som avgjer resultatet, men kvar avgjerda blir handheva: i klienten si eiga rutetabell, i ei rute serveren dyttar ut, eller i ein policy dei to endane forhandlar om. Vel du feil lag, får du anten ein full tunnel du aldri ønskte, eller ei rute inn i ein tunnel som andre sida nektar å godta. Eg brukar ein test med tre vilkår før eg opnar nokon konfigurasjon, og vel deretter ein av mekanismane nedanfor.

Tre vilkår som avgjer designet

For det første treng du det nøyaktige prefikset og maska frå nettverkseigaren. Nettet 10.x er ikkje eit prefiks; 10.20.0.0/16 er det. Stadfest at det ikkje overlappar heime-LAN-et ditt, ei Docker-bru eller ein annan VPN du køyrer, fordi ein overlapping gjer ruta tvitydig og kjernen vel oppføringa du ikkje meinte.

For det andre, kven som svarar på returtrafikken. Å rute ein pakke inn i tunnelen bringar han berre til VPN-serveren. Liggr subnettet bak ein annan ruttar som ikkje har rute tilbake til klientpoolen din, må serveren maskere trafikken, eller den ruttaren må lære poolen din. Inga rute på klientsida rettar ein manglande returveg.

For det tredje, handhevingspunktet. Nokre klientar installerer ei rute, og operativsystemet gjer resten. Andre forhandlar om ein policy, og ein policy gatewayen ikkje godtek gir ingen tunnel i det heile: pakkane blir kasta utan openberr feil. Finn ut kva av dei to som er din før du skriv noko.

WireGuard: AllowedIPs er rutetabellen

På klienten listar AllowedIPs opp destinasjonane som får kome inn i tunnelen, og wg-quick gjer kvar oppføring om til ei vanleg rute. Klienthalvdelen av denne oppgåva er altså éi linje.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Samanlikn no oppføringa til serveren for same klient. Ho skildrar kva serveren vil sende til klienten, som vanlegvis er tunneladressa til klienten, ikkje det private subnettet.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Å byte om dei to er feilen eg ser oftast. Å setje 10.20.0.0/16 under peer-avsnittet til serveren erklærer at heile subnettet ligg bak den klienten, og det er eit krav om site-til-site, ikkje ei løyve. Pakkar som ikkje passar med AllowedIPs til nokon peer blir kasta i det stille, så ei feil oppføring ser nøyaktig ut som eit brannmurproblem.

Styrer du rutene sjølv, set Table = off under [Interface] og legg til ruta du vil ha. Då blir ingenting lagt til automatisk, så ruta høyrer til det som reiser grensesnittet.

OpenVPN: dytt ut ruta, og sørg så for at ho landar

På ein vanleg server er endringa eitt direktiv i serverkonfigurasjonen, ved sida av klientpoolen.

push "route 10.20.0.0 255.255.0.0"

Klienten legg ho til når han koplar til. Feiltilstanden viser seg når same profil også dyttar ut redirect-gateway, eller når nokon allereie har lagt til route-nopull: det første gjer økta til ein full tunnel, det andre kastar kvar utdytta rute, også di.

Ein klient som treng smal åtferd mot ein fulltunnel-server, bør ignorere berre dei delane han ikkje vil ha. I OpenVPN 2.4 og nyare finst pull-filter nettopp for dette.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Hald adressefamiliane åtskilde: ei utdytta IPv4-rute gjer ingenting for ein intern teneste som blir løyst til IPv6, og den tenesta feilar over tunnelen medan alt anna ser fint ut.

Når det private subnettet ikkje er på VPN-serveren men bak ein annan klient, må serveren få beskjed. Legg til ei fil per klient via client-config-dir som inneheld iroute 10.20.0.0 255.255.0.0, pluss den tilsvarande route så andre klientar lærer ruta. Utan iroute har serveren ingen grunn til å sende det prefikset ned gjennom nettopp den tunnelen.

IPsec: trafikkselektorane må vere samde

Med IPsec er det inga rute å dytte ut. Dei to endane forhandlar om kva adresser som ligg inne i tunnelen, og trafikk utanfor dei avtalte selektorane blir korkje kryptert eller send gjennom han. På ein strongSwan-klient er selektorane eksplisitte.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Er gatewayen konfigurert med 0.0.0.0/0 på begge sider, reduserer IKEv2-innsnevring vanlegvis child-SA-en til snittet mellom dei to forslaga, som er det ønska resultatet. Nokre gatewayar avviser i staden eit forslag som ikkje passar med dei konfigurerte selektorane deira, og loggen viser då ein mislukka child-SA framfor ei klage over ruting. Når det skjer, høyrer endringa til på gatewayen, fordi ei klientrute ikkje kan lage ein tunnel for ein selektor den andre sida ikkje vil godta.

På Windows skjuler den innebygde klienten den same avgjerda bak to innstillingar. Split tunneling må vere på, og prefikset må registrerast på profilen.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Det er registreringa av prefikset som gjer at det overlever ein gjentilkopling, noko ei handlagd rute ikkje gjer.

Hald endepunktet og DNS utanfor avgjerda

VPN-endepunktet må halde fram med å vere tilgjengeleg utan tunnelen, elles kollapsar tunnelen inn i seg sjølv. Når berre 10.20.0.0/16 blir ruta, er det automatisk, sidan endepunktet er ei offentleg adresse. På ein fulltunnelprofil er det ikkje det, og klienten treng ei eksplisitt vertsrute til endepunktet før tunnelen kjem opp.

DNS er ei andre avgjerd som ein rutedytt ikkje tek for deg. Interne namn blir vanlegvis løyste gjennom ein resolver som berre det private nettet kan nå. Dyttar serveren ein DNS-server ut, går kvart namn gjennom han; gjer han ikkje det, feilar interne namn anten eller blir løyste offentleg til noko du ikkje meinte. Delt DNS held eitt søkjedomene på den interne resolveren, men det avheng av klientstøtte, så handsame det som ei eiga oppgåve og ikkje som ei biverknad av ruting.

Stadfest, start så på nytt og stadfest igjen

Tre undersøkingar dekkjer rutespørsmålet. Spør kjernen kvar ei ekstern adresse ville hamne, hent noko inne frå subnettet, og stadfest deretter at ein vanleg offentleg førespurnad framleis går ut gjennom den normale tilkoplinga di.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Den første linja namngir eit grensesnitt. Namngir ho det fysiske grensesnittet ditt, landa ruta aldri. På Windows svarar Find-NetRoute -RemoteIPAddress 10.20.5.7 på det same spørsmålet, og den siste undersøkinga bør framleis vise den vanlege adressa di og ikkje VPN-serveren si.

Start så på nytt. Ruter lagde til for hand forsvinn, medan ruter frå profilen, frå ein utdytta konfigurasjon eller frå AllowedIPs kjem tilbake. Verkar smal tilgang før omstarten og feilar etter, ligg feilen i korleis tunnelen startar, ikkje i ruta sjølv.

Før du kallar det ferdig, må du stadfeste fire ting: prefikset kom frå nettverkseigaren og overlappar ingenting lokalt, returvegen finst eller ei maskeringsregel erstattar han, mekanismen du konfigurerte er den som handhevar ruting på plattformen din, og dei same undersøkingane går gjennom etter ein rein omstart. Notata til strongSwan om vidaresending er verdt å lese om returvegen er den delen som held fram med å feile.