Cum construiești un test WireGuard cu doi peeri care dovedește o singură cale

Un test WireGuard care transportă o rută implicită, un prefix LAN, DNS și o excepție de firewall nu poate spune care dintre ele s-a stricat. Reduce-l la doi peeri, o pereche de adrese și un singur serviciu permis, iar defecțiunea nu are unde să se ascundă. Baza plictisitoare este diagnosticul. Construiește-o prima; durează cincisprezece minute și economisește după-amiaza pe care altfel ai petrece-o ghicind.

Ce dovedește baza este mai îngust decât se așteaptă majoritatea. Dovedește că două identități sunt de acord, că UDP ajunge la portul de ascultare și că o singură destinație permisă transportă o cerere. Forwarding, NAT, rute LAN și DNS sunt funcții separate adăugate după aceea, una câte una.

Chei, adrese și singurul endpoint

Generează o pereche de chei pe fiecare sistem și mută între ele doar jumătățile publice. wg genkey | tee privatekey | wg pubkey > publickey este comanda documentată pe o singură linie, și lasă cheia privată într-un fișier pe care apoi îl poți proteja. Alege adrese de tunel dintr-un interval care nu apare în nicio altă configurație a ta, cum ar fi 10.99.0.1/24 și 10.99.0.2/24. Notează care adresă aparține cărei mașini, pentru că fiecare verificare ulterioară depinde de această corespondență.

Cheile private nu călătoresc niciodată. Dacă un test are nevoie de una copiată pe cealaltă parte, testul a luat-o deja greșit. Când cele două sisteme stau în spatele unui NAT, cel puțin unul are nevoie de un port UDP accesibil, în timp ce celălalt poartă un Endpoint care arată spre el, iar adresa și portul publice aparțin notițelor tale, nu presupunerilor tale despre 51820.

Redirecționarea unui port care mapează alt port extern funcționează bine atâta timp cât Endpoint-ul corespunde. Neconcordanțele de aici produc tăcere în loc de erori, de aceea merită verificate pe hârtie înainte de a depana pe cablu.

Câmpurile care aparțin de wg și cele care nu

Setul de câmpuri de bază este mic: PrivateKey și ListenPort sub Interface, PublicKey, AllowedIPs și Endpoint sub Peer. Address și DNS aparțin de wg-quick, nu de wg însuși, iar distincția mușcă în momentul în care aceeași configurație se mută într-un alt instrument.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs îndeplinește două sarcini deodată. Selectează ce destinații intră în tunel, și autorizează peerul să folosească acele adrese sursă la sosire. De aceea intrarea oglindă de pe cealaltă parte trebuie să numească exact adresa tunelului tău; un /32 pentru peerul greșit se citește ca o problemă de rutare și se comportă ca una de autorizare. Pornire rapidă WireGuard arată aceeași formă cu doi peeri, cu formularea canonică, dacă vrei să compari numele câmpurilor.

Citirea handshake-ului în locul pictogramei

Ridică interfața prin ceea ce o deține, apoi citește starea în loc de un bec de status. wg show tipărește ultimul handshake per peer împreună cu contoarele de octeți, iar un handshake în ultimele minute înseamnă că cheile, endpoint-ul și calea UDP funcționează toate. Un contor care crește doar într-o direcție este propriul său răspuns și nu este aceeași defecțiune ca un handshake care nu are loc niciodată.

Cele două defecțiuni implică investigații diferite. Absența completă a handshake-ului indică o nepotrivire de chei, un Endpoint greșit, UDP blocat sau un firewall care aruncă handshake-ul însuși. Un handshake care reușește în timp ce datele nu ajung nicăieri indică AllowedIPs, un serviciu care nu ascultă pe adresa tunelului sau un firewall de gazdă care acceptă portul pentru LAN, dar nu pentru interfața tunelului. Sunt jumătăți diferite ale sistemului, iar baza le separă înainte să începi să schimbi reguli.

A dovedi un serviciu permis, apoi inversul

Trimite o cerere către adresa tunelului celuilalt peer pe un serviciu care ar trebui să răspundă și alege ceva mai bun decât ping. Un răspuns ICMP lipsă poate fi filtrare a gazdei, nu o defecțiune a tunelului, așa că un ping mut nu dovedește nicio direcție. O conexiune TCP către un port despre care știi că este deschis, sau o cerere care returnează date, îți dă un răspuns pe care îl poți interpreta.

Rulează direcția inversă ca test separat, cu propriul rezultat, pentru că cele două direcții au intrări separate de firewall și AllowedIPs și pot eșua independent. Dacă handshake-ul funcționează și cererea nu, problema este pe calea datelor, nu în tunel: AllowedIPs, serviciul care ascultă sau un firewall de gazdă. Repară asta înainte de a adăuga forwarding, NAT sau DNS, altfel vei petrece după-amiaza depanând o funcție care nu a fost niciodată vinovată.

Păstrarea bazei ca referință

Salvează topologia funcțională și sursa profilului într-un loc din care poți restaura și ține-le în afara oricărui director care se sincronizează cu un serviciu public. Apoi adaugă o funcție pe rând, repetând cererea inițială după fiecare: forwarding, NAT, o rută LAN și abia apoi DNS. Fiecare adăugare care strică testul este acum identificabilă, pentru că nimic altceva nu s-a mișcat.

O bază care doar face un simbol verde nu ți-a spus nimic despre ce adăugare a cauzat următoarea defecțiune. Ține singura cale permisă în funcțiune ca referință, iar fiecare schimbare ulterioară este măsurată față de ea.