Prefix hostiteľa vo WireGuarde: prečo jedna adresa funguje a ostatné nie

Tunel je hore, handshake prebieha každé dve minúty a presne jedna adresa na druhej strane odpovedá. Pingy na tunelovú adresu peera fungujú; nič za ňou nie. Niekto si prečíta konfiguráciu rozhrania, uvidí prefix hostiteľa a usúdi, že maska je zlá. Rozšírenie na /24 ping na chvíľu opraví a potom pokazí niečo iné. Prefix nikdy nebol príčinou a chýbajúca trasa nie je tá, ktorú maska ovláda.

Čo prefix rozhrania skutočne vytvára

V Linuxe priradenie adresy rozhraniu vytvorí pripojenú trasu pre tento prefix. Ak priradíte prefix hostiteľa, pripojená trasa pokrýva jednu adresu. Ak priradíte /24, pokrýva 256 a každá z nich sa teraz považuje za dosiahnuteľnú cez toto spojenie.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Prefix hostiteľa je pre tunel typu bod-bod úplne normálna voľba, pretože na druhom konci je presne jeden peer. Tretí príkaz je ten, ktorý odpovedá na používateľovu otázku: hovorí, ktoré rozhranie by jadro pre tento cieľ použilo, a neukáže nič užitočné, ak nepasuje žiadna trasa.

To je celé vysvetlenie symptómu. Jedna adresa odpovedá preto, lebo pre ňu existuje pripojená trasa, alebo preto, lebo zoznam povolených peera ju náhodou obsahuje. Všetko ostatné nemá trasu a je zahodené skôr, než sa WireGuard vôbec zapojí. Tunel je po celý čas zdravý, a preto počítadlo handshake vyzerá naďalej upokojujúco.

AllowedIPs sú dve pravidlá pod jedným menom

Zoznam povolených pre každého peera vo WireGuarde robí dve veci naraz a syntax konfigurácie ich necháva vyzerať ako jednu. Na vstupe povoľuje, ktoré zdrojové adresy smie peer predložiť. Na výstupe vyberá, ktorému peerovi sa paket pošle, a to nájdením najkonkrétnejšej zhody.

Ani jedna z tých vecí nie je routing. Jadro stále musí rozhodnúť, že paket patrí na tunelové rozhranie, skôr než sa naň WireGuard pozrie, a toto rozhodnutie pochádza z routovacej tabuľky. Záznam peera so širokým zoznamom povolených sám o sebe trasu nenainštaluje.

Preto môže konfigurácia vyzerať úplne a správať sa asymetricky. Klient posiela na druhú stranu, pretože existuje trasa, a odpovede nikdy nedorazia, pretože zoznam povolených druhej strany nepovoľuje zdroj klienta, alebo pretože druhá strana nemá spiatočnú cestu. Oba smery sú samostatné rozhodnutia so samostatnými režimami zlyhania. Zapísať, ktorý z nich testujete, je polovica diagnózy.

Odkiaľ trasa pochádza

Ak používate wg-quick, trasy sa za vás generujú zo zoznamu povolených každého peera, ak ste nenastavili Table = off a neprevzali kontrolu sami. To je správanie, ktoré nástroj dokumentuje, a je to dôvod, prečo konfigurácia bez explicitných direktív trás napriek tomu funguje.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Porovnajte zoznam povolených s trasami, ktoré skutočne existujú. Peer, ktorý povoľuje celú podsiet, ale vytvoril len trasu hostiteľa, znamená, že pomocník nikdy nebežal, alebo že rozhranie spravujete priamo pomocou wg a ip, a v tom prípade vám nič trasy negeneruje.

Keď ho spravujete ručne, trasa je jeden riadok a jej tvar je explicitný: cieľ cez rozhranie, bez brány, pretože spojenie je bod-bod. Pridať ju nie je barlička za zlý prefix; je to chýbajúca polovica návrhu, ktorý sa rozhodol routing riadiť sám.

Širší prefix záznam peera nepridá

Lákavá oprava je zmeniť adresu na /24, aby pripojená trasa pokryla LAN servera. Vyzerá to, že to funguje, a dôvod, prečo to vyzerá, že funguje, je ten, že pripojená trasa teraz pasuje, nie že by sa WireGuard niečo nové naučil.

Čo ste tiež urobili, je nárokovanie celého rozsahu ako priamo dosiahnuteľného cez toto spojenie, vrátane adries, ktoré patria iným peerom alebo LAN, ktorá je v skutočnosti za serverom. Prevádzka na tieto adresy teraz vstupuje do tunela, a či vyjde na druhej strane, závisí od routingu a zoznamov povolených samotného servera.

Kryptografická stránka nie je nijako dotknutá. WireGuard stále potrebuje záznam v zozname povolených, ktorý pokrýva cieľ, aby vybral peera, a druhá strana stále potrebuje záznam, ktorý pokrýva váš zdroj, aby ho prijala. Širší prefix rozhrania nemôže dodať ani jedno.

Potvrďte oba smery, než čokoľvek zmeníte

Spracujte oba konce oddelene a zapíšte, čo každý hovorí. Na klientovi trasa a záznam peera; na serveri zrkadlový obraz plus jeho vlastná spiatočná cesta:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Zachytenie je to, čo rozhoduje spory o smer. Ak sa odchádzajúce pakety objavia na tunelovom rozhraní a server nič neloguje, vzdialený koniec ich odmieta, zvyčajne preto, že váš zdroj je mimo jeho zoznamu povolených. Ak sa neobjaví vôbec nič, trasa chýba alebo ukazuje inam.

Potom opravte užší koniec. Záznam v zozname povolených na strane servera pre adresu vášho klienta a záznam na strane klienta pre cieľovú podsiet je normálny tvar a ponecháva prefix rozhrania na pokoji. Prefix rozširujte len vtedy, ak adresný plán naozaj chce zdieľanú podsiet na tomto spojení, a urobte to ako zmenu plánu, nie ako krok ladenia.