WireGuard funciona amb dades mòbils però no a la mateixa wifi
Una sol·licitud des de dins de la LAN a l’adreça pública del router pren un camí diferent que una des de dades mòbils. Proveu fora i trieu després un camí local.
El túnel s’aixeca amb dades mòbils i després es queda a connectant a casa, amb el mateix perfil, la mateixa clau de parell i cap canvi de configuració pel mig. La diferència és al trajecte: una sol·licitud des de dins de la LAN cap a l’adreça pública del router no és el mateix viatge que una sol·licitud que arriba d’internet. La majoria de passarel·les domèstiques o no implementen el camí de tornada o només ho fan per a certs protocols. Això fa que el símptoma sembli una clau espatllada quan res de la clau s’ha mogut. Determineu quin camí ha fallat abans de tocar una clau, una redirecció de port o un perfil de client.
Una adreça, dos camins diferents
Des de fora, un paquet arriba a l’adreça pública del router i una regla de redirecció de port l’entrega a l’oient de WireGuard a l’amfitrió intern. Des de dins, el client marca la mateixa adreça pública, així que el paquet surt del client, arriba al router i s’ha de girar de tornada cap a la LAN. És en aquest gir on els dos camins se separen, perquè el router ha de traduir un flux que alhora surt i torna a entrar per la mateixa interfície. Moltes implementacions el descarten en lloc de traduir-lo, i el client espera llavors una salutació que mai no es va enviar.
El comportament se sol anomenar NAT loopback o hairpinning, i pertany al router i no a WireGuard; RFC 4787 exposa els casos de traducció en què una passarel·la pot o no admetre’l. WireGuard en si no té opinió sobre el camí, perquè només veu paquets que arriben a la seva interfície. Quan el router descarta el flux, el dimoni no rep mai res, el client informa d’un temps d’espera de salutació i el registre del servidor queda buit. Un registre buit és, per tant, una pista d’on es va aturar el paquet, no una prova que el servidor estigui caigut. També és la raó per la qual reinstal·lar no canvia res.
El contrari també compta: un registre del servidor que mostra un intent de salutació des de l’adreça de la LAN demostra que el paquet va arribar i que el camí està bé, cosa que trasllada la investigació a les claus i les adreces permeses. Llegiu el registre pel que demostra i no pel que esperàveu veure.
Reproduïu-ho abans de canviar res
Proveu des d’una xarxa externa autoritzada amb el mateix dispositiu i el mateix perfil, i repetiu després la prova dins de la LAN sense editar res. Una salutació completada fora i un client que a dins mai no surt del dispositiu reprodueixen la condició en lloc d’endevinar-la. Tots dos intents han d’usar el mateix perfil, o la comparació no demostra res.
Després mireu a què resol el nom del punt final per a aquest dispositiu. Les tres ordres següents també mostren a quina adreça va marcar realment el client:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netLa primera ordre informa del punt final que la interfície està fent servir ara, i les altres dues mostren a què resol el nom en aquesta màquina. Un client que marca una adreça pública mentre és a la mateixa xarxa que el servidor està exercint el camí de hairpin. Un client que marca l’adreça de la LAN no ho fa, i una fallada allà pertany a una altra investigació. Aquesta distinció decideix si la secció següent s’aplica tan sols.
Maneres admeses d’arribar a un servidor proper
La disposició més neta és una resposta d’horitzó dividit: el nom públic resol a l’adreça pública per a internet i a l’adreça de LAN del servidor per als clients de dins. El perfil conserva un sol nom de punt final i el resolutor tria el camí. Això exigeix control de la resposta DNS interna, que un router domèstic sol oferir i una organització pot organitzar a propòsit. Sense aquest control, les opcions que queden són una funció del router o un segon perfil.
La funció del router és la reflexió: la passarel·la tradueix el flux de dins a fora i el torna cap a dins. On funciona no necessita cap canvi al client, i on no funciona cap configuració del client el salvarà. Proveu-la observant el registre del servidor durant un intent intern en lloc de llegir la llista de funcions del router.
Editar el perfil a una adreça privada és un diagnòstic, no un disseny. Demostra que el servidor respon a la LAN, i trenca el mateix perfil en el moment que el portàtil surt de 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 |
Manteniu el perfil utilitzable fora de casa
Trieu el camí que trieu, deixeu en pau la comprovació d’identitat. L’adreça del punt final no és la identitat del parell, i un canvi d’adreça mai no justifica acceptar una clau pública aliena que per casualitat respongui. WireGuard autentica per clau, així que un amfitrió equivocat falla la salutació en lloc de concedir accés a una cosa inesperada.
Si l’adreça pública es mou, el DNS dinàmic és el que manté útil el nom, i el comportament d’actualització del client decideix amb quina rapidesa arriba el canvi. Proveu-ho des de fora després d’un canvi d’adreça, perquè el cas de la LAN no ho pot validar. Pareu atenció a un resolutor que fa memòria cau de la resposta antiga més enllà de la vida del registre. Un nom que encara apunta a l’adreça anterior sembla exactament un servidor que va caure.
Anoteu quin nom fa servir el perfil i a què resol a cada costat de la frontera. Un perfil que depèn d’una funció del router que ningú no va registrar és una trucada de suport esperant la propera actualització de firmware. La nota també és el que diu a la persona següent si una fallada interna és el cas conegut de hairpin o una cosa nova.