El handshake de PiVPN funciona, las páginas se atascan: revise la MASQUERADE

Su teléfono muestra el túnel como conectado, el cliente informa de una dirección privada y la primera página sigue colgada a mitad de carga. Esa combinación envía a la mayoría a los ajustes de cifrado y a la temperatura de la CPU, donde en realidad no hay nada mal. El túnel se levantó, así que la negociación terminó; lo que falló es el paso siguiente, cuando el servidor intenta entregar los paquetes del cliente a internet. Recorra el mismo camino que toman esos paquetes y la discrepancia suele verse en una línea de la tabla NAT.

Empiece por lo que el cliente puede y no puede alcanzar

Desde el cliente conectado, cargue una página que viva en el internet público y anote si falla al instante o se atasca a mitad de camino. Después abra un recurso en la dirección privada del propio servidor VPN y compare los dos resultados.

Una dirección de túnel que responde a ping mientras los sitios públicos agotan el tiempo es la señal de un problema de reenvío o de traducción, no de un handshake roto. El panel de estado del propio cliente no puede distinguirlos, porque solo sabe que el canal de control está activo. Compruebe en el servidor la interfaz del túnel con ip -br addr show tun0 y confirme que la dirección asignada al cliente cae dentro del grupo que configuró. Si el grupo y la dirección del cliente no coinciden, corríjalo primero, porque cada regla de abajo coincide con el grupo.

A continuación, pregunte al servidor qué interfaz usaría para llegar a una dirección pública. ip route get 203.0.113.9 imprime el dispositivo y la fuente elegidos en su primera línea. Anote el nombre del dispositivo, porque es el valor que debe contener la regla NAT.

Lea la regla que decide si los paquetes salen

MASQUERADE reescribe un paquete solo cuando el paquete sale por la interfaz nombrada en la regla. Una regla limitada a un dispositivo por cable no hace nada por el tráfico que sale por Wi-Fi, y el paquete conserva su dirección de origen privada hasta el router superior. Ese router no tiene ruta de vuelta a su grupo del túnel, así que descarta la respuesta, y el cliente ve una conexión que se abre y luego muere. El síntoma crece con la cantidad de página que llega antes de que haga falta la primera respuesta.

Liste la tabla viva y lea la columna de interfaz de salida en lugar de buscar solo la palabra MASQUERADE. La salida en forma de agregar es más fácil de comparar que un listado formateado:

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

En una Raspberry Pi que antes usaba Ethernet y ahora usa Wi-Fi, el nombre obsoleto es casi siempre toda la historia. El instalador registró qué dispositivo estaba presente durante la instalación, y el conjunto de reglas guardado lo repite en cada arranque. Compare el dispositivo de la búsqueda de ruta con el de la regla antes de cambiar cualquier otra cosa. Si coinciden, la interfaz no es su problema y debería pasar a los contadores de la última sección. Si difieren, la corrección es un cambio de una palabra en el archivo de persistencia.

Corrija el conjunto de reglas guardado, no solo el que está en marcha

Editar solo la tabla viva aguanta hasta el siguiente reinicio, que es exactamente el tiempo suficiente para convencerle de que el problema está resuelto. Las reglas que vuelven al arranque viven en un archivo que recarga un paquete de persistencia del cortafuegos. En las imágenes de Pi basadas en Debian ese archivo suele ser /etc/iptables/rules.v4.

Haga una copia antes de tocarlo, luego sustituya la interfaz de salida en la línea de MASQUERADE por el dispositivo que anotó, por ejemplo -o wlan0 en lugar de -o eth0. Deje el rango de origen como está, salvo que su grupo de clientes haya cambiado. Recargue y confirme que la regla ya nombra el 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

Dos ajustes contiguos son fáciles de olvidar. sysctl net.ipv4.ip_forward debe informar de 1, y el router superior no debe filtrar por su cuenta las direcciones de origen privadas.

Demuestre que la regla se dispara y luego aísle qué sigue lento

Los contadores son la única prueba honesta de que una regla ha coincidido. Ejecute el listado detallado, inicie una descarga en el cliente y ejecútelo de nuevo. Las columnas de paquetes y bytes junto a su regla deberían subir, y una regla que se queda en cero todavía no coincide. Si los contadores se mueven pero las páginas siguen fallando, compare el rango de origen con el grupo real con grep -n "^server " /etc/openvpn/server.conf. Si se mueven y las páginas cargan pero el rendimiento es pobre, la traducción está hecha y el problema restante está en otro sitio.

Compare dos transferencias del mismo cliente, una a un equipo de la red local y otra por el túnel a ese mismo equipo. Lento en ambos casos apunta al enlace ascendente de la Pi o a la conexión Wi-Fi, no al VPN. Lento solo por el túnel apunta a la MTU y a las retransmisiones, que puede inspeccionar con ip -s link show tun0 antes de cambiar cualquier ajuste de cifrado.

Para deshacer el experimento, restaure la copia y vuelva a cargarla, luego confirme que la regla original y sus contadores han vuelto. Escriba el dispositivo de salida y el comando de recarga en las notas del servidor, porque el próximo cambio de enlace ascendente redescubrirá la misma discrepancia. Una regla que nombra el dispositivo equivocado permanece invisible hasta que el tráfico la necesita.