WireGuard funcționează abia după ce serverul trimite: cunoașterea punctului final

Tunelul pare să funcționeze abia după ce serverul trimite ceva mai întâi. Porniți din client și nu se întâmplă nimic, așteptați câteva secunde, încercați din nou și reușește. Diagnosticul obișnuit este un NAT stricat, iar diagnosticul obișnuit este greșit. Ce s-a schimbat este că o parte a învățat unde locuiește cealaltă.

Cunoașterea punctului final, nu accesibilitatea

O parte WireGuard nu va începe un handshake până nu știe unde să-l trimită. Configurația furnizează asta ca punct final de adresă și port, iar starea de execuție urmărește punctul final în care crede acum.

wg show tipărește ambele laturi ale acelei imagini, iar o parte fără punct final în ieșire nu poate începe nimic, oricât de corecte ar fi cheia sa publică și prefixele permise. Comparați viziunea clientului cu cea a serverului înainte de a schimba orice regulă, pentru că cele două nu sunt adesea de acord cu privire la cine știe ce.

Cum învață o parte un punct final

WireGuard este în mod deliberat tăcut. Când un pachet autentificat corect sosește de la o adresă pe care partea nu o aștepta, implementarea actualizează punctul final al acelei părți la noua sursă, și exact așa funcționează roamingul pe un laptop care schimbă rețelele. Acel comportament explică dependența de direcție: dacă serverul trimite primul și pachetul lui ajunge la client, clientul învață adresa actuală a serverului și poate răspunde. Până atunci nu are unde să trimită. Mecanismul este roaming autentificat și nu o scurtătură de încredere la prima utilizare, pentru că pachetul trebuia să fie valid înainte ca punctul final să se miște.

Documentația instrumentelor pentru wg descrie acea actualizare, și merită citită o dată dacă intenționați să proiectați în jurul ei.

Traducerea cu stare adaugă propria direcție

Acolo unde UDP trece printr-o poartă care traduce, poarta creează stare pentru primul pachet pe care îl vede. RFC 4787 descrie acel comportament și expirările care în cele din urmă elimină maparea. O mapare inactivă expiră, iar un pachet de intrare din partea îndepărtată este apoi eliminat de poartă înainte de a ajunge la gazdă. Un tunel care a funcționat toată dimineața încetează să răspundă după-amiaza exact din acest motiv.

Acesta este un al doilea mecanism independent care produce același simptom direcțional. Atât cunoașterea punctului final, cât și starea traducerii trebuie să fie corecte, iar repararea unuia nu îl repară pe celălalt.

Configurați direcția pe care o doriți cu adevărat

Pentru un client care trebuie să înceapă conexiunea, puneți punctul final al serverului în secțiunea de părți a clientului și lăsați-l acolo. A te baza pe faptul că serverul trimite primul înseamnă a te baza pe un accident în ordinea traficului care se va schimba într-o rețea liniștită. Configurația ar trebui să declare direcția dorită, nu să o descopere.

Pentru o parte aflată în spatele unei traduceri care trebuie să rămână accesibilă, activați un keepalive persistent pe acea parte. Un keepalive la fiecare 25 de secunde este valoarea inițială obișnuită, iar scopul său este să țină maparea deschisă, nu să testeze tunelul. Alegeți o singură parte care să îl poarte, pentru că activarea pe ambele părți dublează traficul și zgomotul din jurnale fără a îmbunătăți rezultatul.

Comparați starea înainte și după declanșator

Capturați cele două vederi în momentul în care eșuează, apoi din nou după ce serverul trimite. Prima comandă arată punctele finale și vârsta handshake-ului. A doua arată dacă există o intrare de traducere pentru port. Captura arată ce direcție a trecut cu adevărat prin cablu, iar verificarea rutei confirmă că clientul nu trimite acel trafic cu totul în altă parte.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Notați coloana punctului final și intrarea de traducere împreună. O parte fără punct final și o poartă fără mapare sunt două defecțiuni diferite. Doar una dintre ele este remediată de un keepalive.