Hoe u slechts één privé-subnet door de VPN stuurt

Eén privé-subnet door de tunnel en al het overige via uw normale pad is een klein verzoek met heel veel manieren om het fout te doen. Wat de uitkomst bepaalt is niet het selectievakje met de naam split tunneling, maar waar de beslissing wordt afgedwongen: in de routetabel van de client zelf, in een route die de server pusht, of in een beleid dat de twee uiteinden onderhandelen. Kiest u de verkeerde laag, dan krijgt u ofwel een volledige tunnel die u nooit wilde, ofwel een route naar een tunnel die de andere kant weigert te accepteren. Ik gebruik een test met drie voorwaarden voordat ik welke configuratie dan ook open, en kies daarna een van de mechanismen hieronder.

Drie voorwaarden die het ontwerp bepalen

Ten eerste hebt u het exacte prefix en masker nodig van de netwerkeigenaar. Het 10.x-netwerk is geen prefix; 10.20.0.0/16 is dat wel. Controleer dat het niet overlapt met uw thuis-LAN, een Docker-brug of een ander VPN dat u draait, want een overlap maakt de route dubbelzinnig en de kernel kiest de vermelding die u niet bedoelde.

Ten tweede: wie beantwoordt het retourverkeer. Een pakket de tunnel in routeren brengt het alleen naar de VPN-server. Ligt het subnet achter een andere router zonder route terug naar uw clientpool, dan moet de server het verkeer maskeren, of die router moet uw pool leren. Geen enkele route aan clientzijde herstelt een ontbrekende terugweg.

Ten derde: het afdwingpunt. Sommige clients installeren een route en het besturingssysteem doet de rest. Andere onderhandelen een beleid, en een beleid dat de gateway niet accepteert levert helemaal geen tunnel op: pakketten worden weggegooid zonder duidelijke fout. Zoek uit welke van de twee uw geval is voordat u iets schrijft.

WireGuard: AllowedIPs is de routetabel

Op de client somt AllowedIPs de bestemmingen op die de tunnel in mogen, en wg-quick maakt van elke vermelding een gewone route. De clienthelft van deze taak is dus één regel.

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

Vergelijk nu de vermelding van de server voor dezelfde client. Die beschrijft wat de server naar de client stuurt, en dat is meestal het tunneladres van de client, niet het privé-subnet.

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

Die twee omwisselen is de fout die ik het vaakst zie. 10.20.0.0/16 onder het peer-gedeelte van de server zetten beweert dat het hele subnet achter die client ligt, en dat is een bewering van site naar site, geen toestemming. Pakketten die met geen enkele AllowedIPs van een peer overeenkomen worden stil weggegooid, dus een verkeerde vermelding lijkt precies op een firewallprobleem.

Beheert u de routes zelf, zet dan Table = off onder [Interface] en voeg de route toe die u wilt. Dan wordt niets automatisch toegevoegd, dus de route hoort bij wat de interface omhoog brengt.

OpenVPN: push de route en zorg dan dat hij aankomt

Op een normale server is de wijziging één richtlijn in de serverconfiguratie, naast de clientpool.

push "route 10.20.0.0 255.255.0.0"

De client voegt hem toe wanneer hij verbindt. De faalmodus verschijnt wanneer hetzelfde profiel ook redirect-gateway pusht, of wanneer iemand al route-nopull heeft toegevoegd: het eerste maakt de sessie een volledige tunnel, het tweede gooit elke gepushte route weg, inclusief de uwe.

Een client die smal gedrag nodig heeft tegenover een volledige-tunnelserver moet alleen de delen negeren die hij niet wil. In OpenVPN 2.4 en later bestaat pull-filter precies daarvoor.

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

Houd adresfamilies gescheiden: een gepushte IPv4-route doet niets voor een interne dienst die naar IPv6 oplost, en die dienst faalt via de tunnel terwijl al het andere er goed uitziet.

Wanneer het privé-subnet niet op de VPN-server staat maar achter een andere client, moet de server het weten. Voeg via client-config-dir een bestand per client toe met iroute 10.20.0.0 255.255.0.0, plus de bijbehorende route zodat andere clients de weg leren. Zonder iroute heeft de server geen reden om dat prefix juist door die tunnel te sturen.

IPsec: de verkeersselectors moeten het eens worden

Bij IPsec valt er geen route te pushen. De twee uiteinden onderhandelen welke adressen in de tunnel leven, en verkeer buiten de afgesproken selectors wordt niet versleuteld en niet erdoorheen gestuurd. Op een strongSwan-client zijn de selectors expliciet.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Is de gateway aan beide zijden met 0.0.0.0/0 geconfigureerd, dan verkleint IKEv2-vernauwing de child-SA meestal tot de doorsnede van de twee voorstellen, wat het gewenste resultaat is. Sommige gateways weigeren juist een voorstel dat niet bij hun geconfigureerde selectors past, en het log toont dan een mislukte child-SA in plaats van een routingklacht. Als dat gebeurt hoort de wijziging op de gateway, want een clientroute kan geen tunnel maken voor een selector die de andere kant niet accepteert.

Op Windows verbergt de ingebouwde client dezelfde beslissing achter twee instellingen. Split tunneling moet aan staan, en het prefix moet op het profiel geregistreerd worden.

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

Het is de registratie van het prefix die ervoor zorgt dat het een herverbinding overleeft, wat een handmatig toegevoegde route niet doet.

Houd het eindpunt en DNS buiten de beslissing

Het VPN-eindpunt moet bereikbaar blijven zonder de tunnel, anders stort de tunnel in zichzelf in. Wordt alleen 10.20.0.0/16 gerouteerd, dan is dat automatisch, omdat het eindpunt een openbaar adres is. Op een volledige-tunnelprofiel is dat niet zo, en de client heeft een expliciete hostroute naar het eindpunt nodig voordat de tunnel omhoog komt.

DNS is een tweede beslissing die een routepush niet voor u neemt. Interne namen lossen meestal op via een resolver die alleen het privénetwerk kan bereiken. Pusht de server een DNS-server, dan gaat elke naam daar doorheen; doet hij dat niet, dan falen interne namen of lossen ze openbaar op naar iets dat u niet bedoelde. Gesplitste DNS houdt één zoekdomein op de interne resolver, maar dat hangt af van clientondersteuning, dus behandel het als een eigen taak en niet als een bijwerking van routing.

Controleer, herstart dan en controleer opnieuw

Drie controles dekken de routingvraag. Vraag de kernel waar een extern adres heen zou gaan, haal iets uit het subnet, en bevestig dan dat een gewoon openbaar verzoek nog steeds via uw normale verbinding naar buiten gaat.

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

De eerste regel noemt een interface. Noemt die uw fysieke interface, dan is de route nooit aangekomen. Op Windows beantwoordt Find-NetRoute -RemoteIPAddress 10.20.5.7 dezelfde vraag, en de laatste controle zou nog steeds uw gewone adres moeten tonen en niet dat van de VPN-server.

Herstart dan. Handmatig toegevoegde routes verdwijnen, terwijl routes uit het profiel, uit een gepushte configuratie of uit AllowedIPs terugkomen. Werkt smalle toegang voor de herstart en faalt hij erna, dan zit de fout in hoe de tunnel start, niet in de route zelf.

Voordat u het af noemt, bevestigt u vier dingen: het prefix kwam van de netwerkeigenaar en overlapt niets lokaals, de terugweg bestaat of een masqueraderegel vervangt hem, het mechanisme dat u hebt geconfigureerd is degene die routing op uw platform afdwingt, en dezelfde controles slagen na een schone herstart. De doorstuurnotities van strongSwan zijn het lezen waard als de terugweg het deel is dat blijft falen.