NAT simétrico e VPN: mida a asignación, non a etiqueta
A asignación dependente do extremo afecta o descubrimento entre pares, non un túnel normal de cliente a servidor. Mida o porto e, se a ruta directa falla, use un relé.
Un fío de soporte remata co veredicto «NAT simétrico, a VPN non vai funcionar aquí», e despois o cliente reinstálase tres veces sen motivo. A etiqueta fai dano porque responde a unha pregunta que ninguén fixo. Un cliente que se conecta cara a fóra a un servidor fixo crea unha asignación no momento en que envía o primeiro paquete, e a resposta déixase volver segundo regras que case todas as redes implementan. O que a asignación dependente do extremo complica de verdade é que dous pares intenten alcanzarse á vez, e iso é outra proba.
Dúas preguntas escóndense tras unha etiqueta
A primeira pregunta é se un host detrás desta rede pode abrir unha sesión cara a un enderezo público e un porto coñecidos. Para un cliente de túnel ese é o caso normal, e a resposta é case sempre si. O router rexistra a orixe interna, asigna un porto externo e deixa pasar a resposta porque pertence a unha sesión que comezou desde dentro.
A segunda pregunta é se dous hosts detrás de redes distintas poden descubrir un camiño compartido e enviarse sen un servidor no medio. Iso depende de como asigna cada rede eses portos externos, e é o único lugar onde o comportamento da asignación importa.
Confundir as dúas produce o diagnóstico erróneo clásico: falla unha función entre pares, alguén executa unha proba de tipo de NAT, ve a peor categoría e conclúe que o túnel corrente tampouco pode funcionar. O túnel nunca foi o que fallou.
A asignación e a filtraxe son propiedades separadas
A terminoloxía do RFC é máis precisa que os nomes que usan os fabricantes, e paga a pena levala ao tícket porque resolve discusións. A asignación é como se asigna o porto externo. A filtraxe é que paquetes entrantes se deixan pasar. Unha rede pode ser estrita nunha e liberal na outra, e esa combinación é o que un protocolo entre pares ten que sobrevivir.
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
A terceira fila é o que a maioría dos routers domésticos e operadores móbiles entenden por simétrico. Teña en conta que a etiqueta só describe a asignación. Unha rede con esa asignación e filtraxe liberal aínda pode aceptar paquetes entrantes no porto que acaba de asignar, e por iso o perforado de buratos funciona nalgunhas e falla noutras.
A filtraxe ten os seus tres casos e o seu nome para cada un. Escribir «NAT simétrico» nun tícket cando quere dicir «filtraxe dependente de enderezo e porto» envía a seguinte persoa ao capítulo equivocado do manual. Os dous compórtanse distinto na proba, así que o erro non é académico.
Mida a asignación en lugar de nomeala
Pode observar o porto asignado directamente desde o lado servidor de calquera servizo UDP que controle. Inicie unha captura no host público, envíe desde o cliente e lea o porto de orixe co que chegou o paquete:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820A liña do extremo é a máis útil das tres, porque WireGuard rexistra o último enderezo e o último porto que recibiu de cada par. Compare ese porto co que o cliente cre que usa. Diferirán sempre que ocorra calquera tradución, e a pregunta importante é se o valor se mantén estable.
Repita a observación contra un segundo porto de destino ou un segundo servidor e compare outra vez. Se o porto externo cambia por destino, a asignación depende do enderezo e do porto. Se se mantén igual, a rede dálle unha soa asignación e o descubrimento ten unha oportunidade.
As ferramentas baseadas en STUN informan da mesma clasificación nun só paso, e pódense usar cando a rede permite UDP de saída cara a un servidor STUN público. Cando non o permite, o método de captura anterior segue funcionando e non require nada máis que un host que xa controla.
Escolla unha solución que encaixe co fallo
Se a función que falla é entre pares, as respostas admitidas son un relé, un servizo de encontro ao que poidan chegar os dous pares, ou unha topoloxía distinta. TURN existe exactamente para isto, e un produto que inclúe o seu propio relé está a dicirlle que espera que algunhas redes sexan hostís.
Se a función que falla é un túnel corrente, o comportamento da asignación non é o seu problema e nada do anterior se aplica. Comprobe que o cliente envía de verdade, que o servidor ve o paquete e que a resposta volve. Esa secuencia son tres observacións e non esixe saber nada sobre a categoría NAT do router.
O que non funciona é repartir cambios de porto local ata que algo se conecte. Cambiar o porto de orixe do cliente non cambia como asigna a rede as asignacións. Un éxito casual ao quinto intento é un falso positivo, e citarase como solución durante meses.
Rexistre a arquitectura, non o veredicto
Unha nota útil di que protocolo, en que dirección comeza a sesión, se hai un relé no camiño e que se observou no cable. «NAT simétrico, non funciona» é inutilizable, porque á vez é erróneo sobre o túnel e non informa sobre o camiño entre pares.
Inclúa a estabilidade do porto medida e o comportamento da filtraxe se os probou. Esos dous feitos permiten a outra persoa prever se unha función nova funcionará nesa rede sen repetir toda a investigación. Tamén envellecen mellor ca unha categoría de fabricante que significa algo lixeiramente distinto en cada páxina de axuda.
Por último, teña á man a terminoloxía do RFC 4787 cando o escriba. Usar os termos precisos custa unha frase e evita que o seguinte lector repita o mesmo diagnóstico erróneo, que é todo o sentido de escribir a nota.