El túnel VPN nunca conecta: dónde se detienen realmente los paquetes

El cliente no deja de reintentar, el registro se detiene antes de que se complete el handshake y el servidor no anota absolutamente nada. Ese patrón aleja de las credenciales y apunta al camino: algo entre los dos extremos se niega a transportar el protocolo que el túnel necesita. Determine dónde se detienen los paquetes antes de tocar cualquiera de las dos configuraciones, porque un protocolo filtrado y una contraseña incorrecta producen el mismo error amable en la mayoría de los clientes. Las pruebas están ordenadas por coste, la más barata primero.

Demuestre dónde se detiene el tráfico

Capture a la vez en la interfaz de salida del cliente y en el servidor. Compare lo que salió con lo que llegó y anote en qué dirección aparece la diferencia.

Nada en el servidor significa que la ruta o el primer NAT descartan el tráfico, mientras que las llegadas sin respuestas apuntan a un cortafuegos en el servidor o a una ruta de retorno que no existe. Un enrutador que termina túneles con frecuencia no guarda ningún registro útil, así que la captura se convierte en el registro. Anote el puerto de destino y el número de protocolo, porque ambos fallos se ven igual en un diálogo del cliente.

PPTP muere sin el protocolo 47

PPTP lleva el control por TCP 1723 y sus datos dentro de GRE, que es el protocolo IP 47 y no un número de puerto. Reenviar solo el 1723 produce el resultado clásico: la conexión se autentica y luego se queda en silencio, porque no existe ninguna regla para el protocolo que transporta la carga útil. El cliente no puede distinguir eso de una contraseña rechazada, por eso la captura debe llegar antes de las modificaciones de configuración.

El paso directo funciona en la dirección opuesta a un reenvío entrante, y el firmware usa con suficiente frecuencia una sola etiqueta para ambos como para confundir a todos. En un cliente Linux el cortafuegos local puede descartar GRE mucho antes de que el enrutador intervenga, así que el protocolo 47 necesita su propia regla y hay que cargar el ayudante conntrack. El ufw de Ubuntu guarda esas reglas en el archivo before, porque las reglas allow normales no pueden expresar un número de protocolo. Después recargue el cortafuegos en lugar de reiniciar la máquina.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP e IPsec detrás de dos NAT

L2TP dentro de IPsec necesita UDP 500 para el intercambio de claves, UDP 4500 cuando se detecta NAT y ESP como protocolo 50. Cada uno se filtra de forma independiente, así que una regla que permite uno no demuestra nada sobre los otros dos. Dos enrutadores en serie traducen cada paquete dos veces y los extremos ya no coinciden en qué se negoció.

Ponga el módem exterior en modo puente o desactive el NAT del enrutador interior, para que la dirección pública llegue al dispositivo que termina el túnel. Donde no sea posible ninguna de las dos, el túnel debe iniciarse desde dentro del límite del doble NAT, no terminarse allí.

Redes de operador y compartición de direcciones

Una dirección WAN dentro de 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 o 100.64.0.0/10 significa que el enrutador no tiene dirección pública y que ningún reenvío entrante desde internet puede alcanzarlo. El NAT de nivel de operador además filtra los protocolos que no espera, y GRE es una víctima frecuente en enlaces móviles. Compare la dirección WAN del propio enrutador, no la que un sitio de consulta indica para un cliente que está detrás.

Ejecutar el mismo enrutador en una línea cableada separa un hallazgo de operador de un error de configuración en una sola prueba. Donde el operador rechaza el protocolo, las opciones que quedan son otro transporte en el 443 o un túnel iniciado desde dentro.

Lea la lista de oyentes antes de cerrar puertos

Un escaneo de puertos alarmante suele ser solo el conjunto de funciones que viene activado. Inventaríe los oyentes, asocie cada socket con una función y luego desactive la función en lugar de bloquear el puerto, para que las dos visiones no se separen.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

Los valores predeterminados de SoftEther son un buen ejemplo: TCP 443, 992 y 5555, con las funciones L2TP/IPsec y de túnel DNS añadiendo sus propios sockets. Desactivar esas funciones elimina los oyentes en lugar de ocultarlos, y la prueba desde un host externo le dice si el operador deja pasar el puerto. Un oyente que responde localmente puede seguir cerrado más arriba, así que compare la dirección WAN del propio enrutador con lo que informa un servicio externo.