El túnel complet d’OpenVPN talla la sessió SSH: arregleu el camí de tornada

Activar un client OpenVPN de túnel complet en una màquina a la qual arribeu per SSH pot tallar la sessió en un segon, i la màquina no fa res malament. El túnel no canvia com arriben els paquets al servidor; canvia com surten les respostes. Quan la ruta per defecte apunta a tun0, una resposta al vostre client SSH entra a la xarxa del proveïdor, que no té cap ruta de tornada a la vostra adreça. La connexió es penja, el següent intent expira i el dimoni continua escoltant al port 22 tot el temps.

Llegiu la taula d’encaminament abans de llegir el registre del VPN. El registre dirà que el túnel ha pujat, i té raó. La qüestió és a quina interfície es lliura cada resposta, i això és una consulta per paquet contra una taula que el túnel acaba de reescriure.

Per què la resposta surt per la porta equivocada

Els paquets entrants encara arriben per la interfície física, perquè un client VPN no pot canviar com arriba internet a l’adreça pública del vostre servidor. Les respostes són una decisió a part: per a cada paquet, el nucli busca la destinació, i després de --redirect-gateway l’entrada per defecte diu túnel. La sortida del proveïdor veu una destinació que no serveix i descarta el paquet.

La protecció pròpia d’OpenVPN cobreix exactament una destinació. El manual de la 2.6 descriu --redirect-gateway com una seqüència: afegeix una ruta d’host per al peer VPN a través de la passarel·la en ús abans del túnel, perquè el trànsit xifrat no pugui tornar dins de si mateix, i després substitueix la ruta per defecte. Aquesta ruta d’host és només per al peer. El vostre client SSH és només una altra adreça d’internet i no rep cap excepció.

Val la pena descartar aviat un error de prefix. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 sense longitud coincideix amb l’adreça única 0.0.0.0, no amb internet; ha de ser 0.0.0.0/0. I si prendre la ruta per defecte trenca el transport propi del túnel, afegiu el punt final com a ruta d’host per la interfície física, fent servir l’adreça real del proveïdor.

Fixeu l’adreça del vostre client SSH per a una solució immediata

La reparació més ràpida és una ruta d’host per a l’adreça del vostre client a través de la passarel·la que el servidor feia servir abans que existís el túnel. Des del vostre costat, trobeu l’adreça que veurà el servidor i després llegiu la taula del servidor per saber la passarel·la antiga:

curl -s https://ifconfig.co
ip route

Al servidor, afegiu l’excepció abans que arrenqui el client. Les adreces d’aquí són marcadors de posició; la forma és el que importa:

sudo ip route add 80.128.240.55 via 192.168.178.1

Aquesta és la solució usada en el cas reportat, i funciona immediatament. També és fràgil de dues maneres previsibles: la ruta desapareix en reiniciar i es torna incorrecta en el moment que el vostre ISP us dona una adreça diferent. Tracteu-la com una mesura d’emergència i feu-la duradora a propòsit, amb una unitat de xarxa o un ganxo del despatxador, o accepteu que és temporal i anoteu el camí de recuperació.

Eviteu que el client prengui la ruta per defecte

L’opció més neta és impedir que el túnel substitueixi la ruta per defecte. route-nopull, usat amb --client o --pull, accepta les opcions empenyudes excepte les rutes, block-outside-dns i les opcions d’estil DHCP com els servidors DNS, així que només afegiu els prefixos que necessiteu. Una eina més estreta és un filtre de tracció, que descarta una directiva problemàtica i manté la resta:

route-nopull
pull-filter ignore "redirect-gateway"

Useu una cosa o l’altra, no totes dues, i tingueu clar què canvia. Sense ruta per defecte pel túnel, el servidor ja no navega per internet a través del proveïdor; només arriba al que heu encaminat explícitament. Si el túnel complet era tot el propòsit de la configuració, aquesta és la palanca equivocada i la ruta d’host de dalt és la correcta.

Partiu el camí de tornada per origen o per connexió

Quan l’adreça entrant és estable, una regla d’origen manté les respostes locals sense tocar les rutes pròpies del túnel. Doneu a l’adreça de la interfície física la seva pròpia taula amb el prefix LAN i la ruta per defecte física, i després seleccioneu aquesta taula per al trànsit que en prové:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

Això funciona perquè les respostes a una connexió SSH entrant surten de l’adreça a la qual es va connectar el client. Un cas reportat en què cada servei entrant havia de continuar funcionant va usar exactament aquesta forma. Quan l’adreça entrant flota o el camí és dinàmic, marqueu la connexió: poseu una marca conntrack al primer paquet que arriba per la interfície física, copieu-la als paquets de resposta a OUTPUT i encamineu els paquets marcats per una taula que apunta a la passarel·la física.

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

Manteniu diferents la marca de connexió, la marca de tallafocs i el número de taula mentre proveu. Reutilitzar un número per a dos papers produeix una regla que sembla correcta i encerta els paquets equivocats. L’entrada per defecte de la taula també necessita via amb la passarel·la LAN en un enllaç Ethernet normal; una entrada dev eth0 nua només funciona quan la interfície és punt a punt o el següent salt es resol d’una altra manera. L’amfitrió Jessie reportat va caure en un enllaç on la forma nua funcionava, cosa que no és cap regla de distribució per copiar.

Verifiqueu sense quedar-vos fora

No proveu desconnectant. Manteniu la primera sessió oberta, pugeu el túnel i pregunteu al nucli quin camí prendria la vostra pròpia adreça:

ip route get 80.128.240.55

La resposta hauria de nomenar la interfície física i la passarel·la antiga, no el túnel. Després obriu una segona connexió SSH; aquesta és la prova real, perquè la sessió antiga pot sobreviure amb un estat que una connexió nova no pot reproduir. Si la segona es penja mentre la primera encara respon, la regla no va coincidir mai amb el trànsit que importa, i les marques o l’adreça d’origen són on cal mirar.

Tingueu una consola fora de banda disponible durant tot l’exercici. Un servidor el únic camí d’accés del qual és el túnel que acabeu de trencar no es pot reparar per aquest túnel, i la reversió és més fàcil quan heu anotat els números de taula i els prefixos que heu afegit.