Un peer WireGuard inaccesibil în timp ce altul funcționează: listă de verificare

Un peer WireGuard trece traficul și al doilea finalizează strângerea de mână dar nu ajunge niciodată la nimic din spatele tunelului. Peerul care funcționează vă spune că interfața, portul UDP și cheia serverului sunt probabil în regulă. Nu vă spune nimic despre AllowedIPs ale celui de-al doilea peer, despre adresa sa sursă internă sau despre regulile de redirecționare dintre ele. Parcurgeți lista în ordine și opriți-vă la primul pas a cărui condiție eșuează.

Pasul 1: Notați calea pe care ar trebui să meargă pachetul

Doi clienți pe același hub nu se ating automat unul pe celălalt. Într-un design hub și spițe, serverul primește pachetul pe wg0 și trebuie să îl redirecționeze din nou afară din wg0 către celălalt peer, ceea ce cere redirecționare IP și o regulă de redirecționare. Într-un design direct peer-la-peer, fiecare parte are nevoie de punctul final al celeilalte și de adresa tunelului acesteia în AllowedIPs. Decideți ce design depanați înainte de a citi orice configurație.

Calea așteptată vă spune și unde să priviți. Dacă pachetul trebuie să traverseze hubul, saltul care eșuează este fie AllowedIPs ale expeditorului, fie redirecționarea hubului, fie AllowedIPs ale destinatarului. Dacă trebuie să meargă direct, hubul este irelevant și contează câmpurile de punct final de pe ambii peeri.

Pasul 2: Comparați AllowedIPs pe ambele părți, nu doar pe una

WireGuard folosește AllowedIPs atât ca tabel de rutare, cât și ca listă de acces. La trimitere, adresa de destinație este căutată în AllowedIPs ale peerului pentru a alege tunelul; la primire, adresa sursă internă trebuie să cadă în AllowedIPs ale peerului care trimite, altfel pachetul este eliminat. Un interval lipsă pe oricare parte produce același simptom: transportul funcționează, încărcătura dispare.

Citiți starea live în locul fișierului, pentru că o reîncărcare poate eșua în tăcere: sudo wg show wg0 allowed-ips. Pe server, intrarea peerului care eșuează trebuie să includă adresa tunelului său, de exemplu 10.90.0.3/32. Pe client, intrarea peerului server trebuie să includă destinația pe care o testați, fie că este adresa tunelului hubului, fie subrețeaua îndepărtată. Intervalele suprapuse fac căutarea ambiguă și pot selecta un peer pe care nu l-ați intenționat, așa că țineți-le separate.

Pasul 3: Verificați adresa sursă internă

Un client care rutează 10.90.0.3 prin wg0 dar trimite pachete de la adresa sa Wi-Fi va fi respins de destinatar, pentru că sursa nu corespunde AllowedIPs ale peerului. Confirmați ce selectează de fapt nucleul cu ip route get 10.90.0.3 from 10.90.0.2, și confirmați adresa atribuită interfeței tunelului cu ip -brief addr show wg0.

Pe gazda Linux care primește, filtrarea căii inverse este o a doua poartă. Un rp_filter strict pe interfața care deține ruta de întoarcere poate elimina traficul tunelului a cărui cale de întoarcere nu corespunde interfeței pe care a sosit. Verificați valoarea efectivă înainte de a-l dezactiva; în multe topologii corectarea potrivită este o rută, nu un filtru relaxat.

Pasul 4: Revedeați redirecționarea hubului și calea de întoarcere

Dacă hubul trebuie să redirecționeze între peeri, nucleul are nevoie de net.ipv4.ip_forward=1, iar paravanul de foc trebuie să accepte fluxul redirecționat: intrare pe wg0, ieșire pe wg0, de la adresa tunelului expeditorului la cea a destinatarului. O defecțiune frecventă este o regulă de intrare care acceptă UDP 51820 dar nicio regulă de redirecționare], așa că strângerea de mână reușește și încărcătura moare. Listați regulile efective cu sudo nft list ruleset sau echivalentul pentru managerul dumneavoastră de paravan de foc.

Apoi verificați răspunsul. Gazda de destinație trebuie să aibă o rută înapoi la expeditor, fie prin hub, fie prin propria poartă. Dacă hubul face și NAT pe subrețeaua tunelului, confirmați că traducerea se aplică fluxului redirecționat și că răspunsul ajunge la hub înainte ca starea să expire. O defecțiune unidirecțională care pare o problemă de cheie este adesea doar această rută de întoarcere.

În final, separați strângerea de mână de date. Un peer care finalizează strângerea de mână dar se blochează la transferuri mari are de obicei o problemă de MTU sau MSS pe acea cale, nu o problemă de AllowedIPs. Testați mai întâi cu un ping mic, apoi cu unul de dimensiune completă, și comparați cei doi peeri.

Pasul 5: Schimbați un singur lucru și păstrați intact peerul care funcționează

Faceți o singură modificare pe calea care eșuează și retestați ambii peeri. Înlocuirea AllowedIPs ale fiecărui peer cu 0.0.0.0/0 este cea mai rapidă cale de a rupe peerul care funcționa deja, pentru că schimbă decizia de rutare pentru tot traficul de pe acea interfață. Editați acea singură intrare, reîncărcați și recitiți starea live.

Notați ce cale a reușit, care a eșuat și ieșirea exactă a comenzii pentru fiecare. Acea comparație valorează mai mult decât un raport general că VPN-ul este stricat, și este primul lucru pe care îl va cere următoarea persoană.