WireGuard PersistentKeepalive: păstrați maparea NAT vie

Cutia de acasă deschide tunelul și ajunge la serverul din cloud fără probleme. Serverul din cloud poate ajunge la aplicația de acasă timp de un minut sau două după ce cutia de acasă a trimis ceva ultima dată, apoi se oprește. Nu apare nimic în jurnalul WireGuard, nu se raportează nicio eroare de handshake, iar repornirea tunelului o repară pentru scurt timp. Acest model este o mapare care expiră, nu un tunel defect, iar ghidul de mai jos confirmă asta înainte de a schimba ceva.

Confirmați că modelul este o expirare în repaus

Detaliul care îl distinge este momentul. Dacă conexiunea inversă funcționează imediat după ce peerul de acasă trimite trafic și eșuează după un interval liniștit, calea este în regulă, iar starea din mijloc nu. Dacă nu a funcționat niciodată, chiar și imediat după trafic, acesta este diagnosticul greșit.

sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transfer

Rulați primele două imediat după ce peerul de acasă trimite ceva, așteptați cinci minute și rulați-le din nou. Un marcaj temporal de handshake care se reînnoiește conform programului fără un punct final nou vă spune că tunelul este viu. Ce s-a schimbat este capacitatea pachetelor nesolicitate de a ajunge din exterior, care este o proprietate a căii și nu a tunelului.

Apoi faceți o încercare inversă și urmăriți contoarele de transfer. Dacă partea din cloud trimite octeți și partea de acasă nu primește niciunul, pachetul a părăsit cloudul și a murit într-un dispozitiv care ține starea pe drum. Aceasta este semnătura pe care o căutați. Dacă ambele contoare se mișcă, tunelul a livrat pachetul, iar aplicația este suspectul.

Puneți keepalive pe peerul din spatele routerului

Keepalive-urile persistente mențin vie o mapare NAT și orice stare a firewall-ului trimițând periodic un pachet mic autentificat. Setarea aparține mașinii din spatele routerului, în intrarea ei pentru peerul îndepărtat, pentru că aceea este partea al cărei pachet de ieșire creează starea.

[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25

Îmbinați-o în secțiunea de peer existentă. Adăugarea unui al doilea bloc cu aceeași cheie publică nu este o modalitate validă de a adăuga opțiuni, iar wg-quick nu le va îmbina pentru dumneavoastră. Cei 25 de secunde documentați sunt un exemplu ales ca să stea sub timeout-urile UDP obișnuite, nu o valoare cu vreo semnificație specială.

Punerea aceleiași directive pe partea din cloud nu ajută la această problemă. Pachetele acelui peer vin deja de la o adresă publică, așa că nu există nicio mapare de păstrat în direcția care contează. Adaugă trafic și nu schimbă nimic.

Citiți temporizatoarele în loc să ghiciți un interval

Keepalive-urile funcționează pentru că sosesc mai des decât expiră starea. Asta face din timeout numărul de care aveți cu adevărat nevoie, iar pe Linux poate fi citit pe dispozitivul care face traducerea:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820

Prima valoare este timeout-ul pentru un flux UDP văzut doar într-o singură direcție, iar a doua se aplică după ce au fost observate răspunsuri. Ambele sunt de obicei scurte, iar o mapare care tace va urma ceea ce se aplică fluxului dumneavoastră.

Comparați acel număr cu intervalul dumneavoastră. Un keepalive de 25 de secunde sub un timeout de 30 de secunde funcționează; același keepalive sub un timeout de 15 secunde nu funcționează. Nicio cantitate de reîncercări nu schimbă acea aritmetică. Unii routere de consum și operatori mobili folosesc valori mult mai scurte decât valoarea implicită din Linux, motiv pentru care o configurație care funcționează într-o rețea eșuează în alta.

Verificați ascultătorul și firewall-ul separat

O mapare vie este necesară și nu suficientă. Aplicația de pe cutia de acasă trebuie să asculte pe adresa corectă, iar firewall-ul gazdei trebuie să permită pachetul după decriptare.

sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/health

Dacă socketul este legat doar de adresa interfeței fizice și nu de adresa tunelului, pachetele care sosesc pe tunel sunt aruncate înainte ca firewall-ul să fie măcar întrebat. Această defecțiune arată din partea cloudului identic cu o problemă de mapare și supraviețuiește oricărei ajustări de keepalive.

Verificarea listei permise este la fel de importantă în cealaltă direcție. Peerul din cloud trebuie să permită adresa tunelului de acasă ca sursă dacă va răspunde, iar peerul de acasă trebuie să permită adresa din cloud ca destinație. Pachetele keepalive sunt trafic autentificat și aplică aceleași reguli, de aceea un keepalive care pare să funcționeze poate coexista cu o aplicație care nu funcționează.

Implementați schimbarea și cunoașteți-i limitele

Aplicați setarea, reporniți interfața dacă este metoda dumneavoastră de actualizare, apoi repetați testul de inactivitate în loc de testul imediat. Așteptați mai mult decât timeout-ul citit anterior, faceți o cerere inversă și confirmați că contoarele s-au mișcat la ambele capete.

Notați intervalul și timeout-ul măsurat lângă el. O modificare viitoare a firmware-ului routerului, sau o trecere la o conexiune mobilă, poate modifica timeout-ul. Nota este ceea ce îi permite cuiva să rederive valoarea în loc să o copieze. Două numere pe o linie economisesc mai târziu o întreagă investigație.

Keepalive-urile persistente protejează starea. Nu deschid un port, nu adaugă o intrare în lista permisă și nu fac să apară un ascultător. Când conexiunea inversă nu funcționează deloc, vina este una dintre aceste trei, iar pornirea rapidă WireGuard descrie setarea keepalive în aceiași termeni înguști.