Sådan sender du kun ét privat undernet gennem VPN-forbindelsen

Ét privat undernet gennem tunnelen og alt andet ad din normale vej er en lille anmodning med mange måder at gøre det forkert på. Det er ikke afkrydsningsfeltet med navnet split tunneling, der afgør resultatet, men hvor beslutningen håndhæves: klientens egen rutetabel, en rute som serveren skubber ud, eller en politik som de to ender forhandler. Vælger du det forkerte lag, får du enten en fuld tunnel, du aldrig ønskede, eller en rute ind i en tunnel, som den anden side nægter at acceptere. Jeg bruger en test med tre betingelser, før jeg åbner nogen konfiguration, og vælger derefter en af mekanismerne nedenfor.

Tre betingelser, der afgør designet

For det første har du brug for det præcise præfiks og den præcise maske fra netværksejeren. Netværket 10.x er ikke et præfiks; 10.20.0.0/16 er. Bekræft, at det ikke overlapper dit hjemme-LAN, en Docker-bro eller en anden VPN, du kører, fordi et overlap gør ruten tvetydig, og kernen vælger den post, du ikke havde tænkt på.

For det andet, hvem besvarer returtrafikken. At rute en pakke ind i tunnelen bringer den kun til VPN-serveren. Hvis undernettet ligger bag en anden router, som ikke har en rute tilbage til din klientpulje, skal serveren maskere trafikken, eller også skal den router lære din pulje. Ingen rute på klientsiden retter en manglende returvej.

For det tredje, håndhævelsespunktet. Nogle klienter installerer en rute, og operativsystemet klarer resten. Andre forhandler en politik, og en politik som gatewayen ikke accepterer, giver slet ingen tunnel: pakker kasseres uden nogen tydelig fejl. Find ud af, hvilken af de to du har, før du skriver noget.

WireGuard: AllowedIPs er rutetabellen

På klienten angiver AllowedIPs de destinationer, der må komme ind i tunnelen, og wg-quick gør hver post til en almindelig rute. Klienthalvdelen af denne opgave er altså én linje.

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

Sammenlign nu serverens post for den samme klient. Den beskriver, hvad serveren sender til klienten, hvilket normalt er klientens tunneladresse, ikke det private undernet.

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

At bytte om på de to er den fejl, jeg ser oftest. At sætte 10.20.0.0/16 under serverens peer-afsnit erklærer, at hele undernettet ligger bag den klient, hvilket er et krav om site-til-site og ikke en tilladelse. Pakker, der ikke matcher nogen peers AllowedIPs, kasseres i stilhed, så en forkert post ligner præcis et firewallproblem.

Hvis du selv styrer ruterne, sæt Table = off under [Interface] og tilføj den rute, du vil have. Så tilføjes intet automatisk, og ruten hører derfor til det, der rejser grænsefladen.

OpenVPN: skub ruten ud, og sørg så for at den lander

På en normal server er ændringen ét direktiv i serverkonfigurationen, ved siden af klientpuljen.

push "route 10.20.0.0 255.255.0.0"

Klienten tilføjer den, når den forbinder. Fejltilstanden viser sig, når samme profil også skubber redirect-gateway ud, eller når nogen allerede har tilføjet route-nopull: det første gør sessionen til en fuld tunnel, og det andet smider hver udskubbet rute væk, inklusive din.

En klient, der har brug for smal adfærd mod en fuldtunnel-server, bør ignorere netop de dele, den ikke vil have. I OpenVPN 2.4 og nyere findes pull-filter netop til det.

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

Hold adressefamilier adskilt: en udskubbet IPv4-rute gør intet for en intern tjeneste, der opløses til IPv6, og den tjeneste fejler over tunnelen, mens alt andet ser fint ud.

Når det private undernet ikke er på VPN-serveren, men bag en anden klient, skal serveren have besked. Tilføj en fil for hver klient via client-config-dir med iroute 10.20.0.0 255.255.0.0, plus den matchende route, så andre klienter lærer ruten. Uden iroute har serveren ingen grund til at sende det præfiks ned gennem netop den tunnel.

IPsec: trafikselektorerne skal være enige

Med IPsec er der ingen rute at skubbe ud. De to ender forhandler, hvilke adresser der ligger inde i tunnelen, og trafik uden for de aftalte selektorer bliver hverken krypteret eller sendt gennem den. På en strongSwan-klient er selektorerne eksplicitte.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Hvis gatewayen er konfigureret med 0.0.0.0/0 på begge sider, reducerer IKEv2-indsnævring normalt child-SA'en til snitfladen mellem de to forslag, hvilket er det ønskede resultat. Nogle gatewayer afviser i stedet et forslag, der ikke matcher deres konfigurerede selektorer, og loggen viser så en mislykket child-SA frem for en klage over routing. Når det sker, hører ændringen til på gatewayen, fordi en klientrute ikke kan skabe en tunnel for en selektor, som den anden side ikke vil acceptere.

På Windows skjuler den indbyggede klient den samme beslutning bag to indstillinger. Split tunneling skal være slået til, og præfikset skal være registreret på profilen.

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

Det er registreringen af præfikset, der gør, at det overlever en genopkobling, hvilket en håndtilføjet rute ikke gør.

Hold endepunktet og DNS uden for beslutningen

VPN-endepunktet skal forblive tilgængeligt uden tunnelen, ellers kollapser tunnelen ind i sig selv. Når kun 10.20.0.0/16 routes, er det automatisk, da endepunktet er en offentlig adresse. På en fuldtunnelprofil er det ikke tilfældet, og klienten har brug for en eksplicit værtsrute til endepunktet, før tunnelen rejses.

DNS er en anden beslutning, som en ruteudskubning ikke træffer for dig. Interne navne opløses normalt gennem en resolver, som kun det private netværk kan nå. Skubber serveren en DNS-server ud, går hvert navn gennem den; gør den ikke, fejler interne navne enten eller opløses offentligt til noget, du ikke havde tænkt på. Delt DNS holder ét søgedomæne på den interne resolver, men det afhænger af klientunderstøttelse, så behandl det som sin egen opgave frem for en bivirkning af routing.

Bekræft, genstart så og bekræft igen

Tre undersøgelser dækker routing-spørgsmålet. Spørg kernen, hvor en fjern adresse ville havne, hent noget inde fra undernettet, og bekræft derefter, at en almindelig offentlig anmodning stadig forlader din normale forbindelse.

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

Den første linje navngiver en grænseflade. Hvis den navngiver din fysiske grænseflade, landede ruten aldrig. På Windows svarer Find-NetRoute -RemoteIPAddress 10.20.5.7 på det samme spørgsmål, og den sidste undersøgelse bør stadig vise din almindelige adresse frem for VPN-serverens.

Genstart så. Ruter, der er tilføjet i hånden, forsvinder, mens ruter fra profilen, fra en udskubbet konfiguration eller fra AllowedIPs kommer tilbage. Hvis smal adgang virker før genstarten og fejler efter, ligger fejlen i, hvordan tunnelen starter, ikke i ruten selv.

Før du kalder det færdigt, skal du bekræfte fire ting: præfikset kom fra netværksejeren og overlapper intet lokalt, returvejen findes, eller en maskeringsregel erstatter den, den mekanisme, du konfigurerede, er den, der håndhæver routing på din platform, og de samme undersøgelser består efter en ren genstart. strongSwans noter om videresendelse er værd at læse, hvis returvejen er den del, der bliver ved med at fejle.