Conectado a OpenVPN pero nada carga: un percorrido desde o cliente

A xanela do cliente di Conectado, o enderezo do túnel está aí, e o navegador segue xirando. Esa combinación é normal, porque un handshake correcto só demostra que o túnel se construíu; non di nada sobre se o servidor reenviará os teus paquetes, reescribirá a súa orixe ou responderá as túas consultas DNS. O erro que comete a maioría é abrir primeiro a configuración do servidor. En lugar diso, avanza desde o cliente cara a fóra, porque cada paso de abaixo che di se o seguinte sequera merece revisarse.

Comeza no cliente e avanza cara a fóra

Fai tres probas nesta orde e anota onde falla a primeira. Fai ping ao enderezo do túnel do servidor, o que demostra que o túnel mesmo transporta tráfico. Fai ping a un enderezo público por número, o que demostra o reenvío e a tradución sen implicar a resolución de nomes. Despois tenta resolver un nome de host, que é a única proba que exercita o DNS. Cada resultado quita unha capa enteira de sospeita.

Non saltes á terceira proba porque o navegador parece máis rápido. Unha carga de páxina fallida cobre as tres capas á vez, e por aí empeza a xente que despois reconstrúe un túnel que funcionaba. Unha páxina que falla non che di cal das tres se rompeu.

Dúas capturas mostran onde se deteñen os paquetes

Cun ping a un enderezo público correndo desde o cliente, toma unha captura na interface do túnel e outra na ligazón ascendente que se supón chega a internet. Executa ambas á vez para que as marcas de tempo coincidan.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Se as peticións aparecen no túnel e nunca na ligazón ascendente, o servidor descartounas entre o túnel e o cable, e a causa é o reenvío ou a política de devasado do reenvío, non o NAT. Se aparecen en ambos, o servidor fixo a súa parte e a resposta falta máis fóra, o que apunta á tradución, a un filtro augas arriba ou a unha restrición do provedor.

Toma o nome da ligazón ascendente da táboa de rutas, non dun titorial. As imaxes de nube e os adaptadores renomeados raramente coinciden coa interface de exemplo dunha guía, e unha captura tomada no dispositivo equivocado vese exactamente como un servidor que non reenvía:

ip -4 route get 9.9.9.9

O campo dev desa saída é o nome que a regra NAT necesitará despois, así que gárdao.

O reenvío é un interruptor do núcleo e unha política de devasado

O núcleo ten que aceptar reenviar, como mínimo. Le o valor actual e despois fai permanente o axuste en lugar de escribilo só no núcleo en execución:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

O reenvío é só a metade. Nun host con UFW a política de reenvío defínese en /etc/default/ufw e debe ser ACCEPT antes de que unha recarga surta efecto. Un descarte por defecto na ruta de reenvío deixa o handshake perfectamente san mentres descarta en silencio cada paquete que tenta saír polo túnel, que é exactamente o síntoma co que comezaches.

Os hosts que xestionan nftables directamente teñen a mesma pregunta con outra sintaxe. Mira os contadores da cadea de reenvío mentres corre unha proba desde o cliente, porque unha cadea que se consulta e unha cadea que descarta vense idénticas nun ficheiro de configuración.

Nomea a interface de saída real na regra NAT

A tradución de orixe corresponde á interface que realmente sae do host, co pool que reparte o servidor. As dúas metades desa regra teñen que describir a realidade, e ningunha é opcional.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

O fallo clásico é unha regra copiada dunha guía que di -o eth0 nunha máquina cuxo adaptador se chama doutro xeito. A regra instálase sen aviso, non coincide con nada, e o cliente segue sen internet. O pool é a outra metade do mesmo erro: se o servidor reparte 10.44.0.0/24 e a regra cobre 10.8.0.0/24, nada coincidirá nunca.

Mira os contadores en lugar de confiar no texto da regra. A listaxe informa paquetes por regra, e unha regra que nunca coincide queda en cero por correcta que pareza. Dálle un minuto de tráfico real do cliente antes de ler nada nese número:

iptables -t nat -L POSTROUTING -v -n

Un reconto de paquetes cero tras unha proba real do cliente significa que a coincidencia está mal, non que o túnel estea roto. En canto coincida, garda o conxunto de regras para que sobreviva a un reinicio; un arranxo que só vive no historial da túa shell desaparece no primeiro reinicio.

Se o servidor tamén é unha instancia NAT na nube, a plataforma tamén ten voz. Unha instancia que traduce enderezos adoita necesitar a comprobación de orixe e destino desactivada onde o provedor ofrece ese axuste, e o propio porto VPN ten que ser alcanzable desde fóra.

O DNS é o segundo fallo detrás do primeiro

Que o ping por enderezo funcione mentres fallan os nomes é un problema do resolutor, e ten a súa propia causa. Un cliente que conserva o seu resolutor local envía esas consultas dentro dun túnel completo e espera unha resposta que nunca chega, porque o resolutor local está agora no lado equivocado da ruta.

Empuxa un resolutor desde o servidor para que o cliente saiba onde preguntar. Dúas entradas dan ao cliente unha alternativa se a primeira non é alcanzable, e ambas deberían ser resolutores que o túnel permita de verdade.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Os clientes de Windows poden volver igualmente ao resolutor local, que é xusto o que block-outside-dns existe para evitar, a cambio de perder nomes que só a rede local pode resolver. Os clientes de Linux con systemd-resolved adoitan ignorar un resolutor empuxado salvo que un script o instale, así que revisa resolvectl status para o dispositivo do túnel antes de concluír que se ignorou o empuxe.

Termina o percorrido tal como o vive un usuario. Carga unha páxina real desde o cliente, confirma o enderezo desde o que sae, reinicia o servidor, volve conectar e repite as tres probas. Esa segunda pasada é a única que demostra que as regras gardadas, a política de devasado e o resolutor empuxado sobreviviron todos xuntos.