O túnel VPN nunca conecta: onde se deteñen realmente os paquetes

O cliente non deixa de reintentar, o rexistro detense antes de completarse o aperto de mans e o servidor non anota absolutamente nada. Ese patrón afasta das credenciais e apunta ao camiño: algo entre os dous extremos négase a transportar o protocolo que o túnel necesita. Determine onde se deteñen os paquetes antes de tocar calquera das dúas configuracións, porque un protocolo filtrado e un contrasinal incorrecto producen o mesmo erro amable na maioría dos clientes. As probas están ordenadas por custo, a máis barata primeiro.

Demostre onde se detén o tráfico

Capture á vez na interface de saída do cliente e no servidor. Compare o que saíu co que chegou e anote en que dirección aparece a diferenza.

Nada no servidor significa que a ruta ou o primeiro NAT descartan o tráfico, mentres que as chegadas sen respostas apuntan a un cortalumes no servidor ou a unha ruta de retorno que non existe. Un encamiñador que remata túneles con frecuencia non garda ningún rexistro útil, así que a captura convértese no rexistro. Anote o porto de destino e o número de protocolo, porque ambos os fallos vense igual nun diálogo do cliente.

PPTP morre sen o protocolo 47

PPTP leva o control por TCP 1723 e os seus datos dentro de GRE, que é o protocolo IP 47 e non un número de porto. Redirixir só o 1723 produce o resultado clásico: a conexión autentícase e logo queda en silencio, porque non existe ningunha regra para o protocolo que transporta a carga útil. O cliente non pode distinguir iso dun contrasinal rexeitado, por iso a captura debe chegar antes das modificacións de configuración.

O paso directo funciona na dirección oposta a un redireccionamento de entrada, e o firmware usa con suficiente frecuencia unha soa etiqueta para ambos como para confundir a todos. Nun cliente Linux o cortalumes local pode descartar GRE moito antes de que o encamiñador interveña, así que o protocolo 47 necesita a súa propia regra e hai que cargar o axudante conntrack. O ufw de Ubuntu garda esas regras no ficheiro before, porque as regras allow normais non poden expresar un número de protocolo. Despois recargue o cortalumes en lugar de reiniciar a 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 dous NAT

L2TP dentro de IPsec necesita UDP 500 para o intercambio de claves, UDP 4500 cando se detecta NAT e ESP como protocolo 50. Cada un fíltrase de forma independente, así que unha regra que permite un non demostra nada sobre os outros dous. Dous encamiñadores en serie traducen cada paquete dúas veces e os extremos xa non coinciden en que se negociou.

Poida o módem exterior ou desactive o NAT no encamiñador interior, para que a dirección pública chegue ao dispositivo que remata o túnel. Onde non sexa posible ningunha das dúas, o túnel debe iniciarse desde dentro do límite do dobre NAT, non rematarse alí.

Redes de operador e compartición de enderezos

Unha dirección WAN dentro de 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ou 100.64.0.0/10 significa que o encamiñador non ten dirección pública e que ningún redireccionamento de entrada desde internet pode alcanzalo. O NAT de nivel de operador ademais filtra os protocolos que non espera, e GRE é unha vítima frecuente nos enlaces móbiles. Compare a dirección WAN do propio encamiñador, non a que un sitio de consulta indica para un cliente que está detrás.

Executar o mesmo encamiñador nunha liña por cable separa un achado de operador dun erro de configuración nunha soa proba. Onde o operador rexeita o protocolo, as opcións que quedan son outro transporte no 443 ou un túnel iniciado desde dentro.

Lea a lista de oíntes antes de pechar portos

Unha exploración de portos alarmante adoita ser só o conxunto de funcións que vén activado. Inventaríe os oíntes, asocie cada socket cunha función e despois desactive a función en lugar de bloquear o porto, para que as dúas visións non 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

Os valores predeterminados de SoftEther son un bo exemplo: TCP 443, 992 e 5555, coas funcións L2TP/IPsec e de túnel DNS engadindo os seus propios sockets. Desactivar esas funcións elimina os oíntes en lugar de ocultalos, e a proba desde un host externo dille se o operador deixa pasar o porto. Un oínte que responde localmente pode seguir pechado máis arriba, así que compare a dirección WAN do propio encamiñador co que informa un servizo externo.