WireGuard funciona cos datos móbiles pero non na mesma wifi
Unha solicitude desde dentro da LAN ao enderezo público do router toma un camiño distinto que unha desde datos móbiles. Probe fóra e escolla despois un camiño local.
O túnel levanta cos datos móbiles e despois queda en conectando na casa, co mesmo perfil, a mesma chave de par e ningún cambio de configuración polo medio. A diferenza está na viaxe: unha solicitude desde dentro da LAN cara ao enderezo público do router non é a mesma viaxe que unha solicitude que chega desde internet. A maioría das pasarelas domésticas ou non implementan o camiño de volta ou só o fan para certos protocolos. Iso fai que o síntoma pareza unha chave rota cando nada da chave se moveu. Determine que camiño fallou antes de tocar unha chave, unha redirección de porto ou un perfil de cliente.
Un enderezo, dous camiños distintos
Desde fóra, un paquete chega ao enderezo público do router e unha regra de redirección de porto entrégallo ao receptor de WireGuard no host interno. Desde dentro, o cliente marca o mesmo enderezo público, así que o paquete sae do cliente, chega ao router e ten que xirarse de volta cara á LAN. É nese xiro onde os dous camiños se separan, porque o router debe traducir un fluxo que á vez sae e volve entrar pola mesma interface. Moitas implementacións descártano en vez de traducilo, e o cliente espera entón un saúdo que nunca se enviou.
O comportamento adoita chamarse NAT loopback ou hairpinning, e pertence ao router e non a WireGuard; RFC 4787 expón os casos de tradución nos que unha pasarela pode ou non admitilo. WireGuard en si non opina sobre o camiño, porque só ve paquetes que alcanzan a súa interface. Cando o router descarta o fluxo, o daemon nunca recibe nada, o cliente informa dun tempo de espera de saúdo e o rexistro do servidor queda baleiro. Un rexistro baleiro é, polo tanto, unha pista de onde se detivo o paquete, non unha proba de que o servidor estea caído. É tamén a razón pola que reinstalar non cambia nada.
O contrario tamén conta: un rexistro do servidor que mostra un intento de saúdo desde o enderezo da LAN demostra que o paquete chegou e que o camiño está ben, o que traslada a investigación ás chaves e aos enderezos permitidos. Lea o rexistro polo que demostra e non polo que esperaba ver.
Reprodúzao antes de cambiar nada
Probe desde unha rede externa autorizada co mesmo dispositivo e o mesmo perfil, e repita despois a proba dentro da LAN sen editar nada. Un saúdo completado fóra e un cliente que dentro nunca sae do dispositivo reproducen a condición en lugar de adiviñala. Ambos os intentos teñen que usar o mesmo perfil, ou a comparación non demostra nada.
Despois mire a que resolve o nome do punto final para este dispositivo. Os tres comandos seguintes tamén mostran a que enderezo marcou realmente o cliente:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netO primeiro comando informa do punto final que a interface está a usar agora, e os outros dous mostran a que resolve o nome nesta máquina. Un cliente que marca un enderezo público mentres está na mesma rede que o servidor está a exercer o camiño de hairpin. Un cliente que marca o enderezo da LAN non o fai, e un fallo aí pertence a outra investigación. Esa distinción decide se a sección seguinte se aplica sequera.
Formas admitidas de chegar a un servidor próximo
A disposición máis limpa é unha resposta de horizonte dividido: o nome público resolve ao enderezo público para internet e ao enderezo de LAN do servidor para os clientes de dentro. O perfil conserva un único nome de punto final e o resolutor escolle o camiño. Iso esixe control da resposta DNS interna, que un router doméstico adoita ofrecer e unha organización pode organizar a propósito. Sen ese control, as opcións que quedan son unha función do router ou un segundo perfil.
A función do router é a reflexión: a pasarela traduce o fluxo de dentro a fóra e devólveo cara a dentro. Onde funciona non precisa ningún cambio no cliente, e onde non funciona ningunha configuración do cliente o salvará. Probea observando o rexistro do servidor durante un intento interno en vez de ler a lista de funcións do router.
Editar o perfil a un enderezo privado é un diagnóstico, non un deseño. Demostra que o servidor responde na LAN, e rompe o mesmo perfil no momento en que o portátil sae da casa.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Manteña o perfil utilizábel fóra da casa
Escolla o camiño que escolla, deixe en paz a comprobación de identidade. O enderezo do punto final non é a identidade do par, e un cambio de enderezo nunca xustifica aceptar unha chave pública allea que por casualidade responda. WireGuard autentica por chave, así que un host errado falla o saúdo en lugar de conceder acceso a algo inesperado.
Se o enderezo público se move, o DNS dinámico é o que mantén útil o nome, e o comportamento de actualización do cliente decide con que rapidez chega o cambio. Probeo desde fóra tras un cambio de enderezo, porque o caso da LAN non o pode validar. Estea atento a un resolutor que cachea a resposta antiga máis alá da vida do rexistro. Un nome que aínda apunta ao enderezo anterior parece exactamente un servidor que caeu.
Anote que nome usa o perfil e a que resolve en cada lado da fronteira. Un perfil que depende dunha función do router que ninguén rexistrou é unha chamada de soporte agardando a próxima actualización de firmware. A nota é tamén o que lle di á persoa seguinte se un fallo interno é o caso coñecido de hairpin ou algo novo.