Slik sender du bare ett privat subnett gjennom VPN

Ett privat subnett gjennom tunnelen og alt annet langs din vanlige vei er en liten forespørsel med mange måter å gjøre det galt på. Det er ikke avkrysningsboksen merket split tunneling som avgjør resultatet, men hvor beslutningen håndheves: i klientens egen rutetabell, i en rute serveren dytter ut, eller i en policy de to endene forhandler om. Velger du feil lag, får du enten en full tunnel du aldri ønsket, eller en rute inn i en tunnel som andre siden nekter å godta. Jeg bruker en test med tre betingelser før jeg åpner noen konfigurasjon, og velger deretter en av mekanismene nedenfor.

Tre betingelser som avgjør designet

For det første trenger du det nøyaktige prefikset og masken fra nettverkseieren. Nettet 10.x er ikke et prefiks; 10.20.0.0/16 er det. Bekreft at det ikke overlapper hjemme-LAN-et ditt, en Docker-bro eller en annen VPN du kjører, fordi en overlapping gjør ruten tvetydig og kjernen velger oppføringen du ikke mente.

For det andre, hvem som svarer på returtrafikken. Å rute en pakke inn i tunnelen bringer den bare til VPN-serveren. Hvis subnettet ligger bak en annen ruter som ikke har rute tilbake til klientpoolen din, må serveren maskere trafikken, eller den ruteren må lære poolen din. Ingen rute på klientsiden retter en manglende returvei.

For det tredje, håndhevelsespunktet. Noen klienter installerer en rute, og operativsystemet gjør resten. Andre forhandler om en policy, og en policy gatewayen ikke godtar gir ingen tunnel i det hele tatt: pakkene forkastes uten åpenbar feil. Finn ut hvilken av de to som er din før du skriver noe.

WireGuard: AllowedIPs er rutetabellen

På klienten lister AllowedIPs opp destinasjonene som får komme inn i tunnelen, og wg-quick gjør hver oppføring om til en vanlig rute. Klienthalvdelen av denne oppgaven er altså én linje.

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

Sammenlign nå serverens oppføring for samme klient. Den beskriver hva serveren vil sende til klienten, som vanligvis er klientens tunneladresse, ikke det private subnettet.

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

Å bytte om på de to er feilen jeg ser oftest. Å sette 10.20.0.0/16 under serverens peer-avsnitt erklærer at hele subnettet ligger bak den klienten, og det er et krav om site-til-site, ikke en tillatelse. Pakker som ikke passer med noen peers AllowedIPs forkastes i stillhet, så en feil oppføring ser nøyaktig ut som et brannmurproblem.

Hvis du styrer rutene selv, setter du Table = off under [Interface] og legger til ruten du vil ha. Da legges ingenting til automatisk, så ruten hører til det som reiser grensesnittet.

OpenVPN: dytt ut ruten, og sørg så for at den lander

På en vanlig server er endringen ett direktiv i serverkonfigurasjonen, ved siden av klientpoolen.

push "route 10.20.0.0 255.255.0.0"

Klienten legger den til når den kobler til. Feiltilstanden viser seg når samme profil også dytter ut redirect-gateway, eller når noen allerede har lagt til route-nopull: det første gjør økten til en full tunnel, det andre kaster hver utdyttet rute, også din.

En klient som trenger smal oppførsel mot en fulltunnel-server, bør ignorere bare de delene den ikke vil ha. I OpenVPN 2.4 og nyere finnes pull-filter nettopp for dette.

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

Hold adressefamiliene atskilt: en utdyttet IPv4-rute gjør ingenting for en intern tjeneste som løses til IPv6, og den tjenesten feiler over tunnelen mens alt annet ser fint ut.

Når det private subnettet ikke er på VPN-serveren men bak en annen klient, må serveren få beskjed. Legg til en fil per klient via client-config-dir som inneholder iroute 10.20.0.0 255.255.0.0, pluss den tilsvarende route så andre klienter lærer ruten. Uten iroute har serveren ingen grunn til å sende det prefikset ned gjennom nettopp den tunnelen.

IPsec: trafikkselektorene må være enige

Med IPsec er det ingen rute å dytte ut. De to endene forhandler om hvilke adresser som ligger inne i tunnelen, og trafikk utenfor de avtalte selektorene blir verken kryptert eller sendt gjennom den. På en strongSwan-klient er selektorene eksplisitte.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Hvis gatewayen er konfigurert med 0.0.0.0/0 på begge sider, reduserer IKEv2-innsnevring vanligvis child-SA-en til snittet mellom de to forslagene, som er det ønskede resultatet. Noen gatewayer avviser i stedet et forslag som ikke passer med deres konfigurerte selektorer, og loggen viser da en mislykket child-SA framfor en klage over ruting. Når det skjer, hører endringen til på gatewayen, fordi en klientrute ikke kan lage en tunnel for en selektor den andre siden ikke vil godta.

På Windows skjuler den innebygde klienten den samme beslutningen bak to innstillinger. Split tunneling må være på, og prefikset må registreres på profilen.

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

Det er registreringen av prefikset som gjør at det overlever en gjentilkobling, noe en håndlagt rute ikke gjør.

Hold endepunktet og DNS utenfor beslutningen

VPN-endepunktet må forbli tilgjengelig uten tunnelen, ellers kollapser tunnelen inn i seg selv. Når bare 10.20.0.0/16 rutes, er det automatisk, siden endepunktet er en offentlig adresse. På en fulltunnelprofil er det ikke det, og klienten trenger en eksplisitt vertsrute til endepunktet før tunnelen kommer opp.

DNS er en andre beslutning som en ruteutdytting ikke tar for deg. Interne navn løses vanligvis gjennom en resolver som bare det private nettet kan nå. Dytter serveren en DNS-server ut, går hvert navn gjennom den; gjør den ikke det, feiler interne navn enten eller løses offentlig til noe du ikke mente. Delt DNS holder ett søkedomene på den interne resolveren, men det avhenger av klientstøtte, så behandle det som en egen oppgave og ikke som en bivirkning av ruting.

Bekreft, start så på nytt og bekreft igjen

Tre undersøkelser dekker rutespørsmålet. Spør kjernen hvor en ekstern adresse ville havne, hent noe inne fra subnettet, og bekreft deretter at en vanlig offentlig forespørsel fortsatt går ut gjennom din normale tilkobling.

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

Den første linjen navngir et grensesnitt. Hvis den navngir det fysiske grensesnittet ditt, landet ruten aldri. På Windows svarer Find-NetRoute -RemoteIPAddress 10.20.5.7 på det samme spørsmålet, og den siste undersøkelsen bør fortsatt vise din vanlige adresse og ikke VPN-serverens.

Start så på nytt. Ruter lagt til for hånd forsvinner, mens ruter fra profilen, fra en utdyttet konfigurasjon eller fra AllowedIPs kommer tilbake. Hvis smal tilgang virker før omstarten og feiler etter, ligger feilen i hvordan tunnelen starter, ikke i ruten selv.

Før du kaller det ferdig, må du bekrefte fire ting: prefikset kom fra nettverkseieren og overlapper ingenting lokalt, returveien finnes eller en maskeringsregel erstatter den, mekanismen du konfigurerte er den som håndhever ruting på plattformen din, og de samme undersøkelsene består etter en ren omstart. Notatene til strongSwan om videresending er verdt å lese hvis returveien er den delen som fortsetter å feile.