O túnel completo de OpenVPN corta a túa sesión SSH: arranxa o camiño de volta

Activar un cliente OpenVPN de túnel completo nunha máquina á que chegas por SSH pode cortar a sesión nun segundo, e a máquina non fai nada mal. O túnel non cambia como chegan os paquetes ao servidor; cambia como saen as respostas. Cando a ruta por defecto apunta a tun0, unha resposta ao teu cliente SSH entra na rede do provedor, que non ten ruta de volta ao teu enderezo. A conexión colga, o seguinte intento expira e o daemon segue escoitando no porto 22 todo o tempo.

Le a táboa de encamiñamento antes de ler o rexistro do VPN. O rexistro dirá que o túnel subiu, e ten razón. A cuestión é a que interface se entrega cada resposta, e iso é unha consulta por paquete contra unha táboa que o túnel acaba de reescribir.

Por que a resposta sae pola porta equivocada

Os paquetes entrantes seguen chegando pola interface física, porque un cliente VPN non pode cambiar como chega internet ao enderezo público do teu servidor. As respostas son unha decisión aparte: para cada paquete, o núcleo busca o destino, e tras --redirect-gateway a entrada por defecto di túnel. A saída do provedor ve un destino que non serve e descarta o paquete.

A propia protección de OpenVPN cobre exactamente un destino. O manual da 2.6 describe --redirect-gateway como unha secuencia: engade unha ruta de host para o peer VPN a través da pasarela en uso antes do túnel, para que o tráfico cifrado non poida volver dentro de si mesmo, e despois substitúe a ruta por defecto. Esa ruta de host é só para o peer. O teu cliente SSH é só outro enderezo de internet e non recibe excepción ningunha.

Paga a pena descartar pronto un erro de prefixo. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 sen lonxitude coincide co enderezo único 0.0.0.0, non con internet; debe ser 0.0.0.0/0. E se tomar a ruta por defecto rompe o transporte propio do túnel, engade o extremo como ruta de host pola interface física, usando o enderezo real do provedor.

Fixa o enderezo do teu cliente SSH para unha reparación inmediata

A reparación máis rápida é unha ruta de host para o enderezo do teu cliente a través da pasarela que o servidor usaba antes de que existise o túnel. Pola túa parte, atopa o enderezo que verá o servidor e despois le a táboa do servidor para coñecer a pasarela antiga:

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

No servidor, engade a excepción antes de que arranque o cliente. Os enderezos de aquí son marcadores de posición; a forma é o que importa:

sudo ip route add 80.128.240.55 via 192.168.178.1

Esta é a reparación usada no caso reportado, e funciona de inmediato. Tamén é fráxil de dous xeitos previsibles: a ruta desaparece ao reiniciar e vólvese incorrecta no momento en que o teu ISP che dá outro enderezo. Trátaa como medida de emerxencia e faina duradeira a propósito, mediante unha unidade de rede ou un gancho do despachador, ou acepta que é temporal e anota o camiño de recuperación.

Impide que o cliente tome a ruta por defecto

A opción máis limpa é impedir que o túnel substitúa a ruta por defecto. route-nopull, usado con --client ou --pull, acepta as opcións empurradas agás as rutas, block-outside-dns e as opcións de estilo DHCP como os servidores DNS, así que só engades os prefixos que necesitas. Unha ferramenta máis estreita é un filtro de tracción, que descarta unha directiva problemática e conserva o resto:

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

Usa unha ou outra, non ambas, e ten claro que cambia. Sen ruta por defecto polo túnel, o servidor xa non navega por internet a través do provedor; só chega ao que encamiñaches explicitamente. Se o túnel completo era todo o propósito da configuración, esta é a panca equivocada e a ruta de host de arriba é a correcta.

Divide o camiño de volta por orixe ou por conexión

Cando o enderezo entrante é estable, unha regra de orixe mantén as respostas locais sen tocar as rutas propias do túnel. Dá ao enderezo da interface física a súa propia táboa co prefixo LAN e a ruta por defecto física, e despois selecciona esa táboa para o tráfico que vén dela:

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

Isto funciona porque as respostas a unha conexión SSH entrante saen do enderezo ao que se conectou o cliente. Un caso reportado no que cada servizo entrante debía seguir funcionando usou exactamente esta forma. Cando o enderezo entrante flota ou o camiño é dinámico, marca a conexión: pon unha marca conntrack no primeiro paquete que chega pola interface física, cópiaa aos paquetes de resposta en OUTPUT e encamiña os paquetes marcados por unha táboa que apunta á pasarela 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

Mantén distintas a marca de conexión, a marca de cortalumes e o número de táboa mentres probas. Reutilizar un número para dous papeis produce unha regra que parece correcta e acerta os paquetes equivocados. A entrada por defecto da táboa tamén necesita via coa pasarela LAN nunha ligazón Ethernet normal; unha entrada dev eth0 espida só funciona cando a interface é punto a punto ou o seguinte salto se resolve doutro xeito. O host Jessie reportado estaba nunha ligazón onde a forma espida funcionaba, o que non é unha regra de distribución que copiar.

Verifica sen quedares fóra

Non probes desconectando. Mantén a primeira sesión aberta, sobe o túnel e pregúntalle ao núcleo que camiño tomaría o teu propio enderezo:

ip route get 80.128.240.55

A resposta debería nomear a interface física e a pasarela antiga, non o túnel. Despois abre unha segunda conexión SSH; esa é a proba real, porque a sesión antiga pode sobrevivir cun estado que unha conexión nova non pode reproducir. Se a segunda colga mentres a primeira aínda responde, a regra nunca coincidiu co tráfico que importa, e as marcas ou o enderezo de orixe son onde hai que mirar.

Ten unha consola fóra de banda dispoñible durante todo o exercicio. Un servidor cuxo único camiño de acceso é o túnel que acabas de romper non se pode reparar por ese túnel, e a reversión é máis doada cando anotaches os números de táboa e os prefixos que engadiches.