Por que un servidor VPN detrás de CGNAT nunca acepta conexións
Un enderezo 100.64, un nome DNS dinámico que resolve noutro sitio e ningún saúdo entrante son un só problema: NAT do operador. Confírmao e despois retransmite a saída.
O router informa dun enderezo WAN que comeza por 100.72, o nome DNS dinámico resolve a outro enderezo público e o servidor VPN dese router nunca completa un saúdo desde fóra. O reenvío de portos está configurado, o servizo execútase e unha proba desde a LAN segue funcionando. Nada no rexistro do router parece un erro. Esa combinación é NAT de grao operador, e ningunha regra de devasado pode abrir un porto nun enderezo que o ISP posúe.
Confirmar o enderezo compartido leva dous minutos e evita unha semana de cambios de configuración.
Os sinais que apuntan ao NAT do operador
Compare o enderezo WAN da páxina de estado do router co enderezo que informa unha consulta externa. Un enderezo WAN dentro de 100.64.0.0/10 é o sinal habitual, e os rangos privados 10/8, 172.16/12 e 192.168/16 significan o mesmo. Se traceroute mostra o mesmo salto público repetido, ou un salto temperán responde cun enderezo privado, hai outro tradutor entre o router e internet. Algúns ISP só listan o enderezo asignado no portal de clientes, así que exporte ese valor xunto co traceroute.
Cambiar de protocolo ou de porto non axuda, porque o problema é a accesibilidade entrante e non un porto pechado.
Por que o reenvío e o DNS dinámico non poden arranxalo
Unha regra de reenvío de portos asigna un porto na interface WAN do router, pero o tráfico entrante nunca chega a esa interface: o ISP tradúceo primeiro e só reenvía o que permite a súa propia táboa. Publicar o enderezo compartido no DNS dinámico dirixe os clientes a unha pasarela do ISP usada por moitos subscritores, por iso o nome resolve e o saúdo segue fallando. As probas de hairpin funcionan porque o router responde á súa propia regra desde dentro, e UPnP ten exactamente o mesmo punto cego.
Reconfigurar o cliente tampouco axudará, xa que o fallo ocorre antes de que se lea calquera axuste do cliente.
Retransmitir a través dun VPS con rutas explícitas
Pon un enderezo público diante alugando o VPS máis pequeno capaz de levar o tráfico, e logo fai que o router da casa marque cara a el. O UDP saínte desde a rede doméstica atravesa o NAT do operador, así que o túnel establécese desde dentro e o VPS convértese no extremo accesible. O lado doméstico pasa a ser un cliente cun enderezo de túnel fixo, non un servidor.
No VPS, engade unha entrada de directorio específica do cliente para que o servidor saiba que par posúe a subrede doméstica, e engade unha ruta de núcleo correspondente.
# /etc/openvpn/server/ccd/home-site.conf ifconfig-push 10.8.0.10 255.255.255.0 iroute 192.168.50.0 255.255.255.0 # server.conf client-config-dir /etc/openvpn/server/ccd route 192.168.50.0 255.255.255.0 push "route 10.8.0.0 255.255.255.0"
A liña iroute indica a OpenVPN que cliente recibe o tráfico da subrede doméstica; a liña route pon esa subrede na táboa do núcleo do VPS para que os paquetes entren no túnel. Para un servizo publicado, engade unha regra de NAT de destino que reenvíe o porto público a 10.8.0.10 e activa net.ipv4.ip_forward.
Proba a ruta desde fóra
Verifica cada salto no lado público, porque un túnel correcto non demostra que o servizo sexa accesible. O estado de escoita e a captura de paquetes no VPS separan «non chegou nada» de «chegou e descartouse».
ss -lunp | grep 1194 tcpdump -ni any udp port 1194 nft list ruleset | grep -A4 dnat # from a phone on mobile data, not the home Wi-Fi nc -vz -u 203.0.113.10 1194
Se a captura mostra paquetes do teléfono pero ningunha resposta, a configuración do servidor ou o devasado son a seguinte parada. Se a captura non mostra nada, o cliente aínda resolve ou envía ao enderezo equivocado.
Alternativas que paga a pena valorar primeiro
Un enderezo IPv4 dedicado do ISP é a solución máis curta e adoita ser unha pequena cota mensual. O IPv6 nativo elimina a tradución nos dous extremos cando a VPN, a rede do cliente e os rexistros DNS o levan todos. Unha superposición de malla cun encamiñador de subrede dentro da rede doméstica acada a mesma retransmisión sen VPS, a cambio de depender dun servizo de coordinación.
Escolle a retransmisión cando o requisito sexa acceso entrante estable e cada regra deba quedar baixo o teu control. Escolle o enderezo do ISP cando o orzamento o permita e o obxectivo sexa simplemente deixar de pensar niso.