Por que unha resposta UDP de OpenVPN sae dun enderezo incorrecto

Un cliente de OpenVPN marca un enderezo, o servidor responde desde outro e o túnel nunca se levanta. O rexistro do servidor mostra que o paquete chega e unha captura mostra que a resposta sae, así que o fallo se atribúe ao cliente. Nun equipo con varias interfaces, ou con varios enderezos nunha soa interface, as dúas partes simplemente non coinciden sobre que enderezo está en uso. A resposta é válida na capa IP, pero moitos clientes descartan un datagrama cuxa orixe non é o enderezo co que contactaron.

Que ve o cliente cando cambia a orixe

Un socket UDP non ligado a un enderezo local concreto non ten unha orixe fixa, así que o núcleo elixe unha ao enviar. Esa elección vén dunha consulta de ruta cara ao enderezo do cliente, e a orixe pasa a ser o enderezo da interface que selecciona a consulta. Nunha máquina cunha soa interface a elección é invisible; nun equipo cun enderezo de xestión, un enderezo público e un enderezo secundario na mesma tarxeta de rede, depende das métricas e da política de encamiñamento. O encamiñamento por políticas fai a discrepancia máis probable en lugar de menos, porque unha regra pode seleccionar un enlace ascendente ao que o cliente nunca chegou. Unha ruta predeterminada aprendida dun provedor máis unha regra de orixe que apunta a outro abonda para producila.

Os clientes que filtran respostas, e o seguimento de conexións que espera a cuádrupla exacta e a orixe, descartarán a resposta sen unha mensaxe útil. Entón o túnel expira coma se non chegase nada, e por iso isto se confunde cun problema de devasa no lado do cliente. Unha captura tomada só no servidor confirma o erro en lugar de explicalo, porque a resposta si sae. Compare a orixe da resposta co enderezo ao que marcou o cliente antes de cambiar calquera outra cousa.

Que fai realmente a opción multihome

A directiva escríbese multihome nun ficheiro de configuración e --multihome na liña de ordes, e fai que un servidor UDP responda desde o enderezo ao que chegou o paquete do cliente. O núcleo entrega o enderezo de destino orixinal como datos auxiliares ao recibir, e OpenVPN usa ese valor como orixe da resposta. Así, un servidor que escoita nun enderezo comodín, local 0.0.0.0 para IPv4 ou o seu equivalente IPv6, compórtase coma se cada cliente chegase a un oínte dedicado. Os clientes que entraron polo enderezo público reciben respostas desde o enderezo público, e os clientes nun enderezo interno recíbenas desde ese. Nada máis na ruta do paquete se move: a ruta, as regras de filtro e a configuración do túnel quedan exactamente como estaban.

Esa última propiedade é a razón pola que a opción é segura de engadir a un servidor que xa funciona, e tamén a razón pola que non pode reparar un filtro que só permite un enderezo. O paquete aínda ten que aceptarse na ruta que segue, así que a corrección da orixe cambia a orixe da resposta e nada máis. Tamén é só para UDP: un oínte TCP non ten este problema na mesma forma, porque a conexión identifícase pola cuádrupla e non polo enderezo de orixe da resposta.

Cando un enderezo local fixo é o valor predeterminado incorrecto

Antes de recorrer á opción, comprobe se o servidor liga un enderezo local concreto, porque un oínte ligado sempre responde desde ese enderezo. Iso é correcto para un despregamento dunha soa interface e incorrecto en canto os clientes usan lexitimamente máis dun enderezo. Se a ligazón foi deliberada, decida se o servidor debe aceptar tráfico en enderezos adicionais. Quitar a ligazón aumenta a exposición, así que as interfaces e as redes de orixe permitidas teñen que impolas o servizo e o filtro, non só o enderezo de ligazón.

A referencia de OpenVPN limita a opción a servidores UDP, anota o procesamento adicional na ruta do paquete e rexistra que plataformas a admiten. Confírmeo na versión instalada antes de planificar arredor dela. Onde non se admite, a alternativa é ligar o enderezo concreto ou corrixir o encamiñamento de retorno, e ambos son cambios máis estreitos do que parecen á primeira vista. Escoitar en comodín tamén ten consecuencias máis alá das respostas: un servidor en todos os enderezos é alcanzable desde cada rede á que está conectado o equipo, e pode que esa non sexa a exposición que alguén pretendía.

Demostre a orixe da resposta desde fóra

Probe desde fóra do servidor e anote o enderezo e o transporte exactos que usou o cliente antes de capturar nada. As tres probas de abaixo responden a tres preguntas distintas, e a orde importa.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

A captura mostra o enderezo de orixe na resposta, que é o feito sobre o que xira todo o artigo. A listaxe de sockets mostra que ligou realmente o servidor, porque un oínte comodín e un concreto vense idénticos nun ficheiro de configuración e compórtanse distinto na rede. A consulta de ruta mostra a orixe que o núcleo elixiría para ese fluxo, o que explica a captura antes de que cambie nada. Repita as tres para IPv4 e IPv6 por separado, porque son oíntes separados e consultas separadas, e unha entrada comodín para unha familia non di nada da outra.

Encamiñamento, descuberta e filtrado seguen separados

Preservar a orixe da resposta non instala unha ruta de saída, non actualiza o DNS dinámico nin fai que unha familia de enderezos acepte a outra. Nun servidor con varios enlaces ascendentes, a ruta de retorno de cada orixe ten que acordarse deliberadamente, ou as respostas saen por unha interface que o filtro do cliente nunca permitiu. Do mesmo xeito, un enderezo novo tras un cambio de prefixo ten que chegar aos clientes mediante a descuberta e o fluxo de reconexión admitido, non mediante o rexistro antigo.

Deixe as comprobacións de identidade do servidor e a verificación de certificados exactamente como están, porque un enderezo cambiado non xustifica aceptar un par non verificado. Se a resposta agora sae da orixe prevista e o túnel segue fallando, dea por resolta a cuestión da orixe e siga adiante. O seguinte erro observado pertence ao encamiñamento, ao filtrado ou á autenticación, e volver cambiar o oínte non chegará a el. Escriba a orixe da resposta no tícket xunto ao enderezo ao que marcou o cliente, para que a seguinte persoa poida comprobar o mesmo feito cunha soa orde.