El handshake de WireGuard funciona, el servei no

El handshake es completa, el client mostra un comptador de transferència recent i, tot i així, una petició a un servei del mateix servidor falla. Aquesta combinació confon la gent perquè el túnel funciona demostrablement. El que no s'ha demostrat és el lliurament local: el paquet ha arribat a l'amfitrió, i l'amfitrió encara l'ha d'acceptar al sòcol correcte i passar-lo a un procés amb permís per respondre. Recorreu aquests tres punts de control per ordre.

Atureu-vos al primer que no es compleixi i no afegiu regles per als altres.

El handshake només demostra el túnel

El handshake de WireGuard estableix claus entre iguals i autoritza el trànsit per als rangs que cada igual ha llistat. No diu res sobre quins processos escolten al servidor ni sobre si el tallafoc de l'amfitrió accepta paquets adreçats a una de les seves pròpies adreces.

Aquesta darrera distinció és la que més sovint es passa per alt: el trànsit cap a l'amfitrió mateix és entrada local, mentre que el trànsit que passa per l'amfitrió cap a un altre lloc és reenviament. Els gestionen cadenes de tallafoc diferents i paràmetres diferents. Comprovar la cadena equivocada fa perdre una tarda i retorna comptadors que semblen innocus.

Llegiu l'oient i la ruta

Al client, confirmeu que l'adreça del túnel del servidor s'encamina cap al túnel. Al servidor, confirmeu que existeix un sòcol a l'adreça que utilitza el client i que el procés que hi ha darrere és el que preteníeu.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Un oient a 127.0.0.1 no respondrà mai una petició adreçada a 10.66.0.1, faci el que faci el tallafoc. Un oient a l'adreça comodí sí que ho farà, tret que una regla el bloquegi. La llista de sòcols, doncs, resol la meitat dels casos abans que s'examini cap regla. El port i l'adreça junts decideixen si una petició pot arribar.

Compareu l'adreça que utilitza el client amb l'adreça que el servidor posseeix realment a la interfície del túnel. Una configuració antiga a qualsevol dels dos costats produeix una petició encaminada correctament a un igual que no té aquesta adreça.

Apliqueu regles per a l'entrada local, no per al reenviament

Si el paquet arriba i el sòcol existeix, la frontera restant és la política d'entrada. Una regla que permet el reenviament no permet el lliurament local, i una regla limitada a una interfície pot no coincidir amb el nom de la interfície del túnel que espereu.

Proveu amb un sol port permès cap al servei previst en lloc d'obrir l'amfitrió. Després comproveu l'autorització pròpia de l'aplicació: una llista d'autoritzats, un requisit de compte o una vinculació a un nom d'amfitrió concret poden rebutjar una petició que la xarxa ha lliurat correctament.

Mantingueu les comprovacions de certificat. Una identitat de certificat inesperada és informació sobre quin amfitrió ha respost, no un obstacle a saltar-se. Fer-hi clic a sobre amaga l'únic indici que identifica el servei equivocat.

Separeu les fallades de nom, mida i identitat

Un servei que funciona per adreça però falla per nom és un problema de DNS, i la solució pertany a la configuració del resolutor que s'envia al client, no al tallafoc. Un servei que respon peticions petites però s'encalla en respostes més grans apunta a la mida del paquet i a l'MTU, que és una investigació completament diferent.

Un error HTTPS que anomena un amfitrió equivocat normalment significa que la petició ha arribat a un altre servei, sovint perquè un intermediari o un altre oient posseeix aquell port. Llegiu el subjecte del certificat i compareu-lo amb l'amfitrió que volíeu assolir. Aquesta comparació no costa res i sovint acaba la investigació.

Anoteu quin punt de control ha fallat: sòcol, regla d'entrada o política de l'aplicació. Aquesta sola línia distingeix una fallada de xarxa d'una decisió d'autorització. També evita que la següent persona obri ports que mai no eren el problema.