O handshake de PiVPN funciona, as páxinas atascan: revise a MASQUERADE

O seu teléfono mostra o túnel como conectado, o cliente informa dun enderezo privado e a primeira páxina segue colgada a metade da carga. Esa combinación envía a maioría da xente aos axustes de cifrado e á temperatura da CPU, onde en realidade non hai nada mal. O túnel levantouse, así que a negociación rematou; o que fallou é o paso seguinte, cando o servidor tenta entregar os paquetes do cliente a internet. Percorra o mesmo camiño que toman eses paquetes e a discrepancia adoita verse nunha liña da táboa NAT.

Comece polo que o cliente pode e non pode alcanzar

Desde o cliente conectado, cargue unha páxina que viva na internet pública e anote se falla ao instante ou atasca a metade de camiño. Despois abra un recurso no enderezo privado do propio servidor VPN e compare os dous resultados.

Un enderezo de túnel que responde a ping mentres os sitios públicos esgotan o tempo é o sinal dun problema de reenvío ou de tradución, non dun handshake roto. O panel de estado do propio cliente non pode distinguilos, porque só sabe que a canle de control está activa. Comprobe no servidor a interface do túnel con ip -br addr show tun0 e confirme que o enderezo asignado ao cliente cae dentro do grupo que configurou. Se o grupo e o enderezo do cliente non coinciden, corríxao primeiro, porque cada regra de abaixo coincide co grupo.

A continuación, pregunte ao servidor que interface usaría para chegar a un enderezo público. ip route get 203.0.113.9 imprime o dispositivo e a fonte elixidos na súa primeira liña. Anote o nome do dispositivo, porque é o valor que debe conter a regra NAT.

Lea a regra que decide se os paquetes saen

MASQUERADE reescribe un paquete só cando o paquete sae pola interface nomeada na regra. Unha regra limitada a un dispositivo por cable non fai nada polo tráfico que sae por Wi-Fi, e o paquete conserva o seu enderezo de orixe privado ata o router superior. Ese router non ten ruta de volta ao seu grupo do túnel, así que descarta a resposta, e o cliente ve unha conexión que se abre e logo morre. O síntoma medra coa cantidade de páxina que chega antes de que faga falta a primeira resposta.

Liste a táboa viva e lea a columna de interface de saída en lugar de buscar só a palabra MASQUERADE. A saída en forma de engadir é máis fácil de comparar que unha listaxe formatada:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Nunha Raspberry Pi que antes usaba Ethernet e agora usa Wi-Fi, o nome obsoleto é case sempre toda a historia. O instalador rexistrou que dispositivo estaba presente durante a instalación, e o conxunto de regras gardado repíteo en cada arranque. Compare o dispositivo da busca de ruta co da regra antes de cambiar calquera outra cousa. Se coinciden, a interface non é o seu problema e debería pasar aos contadores da última sección. Se difiren, a corrección é un cambio dunha palabra no ficheiro de persistencia.

Corrixa o conxunto de regras gardado, non só o que está en marcha

Editar só a táboa viva aguanta ata o seguinte reinicio, que é exactamente o tempo suficiente para convencelo de que o problema está resolto. As regras que volven ao arranque viven nun ficheiro que recarga un paquete de persistencia do cortafuegos. Nas imaxes de Pi baseadas en Debian ese ficheiro adoita ser /etc/iptables/rules.v4.

Faga unha copia antes de tocalo, despois substitúa a interface de saída na liña de MASQUERADE polo dispositivo que anotou, por exemplo -o wlan0 en lugar de -o eth0. Deixe o rango de orixe como está, salvo que o seu grupo de clientes cambiase. Recargue e confirme que a regra xa nomea o dispositivo correcto:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Dous axustes contiguos son fáciles de esquecer. sysctl net.ipv4.ip_forward debe informar de 1, e o router superior non debe filtrar pola súa conta os enderezos de orixe privados.

Demostre que a regra se dispara e despois illé qué segue lento

Os contadores son a única proba honesta de que unha regra coincidiu. Execute a listaxe detallada, inicie unha descarga no cliente e execútea de novo. As columnas de paquetes e bytes xunto á súa regra deberían subir, e unha regra que queda en cero aínda non coincide. Se os contadores se moven pero as páxinas seguen fallando, compare o rango de orixe co grupo real con grep -n "^server " /etc/openvpn/server.conf. Se se moven e as páxinas cargan pero o rendemento é pobre, a tradución está feita e o problema restante está noutro sitio.

Compare dúas transferencias do mesmo cliente, unha a un equipo da rede local e outra polo túnel a ese mesmo equipo. Lento en ambos os casos apunta ao enlace ascendente da Pi ou á conexión Wi-Fi, non ao VPN. Lento só polo túnel apunta á MTU e ás retransmisións, que pode inspeccionar con ip -s link show tun0 antes de cambiar calquera axuste de cifrado.

Para desfacer o experimento, restaure a copia e vólvaa cargar, despois confirme que a regra orixinal e os seus contadores volveron. Escriba o dispositivo de saída e o comando de recarga nas notas do servidor, porque o próximo cambio de enlace ascendente redescubrirá a mesma discrepancia. Unha regra que nomea o dispositivo equivocado permanece invisible ata que o tráfico a necesita.