Üks WireGuard-peer pole kättesaadav, teine töötab: kontrollnimekiri

Üks WireGuard-peer edastab liiklust ja teine teeb kätluse, kuid ei jõua kunagi millegini tunnelist väljaspool. Töötav peer ütleb teile, et liides, UDP port ja serveri võti on tõenäoliselt korras. See ei ütle midagi teise peeri AllowedIPs-i, selle sisemise lähteaadressi ega nende vaheliste edastusreeglite kohta. Käige nimekiri järjekorras läbi ja peatuge esimese sammu juures, mille tingimus ei kehti.

Samm 1: Kirjutage üles tee, mida pakett peaks läbima

Kaks klienti samas keskmes ei jõua automaatselt teineteiseni. Keskme ja kodarate lahenduses võtab server paketi vastu liidesel wg0 ja peab selle uuesti wg0-st teise peerini edasi saatma, mis nõuab IP-edastust ja edastusreeglit. Otseses peer-to-peer lahenduses vajab kumbki pool teise otspunkti ja teise tunneli aadressi AllowedIPs-i sees. Otsustage, millist lahendust te silute, enne kui loete ükskõik millist seadistust.

Eeldatav tee ütleb teile ka, kuhu vaadata. Kui pakett peaks keskme läbima, on ebaõnnestuv hüpe kas saatja AllowedIPs, keskme edastus või vastuvõtja AllowedIPs. Kui see peaks minema otse, on keskmus tähtsusetu ja mõlema peeri otspunkti väljad on need, mis loevad.

Samm 2: Võrrelge AllowedIPs-i mõlemal poolel, mitte ainult ühel

WireGuard kasutab AllowedIPs-i üheaegselt marsruutimistabeli ja juurdepääsunimekirjana. Saatmisel otsitakse sihtaadress peeri AllowedIPs-ist, et valida tunnel; vastuvõtmisel peab sisemine lähteaadress jääma saatva peeri AllowedIPs-i sisse, muidu pakett visatakse kõrvale. Puuduv vahemik kummalgi poolel annab sama sümptomi: transport töötab, kasulik koormus kaob.

Lugege reaalajas olekut, mitte faili, sest uuestilaadimine võis vaikselt ebaõnnestuda: sudo wg show wg0 allowed-ips. Serveris peab ebaõnnestuva peeri kirje sisaldama selle tunneli aadressi, näiteks 10.90.0.3/32. Kliendis peab serveri peeri kirje sisaldama sihtaadressi, mida te testite, olgu see siis keskme tunneli aadress või kaugem alavõrk. Kattuvad vahemikud muudavad otsingu mitmetähenduslikuks ja võivad valida peeri, mida te ei kavatsenud, seega hoidke need eraldi.

Samm 3: Kontrollige sisemist lähteaadressi

Klient, mis marsruudib 10.90.0.3 wg0 kaudu, kuid saadab pakette oma Wi-Fi aadressilt, lükatakse vastuvõtja poolt tagasi, sest lähe ei vasta peeri AllowedIPs-ile. Kinnitage, mida kernel tegelikult valib, käsuga ip route get 10.90.0.3 from 10.90.0.2, ja kinnitage tunneli liidesele määratud aadress käsuga ip -brief addr show wg0.

Vastuvõtvas Linux-hostis on pöördteekonna filtreerimine teine värav. Range rp_filter liidesel, millel on tagasitee marsruut, võib kõrvale visata tunneli liikluse, mille tagasitee ei vasta liidesele, millelt see saabus. Kontrollige tegelikku väärtust enne selle keelamist; paljudes topoloogiates on õige parandus marsruut, mitte lõdvendatud filter.

Samm 4: Vaadake üle keskme edastus ja tagasitee

Kui keskmus peab peeride vahel edastama, vajab kernel net.ipv4.ip_forward=1 ja tulemüür peab edastatud voo vastu võtma: sisse wg0-lt, välja wg0-lt, saatja tunneli aadressilt vastuvõtja omale. Levinud tõrge on sisendreegel, mis lubab UDP 51820, kuid edastusreegel puudub], nii et kätlus õnnestub ja kasulik koormus sureb. Loetlege kehtivad reeglid käsuga sudo nft list ruleset või oma tulemüürihalduri vastega.

Seejärel kontrollige vastust. Sihtostil peab olema tagasitee saatjani, kas keskme või oma lüüsi kaudu. Kui keskmus teeb ka tunneli alavõrgule NAT-i, kinnitage, et tõlge kehtib edastatud voo kohta ja et vastus jõuab keskmesse enne oleku aegumist. Ühesuunaline tõrge, mis näeb välja nagu võtmeprobleem, on sageli just see tagasitee.

Lõpuks eraldage kätlus andmetest. Peer, mis lõpetab kätluse, kuid takerdub suurte edastuste juures, on tavaliselt MTU või MSS probleem just sellel teel, mitte AllowedIPs-i probleem. Testige esmalt väikese pingiga, seejärel täissuuruses pingiga, ja võrrelge kahte peeri.

Samm 5: Muutke üht asja ja hoidke töötav peer puutumatuna

Tehke ebaõnnestuval teel üksainus muudatus ja testige uuesti mõlemat peeri. Iga peeri AllowedIPs-i asendamine väärtusega 0.0.0.0/0 on kiireim viis rikkuda peer, mis juba töötas, sest see muudab marsruudiotuse kogu selle liidese liikluse jaoks. Muutke ühte kirjet, laadige uuesti ja lugege reaalajas olek tagasi.

Märkige üles, milline tee õnnestus, milline ebaõnnestus ja igaühe täpne käsu väljund. See võrdlus on väärt rohkem kui üldine teade, et VPN on katki, ja see on esimene asi, mida järgmine inimene küsib.