O cliente OpenVPN bloquéase cando o seu servidor se executa no mesmo host

Tiña unha máquina de laboratorio que aceptaba un túnel desde un sitio remoto e tamén marcaba cara a unha rede de provedor. O perfil de saída funcionara durante semanas. Despois de engadir o servidor de entrada, o de saída conectábase e logo deixaba de pasar tráfico en cuestión de segundos, ou negábase a arrincar cun erro de enderezo en uso. Os ficheiros de configuración non cambiaran; o host simplemente adquirira un segundo proceso de OpenVPN coa súa propia opinión sobre portos e rutas.

O fallo non é aleatorio e non é un problema de autenticación. Dous daemons nunha máquina compiten polo mesmo socket local e pola mesma táboa de rutas, e o que arrinca ou se reconecta en último lugar adoita gañar. Saber cal destas dúas colisións tes decide onde mirar primeiro.

Le o síntoma ao revés

Comeza por cando morre o túnel. Un erro de bind ao arrincar apunta ao lado que escoita: algo xa posúe ese porto, e OpenVPN négase a arrincar en lugar de compartilo. Un túnel que sobe e logo queda en silencio apunta ao enrutamento, porque unha ruta instalada pola outra instancia pode sacar os paquetes da conexión exterior do seu camiño.

Ambos os casos producen a mesma queixa do usuario, por iso os bucles de reintento e os scripts de vixilancia non arranxan nada. Volven conectar o cliente no mesmo conflito. A primeira pregunta útil é se o proceso segue executándose cando se detén o tráfico.

Un socket e un dispositivo por instancia

Un servidor que escoita enlaza o seu porto; un cliente de saída tamén necesita un porto local para o seu tráfico encapsulado. Cando ambos viven no mesmo host, o comportamento predeterminado do cliente pode chocar co porto do servidor. O porto local do cliente pódese fixar, e a ligazón pódese omitir onde o par non necesita un porto de orixe fixo:

lport 1195
nobind
dev tun1

Eses números son exemplos, non un requisito. O importante é que o cliente deixe de competir polo porto do servidor e que cada instancia obteña un dispositivo de túnel separado. Dous daemons que comparten tun0 sobrescriben o estado do dispositivo do outro mesmo cando os seus portos difiren, así que un dispositivo por túnel non é opcional.

nobind pertence ao lado do cliente. Un servidor aínda debe enlazar e escoitar, así que non copies a liña na configuración do servidor nin desactives a ligazón nun cliente cuxo par filtra por un porto de orixe fixo.

Escolle un único propietario para a ruta predeterminada

Só unha conexión pode instalar unha ruta predeterminada. Se ambos os perfís redirixen todo o tráfico, a segunda conexión substitúe silenciosamente a primeira, e a primeira parece romperse. Ou mantés o túnel de saída dividido e empuxas só os prefixos do provedor, ou dáslle unha táboa de rutas 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

Os enderezos e o número de táboa anteriores son marcadores de posición. Inmediatamente despois de engadir a regra, confirma que o enderezo do propio servidor VPN aínda se resolve pola táboa normal; unha táboa que captura o transporte exterior rompe o túnel que debía protexer, e o bucle de reconexión que segue parece un provedor pouco fiable.

Para unha configuración que debe sobrevivir a reconexións e reinicios, un espazo de nomes de rede é a fronteira máis sólida. O segundo cliente execútase dentro do seu propio espazo de nomes coas súas propias interfaces e rutas, e só se expoñen os servizos que deben cruzar. O host mantén unha ruta predeterminada, e unha reconexión do espazo de nomes non a pode reescribir.

Verifica coa táboa, non coa liña de estado

Un cliente que informa que está conectado só demostra a súa canle de control. Captura o estado de enrutamento antes e despois de cada conexión, e despois pregunta ao núcleo que dispositivo usaría un destino real:

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

Se o dispositivo seleccionado para o enderezo do provedor cambia cando arrinca o segundo túnel, tes a colisión de rutas. Se ambos os procesos aparecen no mesmo porto local, tes a colisión de sockets. Arranxar a primeira sen a segunda só traslada o fallo á seguinte reconexión.

Escribe os portos, dispositivos, táboas e propietario da ruta no runbook do host. Se non, a seguinte persoa que engada un terceiro túnel redescubrirá a mesma colisión, e a única evidencia visible será unha conexión que funciona ata que se reinicie o daemon doutra persoa.