Akadályozza meg, hogy a VPN-kliensek elérjék egymást az alagúton

Két kliens kinyithatja mindkettő az ugró gazdagépet, és mégsem lehet semmi dolguk egymás megnyitásával. Egy szolgáltatás elérése továbbítási döntés, míg egy társ elérése szabályzati döntés, és a legtöbb VPN-verem külön objektumokban tartja ezeket. Semmi, amit az elsőhöz beállít, nem érvényesíti a másodikat. A feladat tehát nem szabály hozzáadása, hanem annak az objektumnak a megtalálása, amely ezen a kiszolgálón a társak forgalmáról dönt, a tiltás odaírása és a kliensből való bizonyítása.

A megosztott szolgáltatáshoz vezető útvonal nem engedély a társak között

A kliens alhálózat hirdetése megmondja egy társnak, hogyan tegyen csomagot a vezetékre egy másik kliens címe felé. Hogy azt a csomagot kézbesítik-e, később dől el, azáltal, ami továbbítja. Linux átjárón ez a FORWARD lánc; felhasználói térben futó démonban az alagút saját munkamenet-táblázata. Az útvonal az elérhetőségre válaszol, és az engedélyt érintetlenül hagyja.

Ezért a csak útvonalakat olvasó elkülönítési ellenőrzés semmit nem bizonyít. Egy /24 minden kliensnek kiküldhető, miközben minden társak közötti csomag a továbbítási horognál eldobódik. A veszélyes eset a fordított: nincs kifejezett szabály, megengedő alapértelmezés, és olyan elkülönítés, amely csak azért létezik, mert senki nem tesztelte.

Írja le a követelményt egy sorban, mielőtt terminált nyit. Érje el a szolgáltatásblokkot és az ugró gazdagépet, a kliensblokkon belül semmi mást ne érjen el.

Derítse ki, ki továbbítja valójában a társ csomagját

Két kiszolgálóviselkedés ugyanúgy néz ki a kliens oldaláról, és különböző szabályokat igényel. Vagy a kernel újra kiküldi a csomagot az alagút interfészén, vagy a démon munkamenetek között másolja, és a kernel soha nem látja.

A WireGuard az első csoportba tartozik: nincs társak közötti kapcsolója, ezért a 10.8.0.4-től 10.8.0.5-re menő csomag megérkezik a wg0-ra, eltalálja a továbbítási horgot, és újra kifelé irányul a wg0-n, amikor az AllowedIPs mindkét címet lefedi. Az OpenVPN a második csoport, amint a kiszolgáló konfigurációjában be van állítva a client-to-client, mert ez az utasítás a felhasználói térben adja át a csomagot a munkamenetek között. Bármit ír, előbb ellenőrizze a betöltött konfigurációban ezt az utasítást. Az a kernel-szabály, amely soha nem lát forgalmat, nem különböztethető meg egy működő szabálytól, és így végződik egy telepítés minden elkülönítés nélkül.

Az érvényes konfigurációt olvassa, ne azt a fájlt, amelyről feltételezi, hogy be van töltve, mert a disztribúciós csomagok saját beszúrásaikat hozzák. Ha a démon továbbít, a tiltás az ő saját kliensenkénti vezérlőibe tartozik, és a gazdagép tűzfala csak a gazdagéphez címzett forgalmat szűri. Ha a kernel továbbít, a továbbítási horog az egyetlen hely, amely számít.

Az irányított és lefordított telepítések még egy ellenőrzést igényelnek: lehet, hogy a távoli kliens által látott forrás nem az, amelyre számít. Akkor a kliens alhálózathoz illeszkedő szabály semmihez sem illeszkedik. Jegyezze fel a fordítást túlélő címet, mielőtt megírja az egyezést, és inkább az interfészpárt illessze, mint hogy NAT-címeket találgasson.

Adjon minden címnek önállóan visszavonható identitást

Az elkülönítés akkor omlik össze, amikor két eszköz egy hitelesítő adatot oszt meg. Az ehhez az identitáshoz kötött szabály nem tudja szétválasztani őket, és egy elveszett laptop visszavonása az egész csoportot visszavonja. Eszközönkénti tanúsítványok vagy társankénti kulcsok helyben tartják a visszavonást és olvashatóvá teszik a szabályzatot, mert minden cím pontosan egy személyhez vagy géphez rendelődik. Ahol a tervezés ezt nem tudja, mondja ki az üzemeltetési útmutatóban, ahelyett hogy finom szemcséjűnek írná le a szabályt.

A címkiosztásnak egyeznie kell a szabályzattal. Foglaljon le egy blokkot a szolgáltatásoknak, egyet a klienseknek, és a klienscímeket egy Ön által vezérelt készletből ossza, ne az elsőként jövő tartományából. Ha a kiszolgáló fordít vagy hidat képez, tartsa a leképezési táblázatot a konfiguráció mellett, mert a következő olvasónak erre a táblázatra van szüksége a szabály újravezetéséhez.

A tiltást oda tegye, ahol a csomag átlépi az alagutat

Egy WireGuard-forgalmat továbbító átjárón két szabály fedi le az esetet: engedélyezze a szolgáltatásblokkot, majd dobja el a kliensblokk többi részét. Az interfészpár ugyanolyan fontos, mint a címek, mert a csak célra illeszkedő egyezés a LAN felől érkező forgalmat is elkapja. Ebben a sorrendben töltse be őket, hogy az engedély értékelődjön először.

Az nftables esetében a pár egy meglévő inet filter táblába kerül, először az engedély, aztán az eldobás. Mindkét egyezés rögzíti az interfészpárt és a címeket is.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Betöltés után olvassa vissza a láncot, ahelyett hogy a kilépési állapotban bízna, és erősítse meg, hogy mindkét szabály a szándékolt sorrendben áll. Adjon hozzá illeszkedő ip6 szabályokat az IPv6-készlethez, különben a v4 pár csak dísz egy kettős veremű alagúton. Ha a kiszolgálónak már van megengedő továbbítási szabályzata, fűzze hozzá az eldobást, ahelyett hogy a láncot teljesen lecserélné.

Amikor a client-to-client be van kapcsolva az OpenVPN-en, ezek a továbbítási szabályok soha nem illeszkednek a társak forgalmára, és a tiltásnak a démon saját vezérlőiben kell élnie. Tartsa meg a kernel-szabályokat a gazdagéphez címzett forgalomra, de ne számolja őket az elkülönítés vezérlőjeként.

Bizonyítsa a tiltást kliensből, ne a kiszolgálóból

Az átjáróból végzett tesztelés semmit nem bizonyít, mert a helyben előállított forgalom a kimeneti útvonalat veszi, és soha nem lépi át a továbbítási horgot. Használjon két valódi klienst: egyet, amelynek el kell érnie a szolgáltatást, és egyet, amelyet el kell utasítani. Először az engedélyezett esetet futtassa, hogy egy törött alagutat ne nézzenek működő szabályzatnak.

Az engedélyezett kliensből erősítse meg, hogy a szolgáltatás válaszol a portján. Ugyanabból a kliensből próbálja a társ címét, és csendes eldobást várjon elutasítás helyett:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Az eldobott csomag és az offline társ egyaránt időtúllépésnek látszik, ezért nézze meg a számlálókat, mielőtt bármit megállapít. Erősítse meg, hogy az eldobási szabály számlálója nő, miközben a társ bizonyíthatóan él. Ismételje meg IPv6-on, ahol a hiányzó ip6 szabály hatékonynak láttatja a v4 tiltást. Jegyezze fel az elfogadott és elutasított eredményeket a dátumozott üzemeltetési útmutatóban, mert a következő migráció újra levezeti a szabályt.