El client OpenVPN s’atura quan el seu servidor s’executa al mateix host

Tenia una màquina de laboratori que acceptava un túnel d’un lloc remot i també marcava cap a una xarxa de proveïdor. El perfil de sortida havia funcionat durant setmanes. Després d’afegir el servidor d’entrada, el de sortida es connectava i després deixava de passar trànsit en qüestió de segons, o es negava a arrencar amb un error d’adreça en ús. Els fitxers de configuració no havien canviat; el host simplement havia adquirit un segon procés d’OpenVPN amb la seva pròpia opinió sobre ports i rutes.

La fallada no és aleatòria i no és un problema d’autenticació. Dos dimonis en una màquina competeixen pel mateix sòcol local i per la mateixa taula d’encaminament, i el que arrenca o es reconnecta l’últim sol guanyar. Saber quina d’aquestes dues col·lisions tens decideix on mirar primer.

Llegeix el símptoma al revés

Comença per quan mor el túnel. Un error de bind en arrencar apunta al costat que escolta: alguna cosa ja posseeix aquest port, i OpenVPN es nega a arrencar en lloc de compartir-lo. Un túnel que puja i després s’emmudeix apunta a l’encaminament, perquè una ruta instal·lada per l’altra instància pot treure els paquets de la connexió exterior del seu camí.

Els dos casos produeixen la mateixa queixa de l’usuari, i per això els bucles de reintent i els scripts de vigilància no arreglen res. Tornen a connectar el client al mateix conflicte. La primera pregunta útil és si el procés encara s’executa quan s’atura el trànsit.

Un sòcol i un dispositiu per instància

Un servidor que escolta enllaça el seu port; un client de sortida també necessita un port local per al seu trànsit encapsulat. Quan tots dos viuen al mateix host, el comportament per defecte del client pot xocar amb el port del servidor. El port local del client es pot fixar, i l’enllaç es pot ometre quan el par no necessita un port d’origen fix:

lport 1195
nobind
dev tun1

Aquests números són exemples, no un requisit. L’important és que el client deixi de competir pel port del servidor i que cada instància obtingui un dispositiu de túnel separat. Dos dimonis que comparteixen tun0 sobreescriuen l’estat del dispositiu de l’altre fins i tot quan els seus ports difereixen, així que un dispositiu per túnel no és opcional.

nobind pertany al costat del client. Un servidor encara ha d’enllaçar i escoltar, així que no copiïs la línia a la configuració del servidor ni desactivis l’enllaç en un client el par del qual filtra per un port d’origen fix.

Tria un sol propietari per a la ruta per defecte

Només una connexió pot instal·lar una ruta per defecte. Si tots dos perfils redirigeixen tot el trànsit, la segona connexió substitueix silenciosament la primera, i la primera sembla trencar-se. O bé mantén el túnel de sortida dividit i envia només els prefixos del proveïdor, o bé dona-li una taula d’encaminament separada.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Les adreces i el número de taula anteriors són marcadors de posició. Immediatament després d’afegir la regla, confirma que l’adreça del mateix servidor VPN encara es resol per la taula normal; una taula que captura el transport exterior trenca el túnel que havia de protegir, i el bucle de reconnexió que segueix sembla un proveïdor poc fiable.

Per a una configuració que ha de sobreviure a reconnexions i reinicis, un espai de noms de xarxa és la frontera més sòlida. El segon client s’executa dins del seu propi espai de noms amb les seves interfícies i rutes, i només s’exposen els serveis que han de creuar. El host manté una ruta per defecte, i una reconnexió de l’espai de noms no la pot reescriure.

Verifica amb la taula, no amb la línia d’estat

Un client que informa que està connectat només demostra el seu canal de control. Captura l’estat d’encaminament abans i després de cada connexió, i després pregunta al nucli quin dispositiu faria servir una destinació real:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Si el dispositiu seleccionat per a l’adreça del proveïdor canvia quan arrenca el segon túnel, tens la col·lisió de rutes. Si tots dos processos apareixen al mateix port local, tens la col·lisió de sòcols. Arreglar la primera sense la segona només mou la fallada a la propera reconnexió.

Escriu els ports, dispositius, taules i propietari de la ruta al runbook del host. Si no, la propera persona que afegeixi un tercer túnel tornarà a descobrir la mateixa col·lisió, i l’única evidència visible serà una connexió que funciona fins que es reiniciï el dimoni d’una altra persona.