Dúas portas de enlace, unha VPN: por que OpenVPN escolle o enlace ascendente incorrecto

Dous enlaces ascendentes, un túnel, e o tráfico sae polo que non escolliches. As subredes privadas son accesibles, o rexistro informa dunha conexión correcta e é o enlace medido o que a transporta. Nada na saída de OpenVPN menciona unha porta de enlace, porque o cliente nunca escolleu unha. Abriu un socket cara a unha dirección remota e deixou que o núcleo decidise como chegar a esa dirección.

A dirección do túnel non é o extremo

En cada sesión existen dous camiños distintos. O camiño exterior transporta o tráfico cifrado ata a dirección pública do servidor. O camiño interior transporta todo o que o servidor empuxa dentro do túnel, e as regras de encamiñamento dun non afectan ao outro.

A entrada remote do perfil nomea o destino exterior, así que esa é a dirección que hai que fixar. Tamén é o valor que cambia cando un nome de host se resolve de forma distinta ou o perfil enumera varios remote.

Atopa a dirección á que o cliente marcou de verdade

Le o socket activo en lugar do ficheiro de configuración. A táboa de sockets mostra o par ao que o proceso se conectou realmente, e ese é o valor co que debe coincidir a excepción. Un perfil pódese editar despois de que comece a sesión, e o socket é a única proba do que se marcou:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

A liña do rexistro indica a dirección e o porto do par no momento da conexión. Se non coincide co perfil, algo diante do cliente reescribe o destino antes de que comece a conexión.

Comproba tamén a familia de direccións. Un perfil de dobre pila pode conectarse por IPv6 mentres a túa excepción só cobre IPv4, e entón o tráfico segue unha regra distinta da que escribiches. O mesmo vale para un proxy que responde no nome do extremo. Ambos os casos producen un túnel que funciona mentres a túa ruta non fai nada.

Fixa o extremo e le a orde da política

Unha ruta de host é máis específica que calquera ruta predeterminada. Por iso unha /32 para a dirección do par gaña dentro da táboa que a contén. A forma habitual nomea explicitamente a porta de enlace e o dispositivo:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Esa ruta só axuda se a busca chega a esa táboa. As regras de política avalíanse en orde e a primeira coincidencia decide, así que unha regra que envía todo a unha segunda táboa omite a túa ruta de host en main. Le as regras antes de supor que a ruta é autoritativa:

ip rule show
ip route get 203.0.113.40

Pregunta ao segundo comando coa mesma dirección de orixe ou marca que usa o cliente cando a política depende delas. Informa da ruta que o núcleo escollería, o que é unha proba sobre a busca e non unha proba de que o socket activo use ese camiño.

Cando o extremo se move

Un nome de host que se resolve en varias direccións invalida unha /32 permanente en canto cambia a resposta. Un perfil con varias liñas remote ten o mesmo problema, porque o cliente pode aterrar en calquera delas. Refresca a ruta desde os propios ganchos do ciclo de vida do cliente en lugar de engadila a man. Un script up que le o par negociado e instala a ruta de host mantén a excepción aliñada coa realidade, e un script down correspondente retíraa.

Rexistra o refresco no mesmo lugar que o resto da configuración de encamiñamento do host. Unha ruta que só existe ata o próximo reinicio é unha proba, non unha corrección.

Mantén a política interior separada

Mover o camiño exterior non dá acceso a unha nova subrede privada nin cambia que destinos empuxa o servidor dentro do túnel. A ruta da capa inferior escolle o cable; as rutas empuxadas escollen que entra no túnel. Manter esas dúas decisións separadas é o que fai previsible a división.

Se o obxectivo só é manter o tráfico cifrado fóra dun enlace medido, deixa a ruta predeterminada tranquila e engade a única excepción de host. Substituír a ruta predeterminada de toda a máquina para mover unha soa conexión VPN rompe calquera outra aplicación do host.

Confirma o resultado con dúas observacións independentes: a dirección local e o dispositivo do socket, e a ruta á que se resolve o destino privado. Cando ambas coinciden coa túa intención, a división é real. O manual de OpenVPN 2.6 cobre as opcións remote e de vinculación local que deciden a que dirección marca o cliente.