Handshake-ul WireGuard funcționează, dar nu există internet: urmărește pachetul

Tunelul este activ, wg show raportează un handshake recent, poți da ping la adresa tunelului serverului, și nimic dincolo de ea nu răspunde. Primul instinct este să regenerezi cheile sau să partajezi din nou configurația. Asta schimbă exact partea din traseu care este deja dovedită ca funcționând.

Un handshake finalizat spune că cele două părți sunt de acord asupra cheilor, că UDP ajunge la punctul final și că rutarea criptografică acceptă pachetul. Nu spune nimic despre dacă pachetul poate părăsi serverul după aceea.

Așa că urmărește un singur pachet în loc să ghicești. Sunt patru locuri unde poate muri, și fiecare lasă o urmă diferită.

Ce dovedește de fapt handshake-ul

WireGuard este un protocol UDP care stabilește o sesiune cu un handshake Noise și apoi criptează pachetele pentru un peer. Când wg show afișează un handshake de câteva secunde și un contor de transfer în creștere, punctul final, cheile și cheia publică a peer-ului sunt toate corecte.

Ce nu dovedește este că clientul tău trimite trafic către internet în interfață, că serverul este dispus să îl redirecționeze sau că un răspuns poate găsi drumul înapoi. Acestea sunt decizii de rutare ale nucleului și ale firewall-ului, și se iau în afara tunelului.

De aceea ping-ul către adresa tunelului serverului este un test atât de înșelător. Acel pachet este adresat serverului însuși, deci se termină local. Nu are niciodată nevoie de redirecționare, niciodată de traducere și niciodată de o rută de întoarcere din internet.

AllowedIPs este o decizie de rutare

Pe client, AllowedIPs face două treburi. Este tabelul de rutare pe cheie criptografică care decide ce adrese de destinație intră în tunelul acestui peer, și este lista de adrese sursă pe care peer-ul le va accepta de la tine. Dacă configurația clientului listează doar 10.8.0.0/24, destinațiile publice nu intră niciodată în interfață, iar ruta ta implicită obișnuită le duce în afara tunelului. Atunci tunelul funcționează perfect și nu face nimic din ce ai vrut.

Uită-te la ce a instalat de fapt clientul, nu la ce spune fișierul de configurare:

wg show wg0 allowed-ips
ip route get 1.1.1.1

A doua comandă este cea decisivă. Dacă răspunsul numește interfața ta fizică și gateway-ul obișnuit, pachetul nu este tunelat și nicio schimbare pe partea serverului nu va repara asta. Adaugă 0.0.0.0/0 pentru IPv4 și ::/0 pentru IPv6 separat; o regulă care prinde tot pentru o familie o lasă pe cealaltă pe traseul original, iar asta este o cauză frecventă a unui tunel IPv4 funcțional și a unei căutări IPv6 blocate.

Unde moare pachetul pe gateway

Dacă ruta este corectă și pachetul tot nu ajunge nicăieri, înseamnă că ajunge la server și se oprește acolo. Patru verificări acoperă majoritatea gateway-urilor.

Redirecționare. sysctl net.ipv4.ip_forward care returnează 0 este răspunsul clasic, iar multe distribuții sunt încă pe 0 implicit. Trebuie să fie 1, și setat permanent într-un fișier sysctl, nu cu o comandă care dispare la repornire. Redirecționarea IPv6 este un comutator separat.

Politica de filtrare. Un lanț FORWARD cu politică implicită de eliminare va arunca traficul tunelului, dar va permite traficul către gazdă însăși, ceea ce se potrivește exact simptomului. Citește setul de reguli activ, nu un fișier salvat: nft list ruleset sau iptables -S.

Traducere sau rutare. Clienții cu adrese private de tunel au nevoie fie de NAT sursă pe interfața de ieșire a serverului, fie de un prefix rutat pe care rețeaua superioară știe să îl returneze. Alegerea dintre ele urmează planul de adrese. Adăugarea MASQUERADE la o rețea care deja rutează prefixul tău înapoi este inofensivă, dar inutilă, iar omiterea ei acolo unde nu există rută lasă răspunsurile adresate către un interval privat nerutabil.

Drumul de întoarcere. În modelele rutate, routerul superior are nevoie de o rută care indică serverul tău. Rețeaua furnizorului poate și ea să blocheze: câteva cloud-uri activează o verificare a sursei și destinației pe instanță, care aruncă în liniște pachetele a căror sursă nu este adresa proprie a instanței, până când verificarea este dezactivată.

DNS eșuează altfel decât rutarea

Un pachet către o adresă cunoscută și o căutare de nume sunt două eșecuri separate, iar mesajele de eroare induc în eroare în direcții opuse. Dacă ping 1.1.1.1 funcționează și browserul nu încarcă nimic, ruta este bună și rezolvarea numelor nu. Dacă ping-ul însuși eșuează, DNS este irelevant și te-ai întors la secțiunea anterioară.

wg-quick poate seta un resolver din linia DNS = din configurație, iar systemd-resolved are propriul comportament pe legătură. Un VPN care suprascrie resolverul cu o adresă accesibilă doar în interiorul tunelului va eșua la fiecare căutare în momentul în care tunelul cade, ceea ce arată ca și cum tunelul ar strica internetul.

O ordine care produce dovezi

Rulează mai întâi verificarea pe partea clientului, pentru că este o singură comandă și elimină jumătate din posibilități. Apoi confirmă dacă serverul este gândit ca ieșire spre internet; un gateway construit pentru acces privat nu este stricat când destinațiile publice eșuează.

Pe server, urmărește interfața în timp ce trimiți un ping de pe client: tcpdump -ni wg0 icmp ar trebui să arate cererea, iar tcpdump -ni eth0 icmp ar trebui să arate că iese, tradusă sau nu. Dacă apare pe primul și niciodată pe al doilea, oprirea este locală pe server. Dacă iese și nu se întoarce niciun răspuns, problema este mai sus, și aceea este altă discuție.

La final, fă în așa fel încât corecția să supraviețuiască unei reporniri. Redirecționarea aparține unui fișier sysctl, regulile firewall aparțin serviciului care le încarcă, iar rutele clientului aparțin configurației care ridică interfața, nu unui shell pe care îl vei uita. Reconectează-te, repetă aceleași două teste și confirmă că numărătorii se mișcă.