Os portos UDP fixos poden aforrar o reenvío de portos, pero non todos os NAT

Dous routers domésticos, ningún porto reenviado e unha VPN que ás veces se conecta de todos os xeitos. UDP permíteo, porque un cortafogos admitirá un paquete que poida emparellar cun fluxo que a máquina xa iniciou. É un truco condicional, non unha función, e as condicións son doadas de enunciar cando sabes que compara o cortafogos. Tamén son a razón pola que perfís idénticos se comportan distinto en redes distintas.

A comparación que fai un cortafogos

Cada datagrama saínte crea unha entrada efémera: enderezo de orixe, porto de orixe, enderezo de destino, porto de destino. Todo o que chega e coincide coa entrada trátase como resposta e déixase pasar. As regras de entrada non interveñen.

Así que a pregunta non é se o cortafogos deixa entrar o par. É se o paquete do par parece a resposta que a entrada agarda. Cambia un campo desa tupla de catro partes e o paquete vólvese un estraño. Por iso unha configuración que funciona pode romper cando só cambia o número de porto, e por iso o mesmo porto pode funcionar nun router e fallar no seguinte.

Fixa o porto de orixe local e o mesmo número aparece a ambos lados do intercambio. Ese é todo o mecanismo, e explica por que o truco é fráxil e non misterioso.

Fixar un porto en cada extremo

O porto UDP predeterminado de OpenVPN é o 1194, e lport fixa o porto de orixe desde o que envía. Fixa ambos os pares e a tupla saínte de cada un apuntará a un porto no que o outro escoita:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

Iso só funciona mentres ningún router entre eles reescriba o porto de orixe. Cando os paquetes aparecen nunha captura pero non levanta ningún túnel, a reescritura é o primeiro sospeitoso.

Onde deixa de coincidir a tupla

Un NAT que mapea por destino dá a cada par un porto externo distinto. O enderezo que lle dixeron ao teu par que usase non é o enderezo que lle chega, así que o paquete entrante non coincide con nada e descártase en silencio.

A tradución de operador, o NAT apilado e a aleatorización de portos acaban igual. Tamén calquera dispositivo intermedio que reescriba portos e deixe os enderezos tranquilos.

Os transportes de fluxo están peor. Un handshake TCP séguese paso a paso, así que unha VPN baseada en TCP non se pode perforar así en absoluto e necesita un oínte nalgún punto do camiño.

Normalmente un lado falla primeiro

Na práctica as dúas redes raramente se comportan igual. Un router pode repartir un mapeo previsible mentres o outro reparte portos por destino, e o resultado é unha configuración que funciona entre dúas casas e falla desde unha rede móbil. Os informes que se contradín adoitan describir dúas parellas de routers distintas. Ningún dos dous autores se equivoca, e ningún dos dous resultados se xeneraliza.

Averigua que lado descartou o paquete antes de tocar os perfís. As capturas en ambos extremos resólveno nun só intento: os datagramas que saen de A e nunca chegan a B significan que o fluxo se reescribiu en tránsito, mentres que os que chegan a B sen que volva ningunha resposta significan que o cortafogos non os aceptou como relacionados.

Dous pares con enderezos IPv6 públicos esquivan todo o problema. Sen tradución non hai nada que emparellar, así que abonda unha regra de cortafogos que nomee os pares e o deseño deixa de depender do comportamento do router.

Cando deixar de tentalo

Un host con enderezo público é a resposta fiable. Pode terminar o túnel para ambos os pares, ou simplemente axudarlles a descubrir o enderezo externo actual do outro, e ambos os arranxos funcionan faga o que faga o NAT. Unha capa superposta xestionada ofrece a mesma coordinación se a política o permite.

Ningún destes necesita un cortafogos desactivado. Apagar a protección para gañar a conexión directa descarta a razón pola que o intento directo era atractivo, e deixa a máquina aberta durante toda a proba.

Proba primeiro o arranxo directo e logo anota o que viches. O comportamento do NAT e a captura que o mostrou valen máis que a parella de portos que acabas usando, porque a próxima rede será distinta. O manual de OpenVPN 2.6 documenta lport e as opcións remote das que depende isto.