Strângerea de mână WireGuard funcționează, serviciul nu

Strângerea de mână se finalizează, clientul arată un contor de transfer recent, iar o cerere către un serviciu de pe același server eșuează în continuare. Această combinație derutează oamenii, pentru că tunelul funcționează în mod demonstrabil. Ce nu a fost dovedit este livrarea locală: pachetul a ajuns la gazdă, iar gazda trebuie încă să îl accepte pe socketul corect și să îl dea unui proces cu permisiunea de a răspunde. Parcurgeți aceste trei puncte de control în ordine.

Opriți-vă la primul care nu se susține și nu adăugați reguli pentru celelalte.

Strângerea de mână dovedește doar tunelul

Strângerea de mână a WireGuard stabilește chei între parteneri și autorizează traficul pentru intervalele pe care fiecare partener le-a listat. Nu spune nimic despre ce procese ascultă pe server și nimic despre dacă firewall-ul gazdei acceptă pachete adresate uneia dintre propriile adrese.

Exact această ultimă distincție este cea mai des ratată: traficul către gazda însăși este intrare locală, în timp ce traficul care trece prin gazdă către altundeva este redirecționare. Sunt gestionate de lanțuri de firewall diferite și de setări diferite. Verificarea lanțului greșit costă o după-amiază și întoarce contoare care par inofensive.

Citiți ascultătorul și ruta

Pe client, confirmați că adresa tunelului serverului este rutată în tunel. Pe server, confirmați că există un socket la adresa folosită de client și că procesul din spate este cel intenționat.

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 ascultător pe 127.0.0.1 nu va răspunde niciodată unei cereri adresate la 10.66.0.1, indiferent ce permite firewall-ul. Un ascultător pe adresa generală va răspunde, dacă o regulă nu îl blochează. Lista socketurilor decide astfel jumătate din cazuri înainte de a examina vreo regulă. Portul și adresa împreună decid dacă o cerere poate ajunge.

Comparați adresa folosită de client cu adresa pe care serverul o are într-adevăr pe interfața tunelului. O configurație învechită pe oricare parte produce o cerere rutată corect către un partener care nu are acea adresă.

Aplicați reguli pentru intrarea locală, nu pentru redirecționare

Dacă pachetul ajunge și socketul există, granița rămasă este politica de intrare. O regulă care permite redirecționarea nu permite livrarea locală, iar o regulă limitată la o interfață poate să nu corespundă numelui interfeței tunelului pe care îl așteptați.

Testați cu un singur port permis către serviciul dorit, în loc să deschideți gazda. Apoi verificați autorizarea aplicației înseși: o listă de permisiuni, o cerință de cont sau o legare la un anumit nume de gazdă pot respinge o cerere pe care rețeaua a livrat-o cu succes.

Păstrați verificările de certificat. O identitate de certificat neașteptată este informație despre ce gazdă a răspuns, nu un obstacol de ocolit. Trecerea prin avertisment ascunde singurul indiciu care identifică serviciul greșit.

Separați eșecurile de nume, dimensiune și identitate

Un serviciu care funcționează după adresă dar eșuează după nume este o problemă DNS, iar corectarea aparține configurației resolverului trimise către client, nu firewall-ului. Un serviciu care răspunde la cereri mici dar se blochează la răspunsuri mai mari indică dimensiunea pachetului și MTU, ceea ce este o investigație complet diferită.

O eroare HTTPS care numește gazda greșită înseamnă de obicei că cererea a ajuns la alt serviciu, adesea pentru că un proxy sau un alt ascultător deține portul respectiv. Citiți subiectul certificatului și comparați-l cu gazda la care voiați să ajungeți. Acea comparație nu costă nimic și deseori încheie investigația.

Notați care punct de control a eșuat: socket, regulă de intrare sau politică a aplicației. Acea singură linie distinge o defecțiune de rețea de o decizie de autorizare. De asemenea, împiedică următoarea persoană să deschidă porturi care nu au fost niciodată problema.