WireGuard peer nedostupan dok drugi radi: kontrolni popis

Jedan WireGuard peer prenosi saobraćaj, a drugi obavi rukovanje ali nikada ne stigne do ničega iza tunela. Peer koji radi govori vam da su interfejs, UDP port i serverski ključ vjerovatno u redu. On ne govori ništa o AllowedIPs drugog peera, njegovoj unutrašnjoj izvornoj adresi ni o pravilima prosljeđivanja između njih. Prođite listu po redu i zaustavite se na prvom koraku čiji uslov pada.

Korak 1: Zapišite putanju kojom paket treba da prođe

Dva klijenta na istom čvorištu ne stižu jedan do drugog automatski. U dizajnu čvorišta i krakova server prima paket na wg0 i mora ga proslijediti natrag iz wg0 ka drugom peeru, što zahtijeva IP prosljeđivanje i pravilo prosljeđivanja. U direktnom peer-na-peer dizajnu svaka strana treba endpoint druge strane i adresu njenog tunela unutar AllowedIPs. Odlučite koji dizajn ispravljate prije nego što pročitate bilo koju konfiguraciju.

Očekivana putanja takođe govori gdje da tražite. Ako paket treba da pređe preko čvorišta, neuspjeli skok je ili AllowedIPs pošiljaoca, ili prosljeđivanje čvorišta, ili AllowedIPs primaoca. Ako treba da ide direktno, čvorište je nevažno i polja endpointa na oba peera su važna.

Korak 2: Uporedite AllowedIPs na obje strane, ne samo na jednoj

WireGuard koristi AllowedIPs i kao tabelu rutiranja i kao listu pristupa. Pri slanju se odredišna adresa traži u AllowedIPs peera da bi se izabrao tunel; pri primanju unutrašnja izvorna adresa mora pasti unutar AllowedIPs peera koji šalje, inače se paket odbacuje. Nedostajući opseg na bilo kojoj strani daje isti simptom: transport radi, teret nestaje.

Čitajte živo stanje, a ne datoteku, jer ponovno učitavanje možda je tiho neuspjelo: sudo wg show wg0 allowed-ips. Na serveru zapis neuspjelog peera mora sadržavati adresu njegovog tunela, na primjer 10.90.0.3/32. Na klijentu zapis peera-servera mora sadržavati odredište koje testirate, bilo da je to adresa tunela čvorišta ili udaljena podmreža. Opsezi koji se preklapaju čine pretragu dvosmislenom i mogu odabrati peer koji niste namjeravali, zato ih držite odvojene.

Korak 3: Provjerite unutrašnju izvornu adresu

Klijent koji rutira 10.90.0.3 kroz wg0 ali šalje pakete sa svoje Wi-Fi adrese bit će odbijen od primaoca, jer izvor ne odgovara AllowedIPs peera. Potvrdite šta kernel zaista bira pomoću ip route get 10.90.0.3 from 10.90.0.2 i potvrdite adresu dodijeljenu interfejsu tunela pomoću ip -brief addr show wg0.

Na prijemničkom Linux hostu filtriranje obrnutog puta je druga kapija. Strogi rp_filter na interfejsu koji posjeduje povratnu rutu može odbaciti tunelski saobraćaj čiji povratni put ne odgovara interfejsu na koji je stigao. Provjerite efektivnu vrijednost prije nego što ga isključite; u mnogim topologijama ispravan popravak je ruta, a ne ublažen filter.

Korak 4: Pregledajte prosljeđivanje na čvorištu i povratni put

Ako čvorište mora prosljeđivati između peera, kernelu treba net.ipv4.ip_forward=1, a vatrozid mora prihvatiti proslijeđeni tok: ulaz na wg0, izlaz na wg0, od adrese tunela pošiljaoca do primaoca. Čest kvar je ulazno pravilo koje prihvata UDP 51820 ali nema pravilo prosljeđivanja], pa rukovanje uspije a teret umre. Popišite važeća pravila pomoću sudo nft list ruleset ili ekvivalenta za vaš upravljač vatrozida.

Zatim provjerite odgovor. Odredišni host mora imati rutu natrag do pošiljaoca, bilo kroz čvorište bilo kroz vlastiti gateway. Ako čvorište takođe radi NAT za tunelsku podmrežu, potvrdite da se prevođenje primjenjuje na proslijeđeni tok i da odgovor stiže do čvorišta prije nego što stanje istekne. Jednosmjerni kvar koji izgleda kao problem s ključem često je samo ta povratna ruta.

Na kraju, odvojite rukovanje od podataka. Peer koji završi rukovanje ali zapne na velikim prijenosima obično ima problem s MTU ili MSS na toj konkretnoj putanji, a ne problem s AllowedIPs. Testirajte prvo malim pingom, zatim pingom pune veličine i uporedite dva peera.

Korak 5: Promijenite jednu stvar i sačuvajte radni peer netaknutim

Napravite jednu jedinu promjenu na neuspjeloj putanji i ponovo testirajte oba peera. Zamjena AllowedIPs svakog peera sa 0.0.0.0/0 najbrži je način da slomite peer koji je već radio, jer mijenja odluku o rutiranju za sav saobraćaj na tom interfejsu. Uredite jedan zapis, učitajte ponovo i pročitajte živo stanje natrag.

Zabilježite koja je putanja uspjela, koja nije i tačan izlaz komande za svaku. To poređenje vrijedi više od općeg izvještaja da je VPN pokvaren i prvo je što će sljedeća osoba tražiti.