Hoe om slegs een private subnet deur die VPN te stuur

Kies tussen 'n kliëntroete, 'n roete wat die bediener stoot en bedingde keuses, en dra dan een private subnet sonder 'n volledige tonnel.

Een private subnet deur die tonnel en alles anders oor jou normale pad is 'n klein versoek met baie maniere om dit verkeerd te doen. Wat die uitkoms bepaal, is nie die merkblokkie met die naam split tunneling nie, maar waar die besluit afgedwing word: die kliënt se eie roeteblad, 'n roete wat die bediener stoot, of 'n beleid wat die twee kante beding. Kies die verkeerde laag en jy kry óf 'n volledige tonnel wat jy nooit wou hê nie, óf 'n roete wat in 'n tonnel wys wat die ander kant weier om te aanvaar. Ek gebruik 'n toets met drie voorwaardes voordat ek enige konfigurasie oopmaak, en kies dan een van die meganismes hier onder.

Drie voorwaardes wat die ontwerp beslis

Eerste, jy het die presiese voorvoegsel en masker van die netwerkeienaar nodig. Die 10.x-netwerk is nie 'n voorvoegsel nie; 10.20.0.0/16 is. Bevestig dat dit nie met jou huis-LAN, 'n Docker-brug of 'n ander VPN wat jy bedryf oorvleuel nie, want 'n oorvleueling maak die roete dubbelsinnig en die kern kies die inskrywing wat jy nie bedoel het nie.

Tweede, wie antwoord die terugkeerverkeer. Om 'n pakket in die tonnel te roeteer kry dit net by die VPN-bediener. As die subnet agter 'n ander router sit wat geen roete terug na jou kliëntpoel het nie, moet die bediener die verkeer masjineer, of daardie router moet jou poel leer. Geen kliëntkantige roete herstel 'n ontbrekende terugpad nie.

Derde, die afdwingpunt. Sommige kliënte installeer 'n roete en die bedryfstelsel doen die res. Ander beding 'n beleid, en 'n beleid wat die poort nie aanvaar nie lewer glad geen tonnel nie: pakkette word laat val sonder 'n duidelike fout. Bepaal watter van die twee jy besit voordat jy enigiets skryf.

WireGuard: AllowedIPs is die roeteblad

Op die kliënt lys AllowedIPs die bestemmings wat die tonnel mag binnegaan, en wg-quick verander elke inskrywing in 'n gewone roete. Die kliënthelfte van hierdie taak is dus een reël.

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

Vergelyk nou die bediener se inskrywing vir dieselfde kliënt. Dit beskryf wat die bediener na die kliënt sal stuur, wat gewoonlik die kliënt se tonneladres is, nie die private subnet nie.

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

Om daardie twee om te ruil is die fout wat ek die meeste sien. Om 10.20.0.0/16 onder die bediener se peer-afdeling te plaas, sê dat die hele subnet agter daardie kliënt woon, wat 'n werf-tot-werf-eis is eerder as 'n toestemming. Pakkette wat aan geen peer se AllowedIPs voldoen nie word stilweg laat val, so 'n verkeerde inskrywing lyk presies soos 'n firewall-probleem.

As jy roetes self bestuur, stel Table = off onder [Interface] en voeg die roete by wat jy wil hê. Dan word niks outomaties bygevoeg nie, so die roete hoort in wat ook al die koppelvlak opbring.

OpenVPN: stoot die roete en maak seker dit land

Op 'n normale bediener is die verandering een richtlijn in die bedienerkonfigurasie, langs die kliëntpoel.

push "route 10.20.0.0 255.255.0.0"

Die kliënt voeg dit by wanneer dit koppel. Die foutmodus wys wanneer dieselfde profiel ook redirect-gateway stoot, of wanneer iemand reeds route-nopull bygevoeg het: die eerste maak die sessie 'n volledige tonnel, en die tweede gooi elke gestote roete weg, insluitend joune.

'n Kliënt wat smal gedrag teen 'n volledige-tonnel-bediener nodig het, moet net die dele ignoreer wat dit nie wil hê nie. Op OpenVPN 2.4 en later bestaan pull-filter juis daarvoor.

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

Hou adresfamilies apart: 'n gestote IPv4-roete doen niks vir 'n interne diens wat na IPv6 oplos nie, en daardie diens faal oor die tonnel terwyl alles anders reg lyk.

Wanneer die private subnet nie op die VPN-bediener is nie maar agter 'n ander kliënt, moet die bediener ingelig word. Voeg 'n per-kliënt-lêer deur client-config-dir by met iroute 10.20.0.0 255.255.0.0, plus die bypassende route sodat ander kliënte die pad leer. Sonder iroute het die bediener geen rede om daardie voorvoegsel deur daardie spesifieke tonnel te stuur nie.

IPsec: die verkeerskeuses moet ooreenstem

Met IPsec is daar geen roete om te stoot nie. Die twee kante beding watter adresse binne die tonnel woon, en verkeer buite die ooreengekome keuses word nie geënsikteer nie en nie daardeur gestuur nie. Op 'n strongSwan-kliënt is die keuses eksplisiet.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

As die poort met 0.0.0.0/0 aan beide kante opgestel is, verminder IKEv2-vernouing gewoonlik die kind-SA tot die snyding van die twee voorstelle, wat die uitkoms is wat jy wil hê. Sommige poorte verwerp eerder 'n voorstel wat nie by hul opgestelde keuses pas nie, en die log wys dan 'n mislukte kind-SA eerder as 'n roeteklag. Wanneer dit gebeur, hoort die verandering by die poort, want 'n kliëntroete kan nie 'n tonnel skep vir 'n keuse wat die ander kant nie sal aanvaar nie.

Op Windows versteek die ingeboude kliënt dieselfde besluit agter twee instellings. Split tunneling moet aan wees, en die voorvoegsel moet teen die profiel geregistreer word.

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

Om die voorvoegsel te registreer is wat dit 'n herverbinding laat oorleef, wat 'n handmatig bygevoegde roete nie doen nie.

Hou die eindpunt en DNS buite die besluit

Die VPN-eindpunt moet bereikbaar bly sonder die tonnel, anders val die tonnel in homself in duie. Wanneer net 10.20.0.0/16 geroteer word, is dit outomaties, want die eindpunt is 'n publieke adres. Op 'n volledige-tonnel-profiel is dit nie, en die kliënt het 'n eksplisiete gasheerroete na die eindpunt nodig voordat die tonnel opkom.

DNS is 'n tweede besluit wat 'n roetestoot nie vir jou maak nie. Interne name los gewoonlik op deur 'n oplosser wat net die private netwerk kan bereik. As die bediener 'n DNS-bediener stoot, gaan elke naam daardeur; as dit nie doen nie, misluk interne name óf los dit publiek op na iets wat jy nie bedoel het nie. Verdeelde DNS hou een soekdomein op die interne oplosser, maar dit hang van kliëntondersteuning af, so behandel dit as sy eie taak eerder as 'n newe-effek van roetering.

Verifieer, herbegin dan en verifieer weer

Drie ondersoeke dek die roetevraag. Vra die kern waar 'n afgeleë adres sou heen gaan, haal iets uit die binnekant van die subnet, en bevestig dan dat 'n gewone publieke versoek steeds deur jou normale verbinding uitgaan.

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

Die eerste reël noem 'n koppelvlak. As dit jou fisiese koppelvlak noem, het die roete nooit geland nie. Op Windows antwoord Find-NetRoute -RemoteIPAddress 10.20.5.7 dieselfde vraag, en die laaste ondersoek moet steeds jou gewone adres wys eerder as die VPN-bediener s'n.

Herbegin dan. Roetes wat met die hand bygevoeg is, verdwyn, terwyl roetes uit die profiel, uit 'n gestote konfigurasie of uit AllowedIPs terugkom. As smal toegang voor die herbegin werk en daarna misluk, is die fout in hoe die tonnel begin, nie in die roete self nie.

Voordat jy dit klaar noem, bevestig vier dinge: die voorvoegsel het van die netwerkeienaar gekom en oorvleuel niks plaasliks nie, die terugpad bestaan of 'n masjineringsreël vervang dit, die meganisme wat jy opgestel het is die een wat roetering op jou platform afdwing, en dieselfde ondersoeke slaag ná 'n skoon herbegin. Die strongSwan-aanstuurnotas is die moeite werd om te lees as die terugpad die deel is wat aanhou misluk.

Verwante artikels