Nem éri el a WireGuard-kliens az OpenVPN-klienst?

Mindkét alagút csatlakozik, minden kliens eléri az átjárót, és abban a pillanatban, amikor az egyik a másik címét próbálja, a csomagok eltűnnek. Egyik kézfogásban sincs semmi hiba, és a kulcsok újbóli kiadása sem változtat ezen. Az átjáró közönséges titkosítatlan IP-csomagokat továbbít a saját két interfésze között, tehát a protokolloknak soha nem kell megérteniük egymást; három dologra van szükségük, amit egyetlen kézfogás sem ad meg. Céllefedettség a forrás-kliensen, forrás-tulajdonjog az átjárón és visszaút a túlsó oldalon. A tünet mindhárom esetben ugyanaz, ezért együtt diagnosztizálják őket.

A tünetből egyszerre mindig egy darab hiányzik

Ez a kialakítás egy WireGuard-gyűjtőt használ 10.71.0.0/24 címtartománnyal a wg1 interfészen és egy OpenVPN-gyűjtőt 10.72.0.0/24 címtartománnyal a tun1 interfészen, mindkettő egy átjárón végződik. A tesztelt kérés 10.71.0.5 címről megy HTTPS-re a 10.72.0.30 címen. Az alábbi minden lépés erről az egyetlen folyamról szól. Minden ellenőrzésnek más a hibajellegzetessége, pedig a felhasználó ugyanúgy éli meg őket, és általában egyszerre csak egy hiányzik a háromból.

Kezdje annak ellenőrzésével, hogy mindkét gyűjtő valóban ezen az átjárón van, és hogy a továbbítás engedélyezett abban a névtérben, ahol az alagutak élnek. Az az átjáró, amely mindkét protokollt külön névtérben fejezi be, semmit nem továbbít közöttük, és ezt érdemes kizárni, mielőtt bármilyen partnerkonfigurációt elolvas.

Bővítse a küllő céllefedettségét

A WireGuard-kliensen a meglévő partnerbejegyzésnek kell kiválasztania az átjárót az OpenVPN-célhoz, ami azt jelenti, hogy a célprefixumnak szerepelnie kell abban az engedélyezett listában. Hozzáadása nem hoz létre második alagutat; azt változtatja meg, melyik partnert választja a kliens, amikor ezt a címet keresi, és wg-quick esetén az útvonal általában automatikusan követi a listát.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Hagyja érintetlenül a valódi kulcs- és végpontsorokat, és ne feledje, hogy a Table = off beállítást használó kezelő egyáltalán nem vesz útvonalat ebből a listából. Ebben az esetben ugyanazt a prefixumot a rendszer útvonaltáblájába annak kell telepítenie, aki birtokolja, és az ott hiányzó útvonal pontosan úgy néz ki, mint egy hiányzó engedélyezett prefixum.

Tartsa meg a forrás tulajdonjogát az átjárón

Ennek a kliensnek a partnerbejegyzése az átjárón továbbra is pontosan ennek a kliensnek a forráscímét birtokolja. Az engedélyezett címeket mindkét irányban ellenőrzi a rendszer: partnert választanak a kimenő forgalomhoz, és igazolják, hogy a bejövő csomag forrása ahhoz a partnerhez tartozik, amelyik elküldte. Az OpenVPN-gyűjtő beírása a küllő bejegyzésébe azért, mert a küllő el akarja érni, az a hiba, amely a forgalmat a rossz résztvevő felé tereli.

AllowedIPs = 10.71.0.5/32

Ezt a bejegyzést tulajdonjogi nyilatkozatként olvassa, nem útvonalazási kényelemként. Minden más, amit a kliensnek el kell érnie, a kliens céljainak listájába tartozik, nem abba, ahogy az átjáró elképzeli, mit küldhet ez a partner.

Adjon az OpenVPN-oldalnak visszautat

A célnak most visszaútra van szüksége a WireGuard-forráshoz, és gyűjtős klienseknél ez általában az OpenVPN-kiszolgálóról tolt útvonalként érkezik. Csak azoknak a klienseknek tolja, amelyeknek rendelkezniük kell vele, és a kliensen erősítse meg, hogy elfogadta, ahelyett hogy feltételezné az utasítás érvényesülését.

push "route 10.71.0.0 255.255.255.0"

Az útvonalak terjesztése nem felhatalmazás. Amikor a cél nem a gyűjtőben, hanem egy másik OpenVPN-kliens mögött van, akkor annak a kliensnek a saját LAN-tulajdonjoga és továbbítási követelményei is bekerülnek a tervbe, és a tolt útvonal csak az első fele. Fogalmazza újra a követelményt gráfként, mielőtt utasításokat ad hozzá: melyik csomópont melyik prefixumot birtokolja, és melyik csomópont továbbít felé.

Csak azt az egy szolgáltatást engedélyezze, amelyet engedélyezni akart

Ha a továbbítás be van kapcsolva és mindkét gyűjtő útvonalazható, a fennmaradó kérdés a szabályzat. A szabályt a konkrét folyamra írja meg, ne az interfészpárra általában, alkalmazás előtt nézze meg előnézetben, és tartsa meg az állapotkövető visszautat, hogy a válaszok ne blokkolódjanak új kapcsolatként. A próbafuttatás semmibe nem kerül, és pontosan megmutatja, mi kerülne hozzáadásra.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Ezek továbbított forgalomra vonatkozó szabályok, elkülönülve az átjáró két VPN-szolgáltatáshoz tartozó figyelési szabályaitól. A külső UDP-portok megnyitása nem jogosítja fel a belső kérést, a belső kérés feljogosítása pedig nem igényel korlátlan SSH-t az átjáróhoz vagy alapértelmezett engedélyezést a továbbításnál. A cél saját tűzfala és figyelési címe is összhangban kell legyen, mivel a loopbackhez kötött szolgáltatás a leggondosabban útvonalazott csomagot is elutasítja. Az a szabályzat, amely a beszélgetésnek csak az egyik irányát fedi le, általában sikeres kéréssel és néma válasszal vall kudarcot, ami a három kimenetel közül a legzavaróbb.

A kölcsönös útvonalak általában azt jelentik, hogy nincs szükség forrásfordításra, ami megőrzi a WireGuard-címet a célnál, és olvashatóvá teszi a naplókat. Ne adjon hozzá átfogó masqueradingot csak azért, mert két protokoll érintett, és ne távolítson el meglévő fordítási szabályt anélkül, hogy tudná, mi függ tőle. Ezután ellenőrizze az egyetlen folyamatot végponttól végpontig, és teszteljen egy tiltott forrást vagy portot is: az mindkét oldalon működő kézfogás sem a keresztútvonalat, sem az elkülönítést nem bizonyítja.