Plný tunel WireGuard: AllowedIPs 0.0.0.0/0 nestačí

Zadať 0.0.0.0/0, ::/0 do AllowedIPs peeru je krok, ktorý si všetci pamätajú, a rozhoduje len o tom, akú premávku smie peer prenášať. Tieto prefixy nevytvárajú žiadne trasy, nič nepreposielajú na druhej strane a nechávajú resolver každej aplikácie presne tam, kde bol. Štyri oddelené veci musia platiť súčasne, aby bol plný tunel skutočne plný, a najlepšie sa kontrolujú v poradí nižšie, pretože neskoršia kontrola nemôže zachrániť skoršiu. Každá kontrola nižšie je fakt, ktorý sa dá prečítať zo stroja, nie nastavenie, o ktorom dúfate, že bolo použité.

Čo prefix peeru vyberá a čo nie

AllowedIPs je zároveň selektor aj oprávnenie. Hovorí lokálnej strane, ktoré ciele sa smú posielať tomuto peeru, a prijímajúcej strane hovorí, ktoré zdrojové adresy smie tento peer predkladať. To je celá práca. Nič v tomto opise nevytvára trasu na hostiteľovi, nezapína preposielanie na vzdialenej strane ani sa nedotýka prekladu mien.

Práve preto konfigurácia môže vyzerať úplne a správať sa ako rozdelený tunel. Prefix hovorí, že peer by prijal všetko; smerovacia tabuľka hostiteľa rozhoduje, čo tam naozaj dorazí, a brána rozhoduje, či niečo vyjde. Žiadne z tých troch rozhodnutí nežije v sekcii peeru.

Smerovať klienta, nielen zoznam peerov

Správcovia ako wg-quick programujú smerovaciu tabuľku hostiteľa za vás, a preto sa dva rovnaké konfiguračné súbory správajú odlišne podľa toho, ako rozhranie vzniklo. Minimálny profil je dosť krátky na prečítanie na jeden dúšok:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Prácu nesú dva detaily. Pole Address je jeden prefix hostiteľa, nie podsiete, o ktorej si klient myslí, že ju vlastní, a práve správca prevádza predvolené AllowedIPs na skutočnú predvolenú trasu. Zdvíhnite ten istý súbor pomocou ip link a wg setconf a neobjaví sa vôbec žiadna trasa, čo vyzerá ako pokazený tunel, ale je to zdravý tunel s vynechaným krokom smerovania. Manuál wg-quick dokumentuje smerovanie a Table správanie, ktoré títo správcovia pridávajú.

Čítajte výsledok, nie súbor: ip route get 1.1.1.1 má pomenovať rozhranie tunela a wg show má hlásiť nedávny handshake s počítadlom prenosu, ktoré sa hýbe. Handshake bez trasy znamená, že správca nikdy nebežal, a ďalšia úprava profilu to nespraví. Spúšťajte rozhranie tak, ako ho spustí používateľ, inak test meria váš shell namiesto nasadenia.

Udržať koncový bod mimo tunela

Plný tunel zachytí každý cieľ, vrátane toho, s ktorým musí hovoriť, aby existoval. Správcovia to riešia pridaním trasy hostiteľa pre koncový bod cez pôvodnú bránu, a preto správna konfigurácia takmer vždy obsahuje jednu zámernú výnimku. Použitie polovice konfigurácie správcom a druhej polovice ručne je obvyklý spôsob, akým táto výnimka zmizne.

Ak je koncovým bodom meno hostiteľa, ktoré sa prekladá na niekoľko adries, alebo na rodinu, ktorú nenášíte, výnimka zle starne a tunel môže zlyhať po opätovnom pripojení, ktoré vyzeralo rutinne. Pripnite koncový bod na adresu, ktorú ovládate, alebo potvrďte, že ho správca prehodnocuje, a po každej zmene siete znova prečítajte trasu hostiteľa.

Ten istý mechanizmus vysvetľuje, prečo sa plný tunel a captive portál hádajú. Portál očakáva, že zachytí premávku, ktorú váš tunel teraz zachytáva, takže v hotelových a letiskových sieťach tunel zdvíhate po prihlásení do portálu, nikdy predtým.

Preposielanie a spätná cesta na bráne

Na bráne zapnite preposielanie pre rodinu, ktorú nesiete, povoľte forward reťaz v oboch smeroch, keď prekladáte, a potvrďte spätnú cestu vyhľadaním špecifickým pre zdroj. Nič z toho nevyplýva z úspešného handshake, pretože handshake dokazuje len to, že si dvaja peery môžu vymieňať UDP. Nič to nehovorí o tom, čo sa potom stane s dekapsulovaným paketom.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Vyhľadanie beží na bráne, nie na klientovi, inak budete čítať inú smerovaciu tabuľku. Ak pomenuje nesprávne rozhranie alebo ohlási, že žiadna trasa nie je, potom žiadna zmena na strane klienta nevytvorí výstup do internetu. Keď brána prekladá adresy klientov na ceste von, odpoveď závisí od tohto stavu prekladu, takže pravidlo musí existovať pre oba smery toku, nielen pre odchádzajúci.

DNS a stav zlyhania, testované oddelene

Protokol sám nenastavuje resolver žiadnej aplikácie. wg-quick aplikuje riadok DNS cez integráciu resolvera distribúcie, kontajnery a prehliadače s vlastnými stackmi ho môžu ignorovať, a preto meno môže zlyhať, zatiaľ čo tunel nesie pakety bezchybne. Testujte menom hostiteľa, nie adresou, a poznamenajte, ktorý server odpovedal, namiesto toho, aby ste predpokladali, že to bol ten z profilu.

Rodiny adries sú samostatný test so samostatnou odpoveďou. Predvolená trasa v4 nehovorí nič o tom, čo urobí v6 pripojenie nejakej aplikácie, a tunel, ktorý ticho prepúšťa druhú rodinu, je horší než ten, ktorý nahlas zlyháva. Pýtajte sa na meno cez každú rodinu, prečítajte rozhranie, ktoré použil každý dopyt, a skontrolujte počítadlá prekladu pred a po, pretože pravidlo, ktoré na nič nepasuje, vyzerá rovnako ako chýbajúce pravidlo.

Nakoniec otestujte stav, ktorý chcete, keď sa tunel zastaví. Plný tunel má zlyhať zatvorene pre premávku, ktorú tvrdí: ak rozhranie spadne a aplikácie ticho pokračujú cez fyzické spojenie, je návrh rozdelený tunel s krokmi navyše. Zapíšte zamýšľané správanie pri zlyhaní, zámerne ho skontrolujte a skončite zapísaním štyroch odpovedí — ktorý správca zdvíha rozhranie, ktorá trasa nesie predvolenú, kto preposiela a prekladá na bráne a ktorý resolver odpovedá.