WireGuard teljes alagút: az AllowedIPs 0.0.0.0/0 nem elég

A 0.0.0.0/0, ::/0 beírása egy peer AllowedIPs mezőjébe az a lépés, amelyre mindenki emlékszik, és ez csak azt dönti el, milyen forgalmat szállíthat a peer. Ezek az előtagok nem hoznak létre útvonalakat, nem továbbítanak semmit a túloldalon, és minden alkalmazás feloldóját pontosan ott hagyják, ahol volt. Négy külön dolognak kell egyszerre teljesülnie ahhoz, hogy egy teljes alagút teljes alagút legyen, és ezeket a legjobb az alábbi sorrendben ellenőrizni, mert egy későbbi ellenőrzés nem menthet meg egy korábbit. Az alábbi ellenőrzések mindegyike gépről leolvasható tény, nem olyan beállítás, amelyről reméled, hogy alkalmazták.

Mit választ ki a peer előtagja, és mit nem

Az AllowedIPs egyszerre szelektor és engedélyező. Megmondja a helyi oldalnak, mely célállomások küldhetők ennek a peernek, és megmondja a fogadó oldalnak, milyen forrás-címeket mutathat be ez a peer. Ez a teljes munka. Ebben a leírásban semmi nem hoz létre útvonalat a gazdagépen, nem kapcsolja be a továbbítást a távoli oldalon, és nem nyúl a névfeloldáshoz.

Ezért tűnhet teljesnek egy konfiguráció, és viselkedhet osztott alagútként. Az előtag azt mondja, hogy a peer mindent elfogadna; a gazdagép útvonaltáblája dönti el, mi érkezik oda valóban, az átjáró pedig azt, hogy kimegy-e valami. E három döntés egyike sem él a peer szakaszban.

Az ügyfél útvonalazása, nem csak a peer lista

Az olyan kezelők, mint a wg-quick, helyetted programozzák a gazdagép útvonaltábláját, ezért viselkedik két azonos konfigurációs fájl másképp attól függően, hogyan jött fel az interfész. Egy minimális profil elég rövid ahhoz, hogy egyben elolvasd:

[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

Két részlet hordozza a munkát. Az Address mező egyetlen gazdagép-előtag, nem pedig olyan alhálózat, amelyet az ügyfél a sajátjának hisz, és a kezelő az, amely az alapértelmezett AllowedIPs-t valódi alapértelmezett útvonallá alakítja. Hozd fel ugyanezt a fájlt ip link és wg setconf használatával, és egyáltalán nem jelenik meg útvonal, ami törött alagútnak látszik, valójában pedig egészséges alagút, amelyből kimaradt az útvonalazási lépés. A wg-quick kézikönyve dokumentálja az útvonalazást és a Table viselkedést, amelyet ezek a kezelők hozzáadnak.

Az eredményt olvasd, ne a fájlt: ip route get 1.1.1.1 az alagút interfészét kell megnevezze, és wg show friss kézfogást kell jelentsen mozgó átvitelszámlálóval. Az útvonal nélküli kézfogás azt jelenti, hogy a kezelő soha nem futott, és a profil újbóli szerkesztése nem javítja meg. Úgy indítsd az interfészt, ahogy a felhasználó indítja, különben a teszt a shell-ed méri a telepítés helyett.

A végpontot az alagúton kívül tartani

A teljes alagút minden célállomást elkap, beleértve azt is, amellyel a létezéshez beszélnie kell. A kezelők ezt úgy oldják meg, hogy gazdagép-útvonalat adnak a végponthoz az eredeti átjárón keresztül, ezért tartalmaz egy helyes konfiguráció szinte mindig egy szándékos kivételt. A konfiguráció felét kezelővel, a másik felét kézzel alkalmazni a szokásos módja annak, hogy ez a kivétel elvesszen.

Ha a végpont olyan gazdagépnév, amely több címre vagy olyan családra oldódik fel, amelyet nem szállítasz, a kivétel rosszul öregszik, és az alagút meghibásodhat egy rutinszerűnek tűnő újracsatlakozás után. Rögzítsd a végpontot egy általad irányított címhez, vagy erősítsd meg, hogy a kezelő újraértékeli, és minden hálózati változás után olvasd újra a gazdagép-útvonalat.

Ugyanez a mechanizmus magyarázza, miért harcol egy teljes alagút és egy fogolyportál. A portál elvárja, hogy elfogja a forgalmat, amelyet az alagutad most elkap, ezért szállodai és repülőtéri hálózatokon a portál bejelentkezése után hozod fel az alagutat, soha nem előtte.

Továbbítás és a visszaút az átjárón

Az átjárón kapcsold be a továbbítást az általad szállított családhoz, engedélyezd a forward láncot mindkét irányban, amikor fordítasz, és erősítsd meg a visszautat forrásspecifikus kereséssel. Ebből semmi nem következik egy sikeres kézfogásból, mert a kézfogás csak azt bizonyítja, hogy a két peer tud UDP-t cserélni. Semmit nem mond arról, mi történik utána a visszafejtett csomaggal.

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

A keresés az átjárón fut, nem az ügyfélen, különben más útvonaltáblát olvasol. Ha rossz interfészt nevez meg, vagy azt jelenti, hogy nincs útvonal, akkor semmilyen ügyféloldali változtatás nem hoz létre internetes kijáratot. Amikor az átjáró az ügyfélcímeket kifelé menet fordítja, a válasz ezen fordítási állapottól függ, ezért a szabálynak a folyamat mindkét irányára léteznie kell, nem csak a kimenőre.

DNS és a hibaállapot, külön tesztelve

Maga a protokoll nem állítja be egyetlen alkalmazás feloldóját sem. wg-quick a disztribúció feloldó-integrációján keresztül alkalmazza a DNS sort, a saját vermekkel rendelkező konténerek és böngészők figyelmen kívül hagyhatják, és ezért egy név meghibásodhat, miközben az alagút tökéletesen szállít csomagokat. Gazdagépnévvel tesztelj cím helyett, és jegyezd fel, melyik kiszolgáló válaszolt, ahelyett hogy feltételeznéd, hogy a profilban lévő tette.

A címcsaládok külön teszt külön válasszal. A v4-es alapértelmezett útvonal semmit nem mond arról, mit fog tenni egy alkalmazás v6-os kapcsolata, és az az alagút, amely csendben kiszivárogtatja a második családot, rosszabb annál, amely hangosan meghibásodik. Kérdezz nevet minden családon keresztül, olvasd el, melyik interfészt használta az egyes kérések, és ellenőrizd a fordítási számlálókat előtte és utána, mert a semmihez nem illő szabály pontosan úgy néz ki, mint a hiányzó szabály.

Végül teszteld azt az állapotot, amelyet akkor szeretnél, amikor az alagút leáll. A teljes alagútnak zártan kell meghibásodnia az általa igényelt forgalomra: ha az interfész leesik, és az alkalmazások csendben tovább mennek a fizikai kapcsolaton, a tervezés extra lépésekkel rendelkező osztott alagút. Írd le a szándékolt hiba-viselkedést, ellenőrizd szándékosan, és fejezd be a négy válasz rögzítésével — melyik kezelő hozza fel az interfészt, melyik útvonal viszi az alapértelmezettet, ki továbbít és fordít az átjárón, és melyik feloldó válaszol.