Unha pasarela VPN necesita reenvío IP: que comprobar

O seu cliente pode facer ping á dirección da pasarela mentres todos os recursos que hai detrás seguen inaccesibles. Ese par de observacións describe un host que lle fala e un encamiñador que non encamiña, que son papeis distintos na mesma máquina. O reenvío é o interruptor entre ambos.

Os dous papeis son independentes, e tamén as dúas familias de enderezos.

Responder á súa propia dirección non demostra nada

Cando un paquete se dirixe á propia pasarela, a pila local cónsomeo e non se toma ningunha decisión de reenvío. Por iso un ping correcto á dirección do túnel ou a unha interface de xestión dille que o daemon está vivo e o túnel levantado, pero non di nada sobre o tráfico destinado a unha rede detrás da caixa. O núcleo só consulta a súa ruta de reenvío para paquetes que non van dirixidos a el.

Lea o requisito como un papel, non como un axuste: este host debe mover paquetes entre dúas interfaces. Un portátil que só necesita chegar a unha rede remota nunca asume ese papel, e un extremo sitio a sitio sempre o fai. Ler o requisito así explica por que unha configuración de cliente que funciona falla cando se traslada a unha pasarela.

A mesma frase se aplica á devasa diante da decisión de reenvío, que ten a súa propia política sobre o que se pode reenviar.

Comprobe cada familia de enderezos por separado

O reenvío IPv4 é un interruptor, e o reenvío IPv6 é outro co seu propio comportamento por interface. Activar o primeiro non di nada do segundo, e un cliente de dobre pila pode alcanzar media rede mentres o resto queda ás escuras. Dous clientes de familias distintas poden, polo tanto, discrepar sobre a mesma pasarela. Pregunte que familia usou o cliente que falla antes de editar calquera dos dous axustes. Confirme ambos antes de concluír que o deseño de encamiñamento é incorrecto.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

En moitas distribucións, o valor que le en tempo de execución púxoo alí un servizo ou un ficheiro de configuración, así que un cambio feito cun comando puntual pode desaparecer ao reiniciar. Atope o ficheiro que posúe o axuste antes de editar o valor en tempo de execución.

O reenvío é un de catro requisitos

Un fluxo reenviado que funciona necesita catro cousas á vez: o cliente debe saber que o destino está detrás do túnel, a pasarela debe ter unha ruta cara adiante, as respostas deben ter un camiño de volta e a devasa debe permitir o tráfico. A tradución de orixe pertence a ese deseño como opción e non como regra, porque unha rede encamiñada privada con camiños simétricos non a necesita e unha asimétrica normalmente si. Cada unha das catro falla de forma independente, por iso reparar unha raramente move o síntoma. Escriba as catro antes de cambiar calquera delas.

As plataformas de nube engaden unha quinta consideración. Algunhas aplican comprobacións de orixe e destino nas instancias, o que descarta os paquetes reenviados independentemente de como estea configurado o núcleo do convidado. A documentación de rede da propia plataforma é a autoridade alí, non a saída de sysctl dentro da VM.

Probe desde o cliente, non desde a pasarela

Unha proba executada na propia consola da pasarela non percorre ningunha parte da ruta de reenvío que acaba de habilitar. Xere o tráfico desde o cliente que ten o problema e confirme que chega a algo detrás da pasarela e non á pasarela mesma. Esa é a única proba que exercita o papel que cambiou.

Manteña separadas as regras de escoita e as regras de reenvío na cabeza e no rexistro de cambios. Abrir o porto VPN admite clientes ao servizo; non lles concede nada na rede de detrás, e ambos parecen idénticos nunha lista de devasa que medrou durante anos.

Se os paquetes chegan e o servizo despois rexeita o usuario, xa pasou da rede. Continúe coa autorización da aplicación en lugar de ampliar de novo a política de reenvío.