Dos clients VPN, una taula d’encaminament: qui guanya la ruta per defecte

Sembla que dos clients VPN es barallen per un sòcol, i la solució òbvia ha de ser desinstal·lar-ne un. A la pràctica poques vegades toquen el mateix sòcol. Cada connexió reescriu la taula d’encaminament del sistema operatiu, i un perfil de túnel complet reclama la ruta per defecte. Normalment guanya qui s’ha connectat més tard, i per això el símptoma sembla moure’s entre clients.

El conflicte viu a la taula d’encaminament

Un adaptador virtual més una ruta per defecte és com un túnel complet captura el trànsit. Quan el segon client instal·la la seva ruta per defecte, l’entrada anterior se substitueix o es degrada per mètrica, i cada destinació viatja ara pel túnel més nou. El primer client continua connectat i encara mostra una icona verda, o sigui que la interfície és activa mentre el camí ha desaparegut. Aquesta separació entre l’estat de connexió i l’estat d’encaminament és el que fa confús el comportament.

Els clients són editors d’una taula compartida. Saber quina edició va passar l’última explica gairebé tots els símptomes.

Llegeix quin túnel posseeix el camí actual

Comprova la decisió real en lloc de confiar en el client que informa que està connectat. Pregunta al sistema quina interfície portaria una destinació concreta.

ip route get 10.20.0.5
route print -4

La primera comanda anomena la interfície i l’adreça d’origen per a una destinació, i aquesta és la pregunta exacta que t’importa. L’abocament de rutes mostra les entrades per defecte en competència i les seves mètriques a Windows, així que veus quina guanya ara. Fes la consulta per a un amfitrió de cada xarxa remota, perquè una destinació pot ser correcta mentre l’altra xarxa és inabastable. Si la resposta anomena el túnel equivocat, reconnectar no ajudarà; la política d’encaminament ha de canviar.

Atura que el segon client ho reclami tot

Un client hauria de posseir la ruta per defecte, i l’altre només hauria de portar els seus propis prefixos. OpenVPN els clients poden rebutjar el que el servidor empeny.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull ignora cada ruta empenyuda, mentre que pull-filter ignore "redirect-gateway" només descarta la directiva de ruta per defecte i conserva el DNS i altres opcions empenyuts. Tria entre ells segons quanta configuració del servidor encara vols, i després afegeix els prefixos concrets que necessita la segona xarxa. Tingues present el DNS, perquè un resolutor empenyut per un túnel que no porta les consultes no retorna res. Prova un amfitrió conegut a cada xarxa i confirma l’adreça d’origen que veu el costat remot.

Les subxarxes solapades no es poden evitar

Quan totes dues xarxes publiquen el mateix prefix, el nucli manté una entrada per a dos llocs diferents i ha de triar. Una ruta d’amfitrió no pot inventar la distinció que falta, ni ho pot fer un retoc de mètrica. Renumera un costat, o fes que el seu administrador tradueixi el rang remot perquè els prefixos difereixin. Comprova les subxarxes reals abans de culpar els clients, perquè el valor per defecte 192.168.1.0/24 d’un router domèstic xoca amb un rang d’oficina més sovint del que ningú espera. Anota tots dos rangs al tiquet perquè el proper canvi no torni a crear el solapament.

Separa també dos objectius: arribar a totes dues xarxes és un problema d’encaminament, mentre que encadenar túnels per privacitat és un disseny diferent amb un operador extra al camí. No facis servir un per resoldre l’altre.