Desaparecen as respostas da VPN en Linux? Comprobe rp_filter e a ruta

As peticións saen da máquina, o par da VPN responde e a resposta nunca chega ao socket. O túnel está levantado, os rexistros do par mostran que o paquete se envía e nada na aplicación explica o silencio. En Linux un dos sospeitosos habituais é o filtrado de ruta inversa: un paquete IPv4 entrante pode rexeitarse cando a validación de orixe non coincide coa ruta que o núcleo espera para esa orixe. Percorrelo en orde dille se iso é a causa ou unha coincidencia. Tamén lle evita desactivar un control de seguridade para arranxar unha ruta que falta.

Que decide a validación de orixe

O núcleo comproba se o enderezo de orixe dun paquete é verosímil para a interface pola que chegou, consultando a táboa de enrutamento para unha ruta de volta a esa orixe. Se a ruta inversa apunta a outro sitio, o paquete pode descartarse antes de que o vexa calquera regra de devasas ou socket da aplicación. Esa comprobación existe para dificultar certos patróns de suplantación, e tamén é o motivo polo que os deseños asimétricos e enrutados por política tropezan con ela mentres que calquera cliente corrente da mesma rede funciona ben. Os clientes correntes teñen enrutamento simétrico, que é exactamente o que supón a comprobación.

A palabra importante é verosímil. O paquete pode ser perfectamente lexítimo e aínda así fallar a comprobación, porque non se está probando a lexitimidade.

Lea o modo efectivo, non un só campo

Existen tres modos: desactivado, estrito e laxo. O estrito impón unha expectativa de ruta distinta da do laxo, e o axuste global interactúa cos de cada interface, así que ler un só ficheiro pode describir mal o que está realmente en vigor. Lea ambos, e léaos na interface que recibe a resposta, non na da ruta predeterminada.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

A consulta de ruta desa terceira liña é a parte que a xente se salta. Dille que cre o núcleo sobre a orixe, que é exactamente a entrada da comprobación.

Atope a discrepancia antes de cambiar a comprobación

Averigüe por que a resposta chega por esa interface e se a súa ruta inversa debería ser distinta. Unha regra de política que envía as peticións por un camiño mentres as respostas volven por outro é un deseño lexítimo, e tamén é o deseño que rexeita a validación estrita. As marcas usadas no enrutamento por política tamén poden importar aquí, porque cambian o que devolve a consulta inversa.

Se a ruta inversa simplemente falta, engadila arranxa a causa en lugar de desactivar unha comprobación. Unha ruta que falta, un rexeitamento da devasa e un selector de tráfico equivocado producen o mesmo síntoma visible, e só un deles ten que ver coa validación de orixe.

Non desactive as comprobacións de orixe globalmente como primeira resposta. Iso cambia un diagnóstico concreto por un cambio de comportamento amplo que terá que recordar despois.

Un axuste selectivo que pode defender

Se un axuste estreito é realmente necesario, limíteo á interface que o necesita, anote por que e póñao na configuración que posúe esa interface para que sobreviva a un reinicio. Despois volva probar o fluxo exacto que fallou, da mesma orixe ao mesmo destino, en lugar dun ping a algo cómodo.

Inclúa un caso que aínda debería rexeitarse. Se ese caso agora ten éxito, o axuste debilitou máis que o único camiño que quería reparar.

Manteña IPv4 e IPv6 separados

Un sysctl de aspecto familiar non é unha política para cada familia de enderezos. IPv6 ten o seu propio comportamento e os seus propios axustes, e unha máquina pode ser estrita nunha familia e permisiva na outra sen que ninguén o note ata que falla un destino concreto. Comprobe ambos se a carga de traballo usa ambos.

Rexistre o modo, a interface, a saída da consulta de ruta e o motivo do cambio nun só lugar. A seguinte persoa atopará o axuste e ningunha explicación, e ou o quitará ou o copiará onde non corresponde.