Az AllowedIPs útválasztási lista, nem tűzfal-szabály

A legtöbben engedélylistaként olvassák az AllowedIPs mezőt: azon címek halmazát, amelyek kapcsolódhatnak egy partnerhez, nagyjából mint egy alagúthoz írt tűzfalszabályt. Nem erről van szó. A mező egy útválasztási tábla, amely mindkét irányban működik: partnert választ a kimenő csomaghoz, és ellenőrzi a bejövő csomag forrását. Engedélylistaként olvasva olyan konfigurációk születnek, amelyek olyan forgalmat irányítanak, amelyet senki sem kért.

Egy mező, két olvasó: kimeneti választás és forrásellenőrzés

Az ügyfélnél az előtagok döntik el, mely célok jutnak el ehhez a partnerhez, és melyek maradnak a szokásos hálózaton. Ezért a 0.0.0.0/0 bejegyzés minden IPv4-célt elkap, és ezért küldi a teljes alagút profiljának importálása a szokásos böngészést a távoli gépen keresztül. A szűk bejegyzések az ellenkezőjét teszik: csak a felsorolt hálózatokat irányítják, és minden mást ott hagynak, ahol volt. A WireGuard dokumentációjának kriptokulcs-útválasztási szakasza egy helyen mondja ki mindkét feladatot: a kimenő partner kiválasztását és a bejövő forrás ellenőrzését.

A kiszolgálón ugyanez a mező írja le, mely forráscímeket használhat az egyes partnerek. Ez kriptográfiai ellenőrzés, nem csomagszűrő: az a csomag, amelynek belső forrása nem egyezik a partner listájával, a WireGuardon belül elvész, mielőtt a gazdagép bármely tűzfala látná. Mindkét feladat egy listát oszt meg, és épp ezért viselkedik rosszul egy máshonnan másolt lista egy olyan helyen, amelyre nem gondolt.

Az ügyfélblokk az, ahol a legtöbb zavar elkezdődik. Az osztott alagút megnevezi a távoli hálózatokat, a teljes alagút pedig ugyanez a mező alapértelmezett előtaggal:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Mindkét forma önmagában teljes, és ezek alternatívák, nem lépések. Az első csak azt a két hálózatot küldi át az alagúton; a második minden célt elküld, a ::/0 bejegyzés pedig IPv6-ot ad az IPv4-alapértelmezéshez. Bármelyiket választja, ezek az előtagok jelentik a teljes útválasztási döntést ehhez a partnerhez, amint a wg-quick elkezdi telepíteni az útvonalakat.

A központnak más listára van szüksége

A központ minden ügyfél alagútcímét gazdagép-előtagként listázza, valamint minden hálózatot, amely valóban az adott ügyfél mögött van. Ha egy ügyfél széles listáját minden központi partnerre átmásoljuk, az azt mondja a központnak, hogy sok partner használhatja ugyanazokat a címeket forrásként, és ez nem címterv. A Endpoint mező teljesen más réteghez tartozik: a partner külső címét és portját nevezi meg, soha nem az alagúton belüli célt.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

A gazdagép-előtag hordozza az alagútcímet, a hálózati előtag pedig azt, ami az ügyfél mögött van, és mindkettőre szükség van. Gazdagép-előtag nélkül a központ nem tudja visszaküldeni az ügyfél saját forgalmát, hálózati előtag nélkül pedig a mögötte lévő LAN elérhetetlen marad; az a partner, amely mögött nincs semmi, csak a gazdagép-előtagot kapja.

Az útvonalak telepítésének kihagyása rést hagy

A wg-quick, a segéd, amely konfigurációs fájlból hozza fel az interfészt, ennek a munkának a részeként telepíti az interfész címeket és az útvonalakat. A Table = off beállítása azt mondja a segédnek, hogy hagyja ki az útvonal-munkát, ami nem telepít helyettesítőket, és nem teszi elérhetővé a magánhálózatot. Ha az automatikus útvonalak már elvégzik a munkát, a szükséges előtagok megnevezése a világosabb konfiguráció. Az útvonal-kezelés kikapcsolása és a helyettesítő íratlanul hagyása nem tervezés, hanem mulasztás.

Az alap wg eszköz másképp viselkedik: konfigurálja az interfészt, és soha nem nyúl az útvonalakhoz, ezért a közvetlenül rá épített beállításnak saját útvonalparancsokra van szüksége. Egy eszközhöz írt utasítások hibásnak tűnhetnek, ha a másikkal követi őket az ember. A sikeres ping is gyenge bizonyíték, mert egyetlen útvonalat próbál ki, nem minden szükséges alkalmazásútvonalat.

A DNS és az IPv6 külön döntés

Ellenőrizze az alagút által hirdetett DNS-kiszolgáló címét, és erősítse meg, hogy a választott előtagokon keresztül létezik útvonal ehhez a címhez. A feloldó beállítása nem teszi elérhetővé a feloldót, és az alagút szűkítése csendesen eltávolíthatja az oda vezető útvonalat. Az IPv6-ot is vizsgálja meg külön, mert a helyes IPv4-felosztás semmit sem mond arról az IPv6-alapértelmezett útvonalról, amely még mindig a fizikai kapcsolatra mutat. Három külön döntés változhat meg egyszerre, amikor egy partnerblokkot szerkeszt.

Ezután nyisson meg egy privát erőforrást és egy közönséges webhelyet egy ismert kiinduló konfigurációból. Ha az erőforrás válaszol, és a böngészés továbbra is a helyi kapcsolaton keresztül megy ki, az osztás azt teszi, amit kért. Ha a böngészés ugyanabban a pillanatban elromlik, az alagút elvitte az alapértelmezett útvonalat, és az előtaglista az a hely, ahol keresni kell.