Os clientes VPN conéctanse pero non teñen internet: tres pezas que faltan

O cliente obtén un enderezo, o servidor responde aos ping e, aínda así, cada páxina acaba caducando. A maioría da xente comeza a editar o perfil do cliente neste punto, o que adoita ser un esforzo perdido: unha vez levantado o túnel, o servidor ten que comportarse como un enrutador. Tres condicións deben cumprirse á vez antes de que un paquete saia e volva unha resposta, e o síntoma é idéntico calquera que falte.

Por que un túnel que funciona aínda non ten saída

O núcleo debe reenviar paquetes entre interfaces, o que está desactivado por defecto na maioría das distribucións de Linux. O tráfico debe traducirse a un enderezo ao que o mundo exterior poida responder, salvo que cada enrutador ascendente xa coñeza a ruta de volta á subrede do túnel. A ruta de reenvío da devasa debe permitir o tráfico en ambos os sentidos, incluídas as respostas.

Cada unha delas pódese corrixir por separado, e aí está a trampa. Activar o reenvío sen unha regra de tradución deixa os paquetes saíndo cunha fonte privada e sen ruta de volta. Engadir a tradución sen unha regra de reenvío deixa o núcleo descartando o paquete un paso despois.

Así que probe as tres capas en lugar do cliente, e cambie unha cada vez para que o resultado signifique algo.

O reenvío é un interruptor do núcleo que hai que facer persistente

Comprobe o valor actual antes de cambialo, logo establézao e confirme que o cambio surtiu efecto.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

O primeiro comando informa do valor actual, o segundo establéceo en tempo de execución e o terceiro demostra que a escritura funcionou. O valor en tempo de execución desaparece no seguinte reinicio, e por iso unha sesión que funciona pode romper tras un mantemento sen ningún cambio de configuración.

Fagao permanente nun ficheiro baixo /etc/sysctl.d/, e despois aplique ese ficheiro en lugar de reiniciar para descubrilo. En FreeBSD o equivalente é net.inet.ip.forwarding, con gateway_enable=YES en rc.conf para a persistencia. Un equipo que informa do reenvío desactivado explica toda unha clase de informes de «chegan paquetes e non volve nada». Revise o axuste despois de cada actualización tamén, porque un núcleo reconstruído ou unha imaxe de equipo substituída poden restablecelo sen avisar a ninguén.

Escolla masquerade ou un enderezo de tradución fixo

Cun enderezo exterior dinámico, masquerading é a forma correcta máis sinxela. Nomee a subrede do túnel como orixe e a interface exterior como saída.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Cun enderezo público estático, a tradución de orixe a ese enderezo exacto é máis predicible e máis fácil de auditar.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

A segunda forma leva unha trampa de mantemento: un enderezo codificado de forma fixa que logo cambia mantén o túnel funcionando mentres o acceso a internet se detén en silencio. Ou use masquerade ou actualice a regra cada vez que o provedor o mova. A interface tamén importa, porque un enrutador que comparte o seu propio túnel ascendente ten que traducir por ese túnel e non pola WAN física.

A táboa de filtros é a terceira porta

O reenvío e a tradución poden ser ambos correctos mentres o paquete segue morrendo na táboa de filtros. ufw é un culpable frecuente: a súa política de reenvío chega como DROP, e o resto da configuración pode parecer perfectamente correcta mentres ese único axuste mata o tráfico. Subila é unha decisión de seguridade deliberada e non unha caixa de verificación.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

A primeira regra permite tráfico novo do túnel cara a fóra, e a segunda só as respostas de volta. Estreite ambas á subrede do túnel e ao destino que pretende, porque unha aceptación xeral na interface do túnel converte a VPN nun punto de saída aberto para calquera que poida autenticarse.

Un túnel ponte necesita outra resposta. O enderezo pertence á ponte, non ao porto físico, así que escravizar a interface elimina o enderezo que antes tiña e a máquina parece inalcanzable ata que a propia ponte recibe un, que dhclient br0 pode proporcionar. Ese fallo parece un problema de VPN e é un problema de capa dous. Revise o enderezo propio da ponte antes de tocar a devasa, porque un cambio de filtro non pode arranxar unha máquina que xa non ten enderezo desde o que enviar.

Onde mirar cando unha páxina nunca carga

Faga ping ao enderezo do túnel do servidor para probar que o túnel existe. Despois execute un traceroute desde o cliente a un enderezo público e lea onde se detén: no servidor o paquete chega pero non se reenvía nin se traduce; máis aló do servidor o problema está augas arriba e fóra das súas mans.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

O primeiro comando proba que o túnel leva tráfico ata o propio servidor, e o segundo mostra ata onde chega un paquete cara a fóra. Unha traza que remata no enderezo do túnel apunta ao reenvío ou á tradución no servidor, mentres que unha traza que se detén un salto despois apunta ao provedor ou á ruta de volta do enrutador ascendente.

No servidor, observe a interface exterior mentres un cliente carga unha páxina. O tráfico que sae cun enderezo de orixe privado significa que falta a tradución, e a ausencia total de resposta significa que a ruta de reenvío ou a ruta de volta ascendente o está descartando.

Se os clientes remotos tamén deben chegar a máquinas da LAN do servidor, lembre que a LAN necesita unha ruta de volta á subrede do túnel. Iso é encamiñamento e non tradución, e é o paso que máis a miúdo se esquece cando a ruta a internet por fin funciona.