WireGuard osztott alagút: beállítás alapértelmezett útvonal nélkül

Az osztott alagutat az határozza meg, amit kihagy, és a WireGuard ezt a döntést egyetlen mezőben hozza meg. Az ügyfél peer AllowedIPs mezője egyszerre választja ki, mely célok mennek át az alagúton, és szűri, mely belső forráscímek fogadhatók el, a wg-quick pedig ugyanezt a listát hosztútvonalakká alakítja. Ha a lista rossz, az alagút vagy mindent elnyel, vagy semmit sem visz.

Először határozza meg a prefixlistát

Írja fel azokat a célokat, amelyeknek az alagutat kell használniuk, mielőtt hozzányúlna egy konfigurációs fájlhoz. Irodai alhálózatok, adatbázis-tartomány, felügyeleti hálózat: mindegyik egy-egy indokkal bíró prefix. Minden, ami nincs a listán, a fizikai útvonalon marad, és a tervezés egész értelme ez.

Ha a lista 0.0.0.0/0 vagy ::/0 elemet tartalmaz, teljes alagutat épített, és ezt meg kellene mondania, mert a hibaformák és a DNS-elvárások eltérnek.

Tartsa a listát elég rövidnek ahhoz, hogy egy ellenőr később összevethesse az útválasztási táblával.

Ügyfél-konfiguráció: peer, AllowedIPs, DNS

Az ügyfél interfészblokkja a saját alagútcímét és privát kulcsát tartalmazza. A peer blokk a kiszolgáló nyilvános kulcsát, a végpontot és az első lépés prefixeit tartalmazza:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

Az ügyfélen az AllowedIPs a távoli célok halmaza, nem az ügyfél saját címe. A DNS-sor csak a wg-quick feloldóintegrációján keresztül hat, ezért a resolvconf vagy systemd-resolved támogatása nélküli hoszt figyelmen kívül hagyja. A PersistentKeepalive életben tart egy NAT-leképezést, és közvetlen útvonalon felesleges.

Kommentálja az egyes prefixeket azzal a szolgáltatással, amelyet kiszolgál, különben a következő módosítás találgatás lesz.

Kiszolgáló-konfiguráció: az ellenkező nézőpont

A kiszolgálón a peer bejegyzés az ügyfelet képviseli, ezért AllowedIPs mezője az ügyfél alagútcíme, általában /32. Ez nem az irodai alhálózat. Az ügyfél listájának átmásolása a kiszolgáló bejegyzésébe az osztott alagút leggyakoribb hibája, és vagy kiszélesíti a hozzáférést, vagy elrontja a belső forrásellenőrzést a kézfogáskor.

A kiszolgáló saját interfészcíme és az iroda felé szükséges útvonalai minden peer bejegyzéstől külön állnak.

Két fájl, két nézőpont, egy prefixkészlet megosztva köztük.

Hozza fel, és olvassa ki az útvonalakat

Indítsa el az interfészt a támogatott kezelővel, majd nézze meg, mit telepített, ne azt, mit szándékozott. A wg-quick az AllowedIPs-ből vezeti le az útvonalakat; ha a profil Table = off értéket állít be, semmi sem települ, és az útválasztás az Ön feladata. Olvassa ki minden prefix útvonalát, és erősítse meg, hogy a WireGuard interfészre mutat. Az üres útvonallista általában azt jelenti, hogy az alkalmazott profil nem az, amelyet szerkesztett.

Ellenőrizze a kézfogásszámlálókat is, mert a kézfogás nélküli peer kulcs-, végpont- vagy elérhetőségi problémával küzd, nem útválasztásival.

Írja le a pontos parancsot, amelyet használt, mert a következő ember nyomás alatt fogja futtatni.

Ellenőrizze mindkét oldalt, majd jegyezze fel a visszaállítást

Teszteljen egy privát címet, annak belső nevét és egy célt, amelynek közvetlennek kell maradnia. Ha a privát cím működik, és a közvetlen cél most az alagúton keresztül távozik, a prefixlista túl széles. Ha a név meghiúsul, miközben a cím működik, a DNS-sor nem lépett életbe. A visszaállítás egyetlen parancs, és ugyanabba a jegyzetbe tartozik.

Újracsatlakozás után erősítse meg, hogy az útvonalak még ott vannak, mert a profilt újra alkalmazó kezelő lecserélheti a kézi útvonalakat.

Tartson egyetlen konfigurációs gazdát, mert két kezelő, amely ugyanazt az interfészt állítja elő, előbb-utóbb ellentmondásba kerül. A wg-quick kézikönyv dokumentálja az általa nyújtott útvonal- és DNS-viselkedést.