VPN detrás dun NAT que non pode configurar: que segue funcionando

Cada extremo de túnel necesita un enderezo e un porto que o outro lado poida acadar, e un router que vostede non administra é a razón habitual de que ese requisito falle. O interesante non é que existan trucos, senón que cada un dependa dunha propiedade dunha táboa de mapeo que vostede non ve desde o cliente. Dúas desas propiedades deciden case todo: como se crea un mapeo e se acepta paquetes dun enderezo co que o interior nunca contactou. Ordene a contorna por esas propiedades e as solucións deixan de ser folclore.

A táboa de mapeo decídelo todo

A tradución de enderezos de rede mantén unha táboa na que un enderezo e un porto internos quedan rexistrados fronte a un enderezo e un porto públicos. As respostas que coinciden cun rexistro tradúcense de volta, e un paquete que chega de fóra sen un rexistro coincidente non ten destino ningún. Ese único comportamento explica por que un receptor detrás do router é inalcanzable desde internet. Tamén explica por que o primeiro paquete en cada dirección ten que orixinarse dentro.

Mire a táboa desde o lado do router e as solucións vólvense obvias: ou algo crea unha entrada permanente, ou crea unha temporal e manténa fresca, ou o tráfico nunca toma ese camiño. O resto do artigo son eses tres casos por orde. Nada aquí depende dunha función do fabricante máis alá do que rexistra a táboa.

Que pode e que non pode facer o servizo de encontro

O hole punching UDP usa o rexistro saínte como unha apertura temporal en lugar de derrotar o filtro. Ambos pares contactan un servizo de encontro, que aprende cada extremo público e devolve ao outro lado o seu extremo. Logo ambos envían un cara ao outro, e cada paquete saínte crea ou refresca o rexistro que deixa entrar a resposta. A orde é o que o fai funcionar, e a orde é tamén o que o fai fráxil: un par que envía antes de que o outro lado crease o seu rexistro simplemente descártase, mentres que un reintento un momento despois ten éxito. O servizo non transporta tráfico VPN, así que a súa única panca é o tempo que coordina.

O comportamento do mapeo decide o resto, e RFC 4787 nomea as tres formas: independente do extremo, dependente do enderezo e dependente do enderezo e do porto. Coa última, o porto que un par debe atacar cambia con cada destino, así que a predición deixa de ser fiable. Aí a técnica atopa os seus calexóns sen saída, porque o NAT de nivel de operador e un devasado corporativo estrito eliminan ambos a previsibilidade que o esquema necesita, e ningunha cantidade de reintentos a recupera.

Keepalives, reinicios e o extremo que se move

Un camiño perforado é un fluxo e non un receptor, así que o que corra por riba debe sobrevivir ao cambio. Debe manter vivo o mapeo con tráfico periódico, notar cando se move o extremo público e restablecerse tras reiniciarse o router ou reasignarse o enderezo. Os produtos de mesh VPN poñen esa lóxica no seu propio plano de control, mentres que un servidor simple déixalla a vostede. Os keepalives só axudan mentres sobrevive o mesmo mapeo, e custan batería nun cliente móbil, por iso un intervalo agresivo non sae gratis.

Un portátil que dorme unha hora adoita volver nun extremo público distinto. O que restablece o camiño ten que executarse outra vez desde dentro, o que devolve o mesmo requisito ao cliente.

Tres formas de sortear unha redirección ausente

A primeira forma pide ao router que cree el mesmo a entrada, mediante UPnP IGD, NAT-PMP ou PCP, cando a función existe e está activada. A segunda entrega o tráfico a un relé con enderezo público, que sempre funciona e sempre custa ancho de banda máis unha fronteira de confianza distinta. A terceira inverte a dirección: o host interno abre un túnel saínte cara a un servidor público e todo o demais viaxa dentro.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Un extremo de relé fai visible ese intercambio na configuración do cliente, onde o extremo é un relé e non o enderezo propio dun par. O keepalive persistente mantén quente o mapeo, e os prefixos permitidos deciden que pode enviar o cliente a través del. Un túnel inverso desde o host interno é a mesma idea con outro propietario, e non necesita ningún cambio de NAT. Cada unha das tres elimina o requisito de entrada sen derrotar un devasado que bloquea por deseño o tráfico non solicitado, porque o tráfico segue comezando dentro.

Axuste a solución a quen posúe o router

Se administra o router, unha redirección UDP estática é máis doada de auditar que calquera esquema de perforación e falla de formas que vostede ve. Se non, averigüe se o fabricante ofrece un relé ou un plano de control aloxado, e se a política permitiría usalo. Se non hai ningún, as opcións restantes son un túnel inverso ou aceptar que o extremo non é alcanzable desde fóra. Rexistrar cal usou importa máis do que parece, porque as opcións difiren en quen pode observar o tráfico e en que ocorre cando un terceiro cambia algo.

Anote se o camiño co que rematou era directo ou a través dun relé, xa que ese só feito predí tanto a latencia como o comportamento ante fallos. RFC 4787 segue sendo a referencia do comportamento de mapeo que hai debaixo de todo isto, e ler a súa sección de mapeo é máis rápido que probar tres solucións en secuencia. Á táboa non lle importa que opción escolleu; só rexistra que pode facer o seguinte paquete.