Com enviar només una subxarxa privada per la VPN

Una subxarxa privada pel túnel i tota la resta pel camí habitual és una petició petita amb moltes maneres de fer-la malament. El resultat no el decideix la casella anomenada split tunneling, sinó on s'aplica la decisió: la taula de rutes del propi client, una ruta que empeny el servidor o una política que negocien els dos extrems. Trieu la capa equivocada i obtindreu o un túnel complet que no volíeu, o una ruta cap a un túnel que l'altre extrem es nega a acceptar. Faig servir una prova de tres condicions abans d'obrir cap configuració i després trio un dels mecanismes d'aquí sota.

Tres condicions que fixen el disseny

Primer, necessiteu el prefix i la màscara exactes del propietari de la xarxa. La xarxa 10.x no és un prefix; 10.20.0.0/16 sí que ho és. Confirmeu que no se solapa amb la vostra LAN domèstica, amb un pont de Docker o amb una altra VPN que feu servir, perquè un solapament fa la ruta ambigua i el nucli tria l'entrada que no volíeu.

Segon, qui respon al trànsit de tornada. Encaminar un paquet cap al túnel només el porta al servidor VPN. Si la subxarxa és darrere d'un altre encaminador que no té ruta de tornada cap al vostre conjunt de clients, el servidor ha de disfressar el trànsit, o aquell encaminador ha d'aprendre el vostre conjunt. Cap ruta al costat del client no arregla un camí de tornada que falta.

Tercer, el punt d'aplicació. Alguns clients instal·len una ruta i el sistema operatiu fa la resta. Altres negocien una política, i una política que la passarel·la no accepta no produeix cap túnel: els paquets es descarten sense cap error evident. Esbrineu quin dels dos és el vostre abans d'escriure res.

WireGuard: AllowedIPs és la taula de rutes

Al client, AllowedIPs llista les destinacions que poden entrar al túnel, i wg-quick converteix cada entrada en una ruta ordinària. Així, la meitat client d'aquesta tasca és una sola línia.

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

Ara compareu l'entrada del servidor per a aquell mateix client. Descriu què enviarà el servidor al client, que normalment és l'adreça de túnel del client, no la subxarxa privada.

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

Intercanviar aquestes dues és l'error que veig més sovint. Posar 10.20.0.0/16 sota la secció peer del servidor afirma que tota la subxarxa viu darrere d'aquell client, cosa que és una afirmació de lloc a lloc i no un permís. Els paquets que no coincideixen amb l'AllowedIPs de cap peer es descarten en silenci, així que una entrada equivocada sembla exactament un problema de tallafocs.

Si gestioneu les rutes vosaltres mateixos, poseu Table = off sota [Interface] i afegiu la ruta que voleu. Llavors no s'afegeix res automàticament, així que la ruta pertany a allò que aixeca la interfície.

OpenVPN: empenyeu la ruta i assegureu-vos que arriba

En un servidor normal el canvi és una directiva a la configuració del servidor, al costat del conjunt de clients.

push "route 10.20.0.0 255.255.0.0"

El client l'afegeix quan es connecta. El mode de fallada apareix quan el mateix perfil també empeny redirect-gateway, o quan algú ja ha afegit route-nopull: el primer converteix la sessió en un túnel complet, i el segon descarta totes les rutes empenyudes, inclosa la vostra.

Un client que necessita un comportament estret contra un servidor de túnel complet hauria d'ignorar només les parts que no vol. A OpenVPN 2.4 i posteriors, pull-filter existeix precisament per a això.

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

Manteniu les famílies d'adreces separades: una ruta IPv4 empenyuda no fa res per a un servei intern que es resol a IPv6, i aquell servei falla pel túnel mentre la resta sembla correcta.

Quan la subxarxa privada no és al servidor VPN sinó darrere d'un altre client, cal avisar el servidor. Afegiu un fitxer per client mitjançant client-config-dir que contingui iroute 10.20.0.0 255.255.0.0, més la route corresponent perquè els altres clients aprenguin el camí. Sense iroute el servidor no té cap motiu per enviar aquell prefix per aquell túnel concret.

IPsec: els selectors de trànsit s'han de posar d'acord

Amb IPsec no hi ha cap ruta a empenyer. Els dos extrems negocien quines adreces viuen dins del túnel, i el trànsit fora dels selectors acordats no s'xifra ni s'hi envia. En un client strongSwan els selectors són explícits.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Si la passarel·la està configurada amb 0.0.0.0/0 als dos costats, l'estretiment d'IKEv2 sol reduir la SA filla a la intersecció de les dues propostes, que és el resultat que voleu. Algunes passarel·les, en canvi, rebutgen una proposta que no coincideix amb els seus selectors configurats, i llavors el registre mostra una SA filla fallida i no una queixa d'encaminament. Quan passa això, el canvi pertany a la passarel·la, perquè una ruta al client no pot crear un túnel per a un selector que l'altre costat no acceptarà.

A Windows el client integrat amaga la mateixa decisió darrere de dos paràmetres. La divisió del túnel ha d'estar activada, i el prefix s'ha de registrar al perfil.

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

Registrar el prefix és el que el fa sobreviure a una reconnexió, cosa que una ruta afegida a mà no fa.

Manteniu el punt final i el DNS fora de la decisió

El punt final de la VPN ha de romandre abastable sense el túnel, o el túnel s'enfonsa en si mateix. Quan només s'encamina 10.20.0.0/16 això és automàtic, perquè el punt final és una adreça pública. En un perfil de túnel complet no ho és, i el client necessita una ruta d'amfitrió explícita fins al punt final abans que pugi el túnel.

El DNS és una segona decisió que l'enviament de rutes no pren per vosaltres. Els noms interns solen resoldre's mitjançant un servidor de noms al qual només pot arribar la xarxa privada. Si el servidor empeny un servidor DNS, tots els noms hi passen; si no ho fa, els noms interns o fallen o es resolen públicament a una cosa que no volíeu. El DNS dividit manté un domini de cerca al resolutor intern, però depèn del suport del client, així que tracteu-lo com una tasca pròpia i no com un efecte secundari de l'encaminament.

Verifiqueu, reinicieu i torneu a verificar

Tres proves cobreixen la qüestió de l'encaminament. Pregunteu al nucli on aniria una adreça remota, baixeu alguna cosa de dins de la subxarxa i després confirmeu que una petició pública ordinària encara surt per la vostra connexió normal.

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

La primera línia anomena una interfície. Si anomena la vostra interfície física, la ruta no ha arribat mai. A Windows, Find-NetRoute -RemoteIPAddress 10.20.5.7 respon la mateixa pregunta, i l'última prova encara hauria de mostrar la vostra adreça habitual i no la del servidor VPN.

Després reinicieu. Les rutes afegides a mà desapareixen, mentre que les rutes del perfil, d'una configuració empenyuda o d'AllowedIPs tornen. Si l'accés estret funciona abans del reinici i falla després, la culpa és en com arrenca el túnel, no en la ruta mateixa.

Abans de donar-ho per fet, confirmeu quatre coses: el prefix ve del propietari de la xarxa i no se solapa amb res local, el camí de tornada existeix o una regla de disfressa el substitueix, el mecanisme que heu configurat és el que aplica l'encaminament a la vostra plataforma, i les mateixes proves passen després d'un reinici net. Les notes de reenviament de strongSwan val la pena llegir-les si el camí de tornada és la part que no para de fallar.