Dos clients VPN en un sol escriptori: què xoca i què funciona

El vostre segon client es connecta, els recursos del primer deixen de resoldre’s i el tiquet diu que la VPN de la feina ha trencat la personal. No hi ha res trencat en el sentit de fallada: tots dos clients feien allò per a què estaven dissenyats, i la màquina només té una taula d’encaminament. El xoc és per quatre recursos que cada client assumeix que posseeix. Recorreu-los en ordre i la solució sol esdevenir una decisió de disseny més que una reparació.

Pas 1: esbrineu quin client controla la sortida

Llegiu la decisió de sortida actual abans de canviar res. La consulta de ruta per a una adreça pública us diu quina interfície i quin salt següent faria servir un paquet ara mateix, i aquesta és la resposta a qui ha guanyat. Compareu-ho amb els noms d’interfície que han creat els clients, que normalment porten el nom del producte o del protocol. Si la consulta apunta al túnel que no esperàveu, ja heu trobat el xoc.

ip route get 1.1.1.1
ip route show default
route print

Alguns clients no substitueixen la ruta per defecte en absolut; afegeixen dues meitats, una per a la meitat inferior de l’espai d’adreces i una per a la superior, que juntes ho cobreixen tot. Això deixa visible la ruta per defecte original i fa que una reparació manual sembli correcta mentre el trànsit continua sortint pel túnel. Llegiu la mètrica i la longitud del prefix, no només la presència d’una entrada per defecte.

Atureu-vos si tots dos clients reclamen el mateix prefix amb la mateixa mètrica. El nucli triarà un, i l’altre apareixerà connectat sense portar res.

Pas 2: comproveu el resoldre i els prefixos superposats

El DNS és el segon xoc i produeix un símptoma distintiu: els noms fallen mentre les adreces funcionen. Cada client imposa el seu propi resoldre, i l’últim que escriu guanya per a les consultes següents. Pregunteu al servei de resolució què fa servir per enllaç en lloc de llegir la pàgina de configuració del client.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Després compareu els prefixos privats que fan servir les dues xarxes. Si tots dos costats assignen del mateix rang, cap arranjament pel costat del client ho arreglarà, perquè la màquina no pot dir quina destinació 10.0.0.0/8 pertany a quin túnel. Un costat s’ha de renumerar o traduir, i això és una conversa amb els propietaris de la xarxa, no un canvi de configuració. La superposició és l’únic xoc on la resposta honesta és que el disseny ha de canviar.

Atureu-vos aquí si els prefixos se superposen. Tot el que ve després en aquesta llista assumeix que no se superposen.

Pas 3: trieu un patró de separació que aguanti

Els patrons fiables eviten executar dos clients contra la mateixa taula d’encaminament. Un sol client amb una política de túnel dividit que arriba a les dues xarxes privades és el més simple, sempre que les destinacions no se superposin i el propietari de la política hi estigui d’acord. Una màquina virtual o un espai de noms de xarxa és el pas següent, perquè cadascun obté la seva pròpia taula i el seu propi resoldre.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Un espai de noms dóna la mateixa separació que una màquina virtual sense el segon sistema operatiu, però té arestes aspres: el dispositiu del túnel s’hi ha de moure, i l’aplicació s’ha d’iniciar a dins. Un dispositiu físic separat és sovint l’opció menys sorprenent per a una VPN personal al costat d’un client de feina gestionat. Apilar un túnel dins d’un altre no és un patró de separació; el punt final interior ha de romandre abastable a través del túnel exterior, i aquesta disposició afegeix problemes de MTU i latència a sobre.

Trieu un patró i anoteu per què. Barrejar un espai de noms per a una aplicació amb un túnel dividit per a la resta recrea el xoc original en una forma més difícil de depurar.

Pas 4: verifiqueu les dues xarxes des de la mateixa sessió

Proveu un recurs a cada xarxa privada des de l’entorn on l’aplicació s’executa realment, no des del vostre shell si l’aplicació s’executa dins d’un espai de noms. Comproveu la interfície de sortida, l’adreça resolta i el codi de resposta alhora, perquè un èxit en un dels tres pot amagar una fallada en els altres. Repetiu-ho després d’un reinici, ja que l’ordre en què arranquen els clients decideix qui guanya. Aquest ordre és la part que la gent oblida enregistrar.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Enregistreu les versions dels clients, les interfícies, l’estat del resoldre i els prefixos de cada xarxa. Quan un client s’actualitza i canvia el seu comportament d’encaminament, aquest registre és la diferència entre una reparació de cinc minuts i una reconstrucció. La propera persona no compartirà la vostra memòria de quin túnel va pujar primer.

La llista és completa quan podeu anomenar la interfície que posseeix la ruta per defecte, el resoldre que fa servir cada nom, el patró que separa el segon túnel i el resultat d’una petició per xarxa després d’un reinici. Qualsevol cosa menys és una configuració que avui funciona per casualitat.