Så skickar du bara ett privat subnät genom VPN

Ett privat subnät genom tunneln och allt annat längs din vanliga väg är en liten begäran med många sätt att göra fel. Det är inte kryssrutan med namnet split tunneling som avgör resultatet, utan var beslutet upprätthålls: i klientens egen routingtabell, i en rutt som servern skjuter ut, eller i en policy som de två ändarna förhandlar om. Väljer du fel lager får du antingen en full tunnel som du aldrig ville ha, eller en rutt in i en tunnel som andra sidan vägrar acceptera. Jag använder ett test med tre villkor innan jag öppnar någon konfiguration och väljer sedan en av mekanismerna nedan.

Tre villkor som avgör designen

För det första behöver du det exakta prefixet och nätmasken från nätverkets ägare. Nätet 10.x är inte ett prefix; 10.20.0.0/16 är det. Bekräfta att det inte överlappar ditt hem-LAN, en Docker-brygga eller ett annat VPN du kör, eftersom en överlappning gör rutten tvetydig och kärnan väljer posten du inte menade.

För det andra, vem som svarar på returtrafiken. Att routa ett paket in i tunneln tar det bara till VPN-servern. Om subnätet ligger bakom en annan router som saknar rutt tillbaka till din klientpool måste servern maskera trafiken, eller så måste den routern lära sig din pool. Ingen rutt på klientsidan rättar en saknad returväg.

För det tredje, upprätthållandepunkten. Vissa klienter installerar en rutt och operativsystemet gör resten. Andra förhandlar en policy, och en policy som gatewayen inte accepterar ger ingen tunnel alls: paketen kastas utan uppenbart fel. Ta reda på vilket av de två som är ditt fall innan du skriver något.

WireGuard: AllowedIPs är routingtabellen

På klienten listar AllowedIPs de destinationer som får komma in i tunneln, och wg-quick gör varje post till en vanlig rutt. Klienthalvan av den här uppgiften är alltså en rad.

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

Jämför nu serverns post för samma klient. Den beskriver vad servern skickar till klienten, vilket vanligtvis är klientens tunneladress, inte det privata subnätet.

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

Att byta dessa två är felet jag ser oftast. Att sätta 10.20.0.0/16 under serverns peer-avsnitt hävdar att hela subnätet ligger bakom den klienten, och det är ett anspråk från plats till plats, inte ett tillstånd. Paket som inte matchar någon peers AllowedIPs kastas tyst, så en felaktig post ser exakt ut som ett brandväggsproblem.

Om du sköter ruttabellen själv sätter du Table = off under [Interface] och lägger till rutten du vill ha. Då läggs ingenting till automatiskt, så rutten hör till det som reser gränssnittet.

OpenVPN: skjut ut rutten och se sedan till att den landar

På en vanlig server är ändringen en enda direktiv i serverkonfigurationen, bredvid klientpoolen.

push "route 10.20.0.0 255.255.0.0"

Klienten lägger till den när den ansluter. Felfallet visar sig när samma profil också skjuter ut redirect-gateway, eller när någon redan lagt till route-nopull: det första gör sessionen till en full tunnel, det andra kastar varje utskjuten rutt, inklusive din.

En klient som behöver smalt beteende mot en fulltunnel-server bör ignorera bara de delar den inte vill ha. I OpenVPN 2.4 och senare finns pull-filter just för det.

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

Håll adressfamiljerna åtskilda: en utskjuten IPv4-rutt gör ingenting för en intern tjänst som löses upp till IPv6, och den tjänsten misslyckas över tunneln medan allt annat ser bra ut.

När det privata subnätet inte finns på VPN-servern utan bakom en annan klient måste servern informeras. Lägg till en fil per klient via client-config-dir som innehåller iroute 10.20.0.0 255.255.0.0, plus den matchande route så att andra klienter lär sig vägen. Utan iroute har servern ingen anledning att skicka det prefixet ned genom just den tunneln.

IPsec: trafikselektorerna måste vara överens

Med IPsec finns ingen rutt att skjuta ut. De två ändarna förhandlar om vilka adresser som lever inuti tunneln, och trafik utanför de avtalade selektorerna krypteras inte och skickas inte genom den. På en strongSwan-klient är selektorerna uttryckliga.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Om gatewayen är konfigurerad med 0.0.0.0/0 på båda sidor minskar IKEv2-avsmalningen vanligtvis barn-SA:t till snittet av de båda förslagen, vilket är det önskade resultatet. Vissa gatewayer avvisar i stället ett förslag som inte matchar deras konfigurerade selektorer, och loggen visar då ett misslyckat barn-SA i stället för ett routingklagomål. När det händer hör ändringen hemma på gatewayen, eftersom en klientrutt inte kan skapa en tunnel för en selektor som andra sidan inte accepterar.

På Windows döljer den inbyggda klienten samma beslut bakom två inställningar. Tunneldelningen måste vara på, och prefixet måste registreras på profilen.

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

Det är registreringen av prefixet som gör att det överlever en återanslutning, vilket en handpålagd rutt inte gör.

Håll ändpunkten och DNS utanför beslutet

VPN-ändpunkten måste förbli nåbar utan tunneln, annars kollapsar tunneln in i sig själv. När bara 10.20.0.0/16 routas är det automatiskt, eftersom ändpunkten är en offentlig adress. På en fulltunnelprofil är det inte så, och klienten behöver en uttrycklig värdrutt till ändpunkten innan tunneln kommer upp.

DNS är ett andra beslut som en ruttutskjutning inte fattar åt dig. Interna namn löses vanligtvis via en resolver som bara det privata nätet kan nå. Skjuter servern ut en DNS-server går varje namn genom den; gör den inte det misslyckas interna namn antingen eller löses offentligt till något du inte menade. Delad DNS håller en sökdomän på den interna resolvern, men det beror på klientstöd, så behandla det som en egen uppgift och inte som en bieffekt av routingen.

Verifiera, starta sedan om och verifiera igen

Tre prover täcker routingfrågan. Fråga kärnan vart en fjärradress skulle ta vägen, hämta något inifrån subnätet och bekräfta sedan att en vanlig offentlig begäran fortfarande går ut genom din normala anslutning.

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

Den första raden namnger ett gränssnitt. Namnger den ditt fysiska gränssnitt landade rutten aldrig. På Windows svarar Find-NetRoute -RemoteIPAddress 10.20.5.7 på samma fråga, och det sista provet bör fortfarande visa din vanliga adress och inte VPN-serverns.

Starta sedan om. Rutter som lagts till för hand försvinner, medan rutter från profilen, från en utskjuten konfiguration eller från AllowedIPs kommer tillbaka. Om smal åtkomst fungerar före omstarten och misslyckas efter, ligger felet i hur tunneln startar, inte i rutten själv.

Innan du kallar det klart ska du bekräfta fyra saker: prefixet kom från nätverkets ägare och överlappar inget lokalt, returvägen finns eller en maskeringsregel ersätter den, mekanismen du konfigurerade är den som upprätthåller routing på din plattform, och samma prover går igenom efter en ren omstart. strongSwans anteckningar om vidarebefordran är värda att läsa om returvägen är den del som fortsätter att misslyckas.