Per què un segon túnel VPN trenca el primer?

Instal·lar un segon client VPN per arribar a una xarxa de client és la manera habitual com comença això, i el primer túnel s'apaga mentre tots dos clients informen d'èxit. Cada client ha instal·lat una ruta predeterminada, la segona era més específica, i ara el nucli la segueix per a tot excepte la connexió exterior del primer túnel. Res no s'ha esfondrat i cap perfil no és incorrecte. Una ruta n'ha substituït una altra, i la solució és decidir quin túnel ha de posseir la predeterminada.

El símptoma: el segon client guanya en silenci

OpenVPN: la seva opció redirect-gateway def1 no sobreescriu 0.0.0.0/0. Afegeix 0.0.0.0/1 i 128.0.0.0/1: entre totes dues cobreixen cada adreça IPv4, i cada prefix supera una predeterminada simple per longitud. La predeterminada original es queda a la taula i deixa d'usar-se per al trànsit ordinari, i una ruta d'amfitrió cap al servidor VPN evita que el túnel capturi els seus propis paquets exteriors. Tots dos clients ho fan, i el segon simplement instal·la la seva parella més tard.

Per això el primer túnel sembla mort en lloc de desconnectat. La seva interfície està activa, el seu canal de control és viu, i cap trànsit d'aplicacions hi arriba ja. La queixa inversa té el mateix push absent: un telèfon que es connecta però no envia res normalment parla amb un servidor que mai no ha anunciat redirect-gateway, així que el dispositiu conserva la seva predeterminada i només arriba a la piscina.

Feu una captura de les rutes abans i després que es connecti el segon client. Les dues semi-rutes que apareixen a la taula són tot el canvi, i expliquen totes dues queixes. Res més a la taula no s'ha de moure perquè aparegui el símptoma. Per això treure el segon client restaura el primer a l'instant.

Llegeix quin túnel guanya de debò

No deduïu el guanyador de l'ordre en què es van iniciar els clients ni de la icona de la safata. Pregunteu al nucli quina ruta faria servir per a una destinació fora de les dues xarxes privades, i llegiu la interfície que retorna.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Les dues primeres són la resposta de Linux i les dues últimes l'equivalent de Windows. Executeu-les amb tots dos túnels actius, després desconnecteu-ne un i torneu-les a executar. La diferència entre les dues sortides és el fet que necessiteu abans de triar una solució, i triga menys que llegir el registre de qualsevol client.

Anoteu el resultat, incloent-hi el nom de la interfície i el prefix que ha coincidit. Un tiquet que diu que el segon VPN va trencar el primer és una descripció del símptoma, no una afirmació d'encaminament sobre la qual ningú pugui actuar. La consulta el converteix en un fet que el següent enginyer pot reproduir amb una ordre.

Windows: eviteu que un perfil posseeixi la predeterminada

Windows conserva perfils desats, i el client integrat permet que un depengui d'un altre perquè el primer s'aixequi automàticament quan el segon marca. El perfil connectat més recentment sol conservar la predeterminada, així que el propietari pràctic és l'última marca i no la primera. Doneu a cada perfil les seves pròpies rutes push i activeu el túnel dividit per al que no ha de posseir la predeterminada.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

El túnel dividit ho canvia: només els prefixos empesos pel servidor arriben a la taula, cosa que deixa la predeterminada al primer túnel. El disseny encara falla si tots dos servidors empenyen una ruta predeterminada, perquè llavors guanya l'última connexió i cap paràmetre del client ho canvia. Arregleu el push del servidor o accepteu un sol propietari.

Els perfils activats per aplicacions són una altra funció i val la pena conèixer-los: un perfil de Windows pot iniciar-se quan s'engega un executable determinat, amb filtres de trànsit que decideixen què porta. És un paràmetre de perfil i no una regla de firewall, i resol un problema diferent del conflicte de ruta predeterminada.

Linux: manteniu el segon túnel fora de la taula principal

Executar dues instàncies de openvpn --config en una màquina posa tots dos clients a la mateixa taula, i tres opcions els separen amb un aïllament creixent. La més lleugera és impedir del tot que el segon client editi la taula, amb route-nopull i rutes explícites, o un script route-up que només instal·li el que voleu. Llavors el segon túnel porta exactament els prefixos que anomeneu i res més. Llavors decidiu quins prefixos van on en lloc de descobrir-ho després.

L'encaminament per polítiques és l'opció intermèdia. Una regla selecciona una taula separada per a una adreça d'origen o una marca de firewall, i aquesta taula porta les rutes del segon túnel. El filtratge de camí invers és el parany aquí, perquè una resposta que arriba per una interfície diferent de la que triaria la taula es descarta, així que comproveu el paràmetre rp_filter abans de concloure que el túnel està trencat.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Els espais de noms de xarxa són l'opció més pesada i la més neta. Inicieu el segon client dins de ip netns, doneu-li una parella veth i entreu en aquest espai de noms per usar-lo. La interferència desapareix perquè cada espai de noms té les seves pròpies taules en lloc de compartir-ne una, cosa que val la configuració extra quan tots dos túnels han de romandre actius durant setmanes.

Per aplicació, i l'encadenament com a problema a part

De vegades només un programa hauria d'usar el segon túnel. A Linux, l'encaminament per polítiques per usuari, cgroup o port arriba a aquest resultat, i una sola destinació es pot fixar a una interfície sense tocar la predeterminada. Una aplicació que fixa el seu sòcol a una interfície no consulta mai la taula d'encaminament, així que un llançador pot seguir usant l'adaptador físic fins que es triï una adreça dins dels seus propis paràmetres.

L'encadenament és una operació diferent d'executar dos túnels l'un al costat de l'altre. Encadenar A sobre B vol dir que l'adreça del servidor intern ha de ser abastable des de dins del túnel extern. El client extern tampoc no ha de confondre els paquets xifrats del client intern amb una fuita. Un client dins d'una màquina virtual és la versió grollera però fiable; tots dos en un sol amfitrió requereixen la feina d'encaminament anterior més un camí extern cap al servidor intern que no entri mai al túnel intern.

Anoteu el propietari de la predeterminada, la llista de prefixos que porta cada túnel i el camí DNS. Aquests tres fets converteixen el proper incident en una consulta en lloc d'una investigació.