Klient WireGuard se nedostane ke klientovi OpenVPN?

Oba tunely se připojí, každý klient dosáhne na bránu a ve chvíli, kdy jeden zkusí adresu druhého, pakety zmizí. Na žádném z handshakeů není nic špatně a žádné nové vydání klíčů to nezmění. Brána přenáší běžné nešifrované IP pakety mezi dvěma svými rozhraními, takže protokoly nikdy nemusí rozumět jeden druhému; potřebují tři věci, které žádný handshake neposkytuje. Pokrytí cíle na výchozím klientu, vlastnictví zdroje na bráně a zpáteční cestu na protější straně. Příznak je u všech tří stejný, a proto se diagnostikují společně.

Příznaku chybí vždy jeden kus

Tento návrh používá pool WireGuard 10.71.0.0/24 na wg1 a pool OpenVPN 10.72.0.0/24 na tun1, oba končící na jedné bráně. Testovaný požadavek jde z 10.71.0.5 na HTTPS na 10.72.0.30. Každý krok níže se týká tohoto jednoho toku. Každá kontrola má jiný podpis selhání, i když je uživatel prožívá stejně, a obvykle chybí vždy jen jedna ze tří.

Začněte potvrzením, že oba pooly jsou opravdu na této bráně a že přeposílání je zapnuté v namespace, kde tunely žijí. Brána, která ukončuje oba protokoly v různých namespacech, mezi nimi nic nepřeposílá, a to stojí za to vyloučit dřív, než přečtete jakoukoli konfiguraci protějšku.

Rozšiřte pokrytí cíle na paprsku

Na klientu WireGuard musí stávající záznam protějšku vybrat bránu pro cíl OpenVPN, což znamená, že prefix cíle musí být v seznamu povolených tohoto protějšku. Jeho přidání nevytvoří druhý tunel; mění, kterého protějšku se klient při hledání této adresy drží, a s wg-quick trasa obvykle seznamu následuje automaticky.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Ponechte skutečné řádky klíče a koncového bodu nedotčené a pamatujte, že správce používající Table = off nebere z tohoto seznamu žádnou trasu. V takovém případě musí stejný prefix nainstalovat do systémové routovací tabulky ten, kdo ho vlastní, a chybějící trasa tam vypadá přesně jako chybějící povolený prefix.

Zachovejte vlastnictví zdroje na bráně

Záznam protějšku tohoto klienta na bráně má nadále vlastnit přesně zdrojovou adresu tohoto klienta. Povolené adresy se kontrolují v obou směrech: vybírají protějšek pro odchozí provoz a ověřují, že zdroj příchozího paketu patří protějšku, který ho poslal. Dát pool OpenVPN do záznamu paprsku proto, že se k němu paprsek chce dostat, je chyba, která žene provoz ke špatnému účastníkovi.

AllowedIPs = 10.71.0.5/32

Čtěte tento záznam jako prohlášení o vlastnictví, ne jako routovací pohodlí. Všechno ostatní, k čemu klient potřebuje dosáhnout, patří do seznamu cílů klienta, ne do představy brány o tom, co tento protějšek smí posílat.

Dejte straně OpenVPN zpáteční trasu

Cíl teď potřebuje trasu zpět ke zdroji WireGuard, a u klientů z poolu obvykle přichází jako protlačená trasa ze serveru OpenVPN. Protlačte ji jen klientům, kteří ji mají mít, a na klientu potvrďte, že byla přijata, místo abyste předpokládali, že se direktiva použila.

push "route 10.71.0.0 255.255.255.0"

Distribuce tras není autorizace. Když cíl stojí za jiným klientem OpenVPN místo v poolu, vlastnictví vlastní LAN toho klienta a jeho požadavky na přeposílání se přidávají do návrhu, a protlačená trasa je jen první polovina. Přeformulujte požadavek jako graf dřív, než přidáte direktivy: který uzel vlastní který prefix a který uzel k němu přeposílá.

Povolte jen tu jednu službu, kterou jste chtěli povolit

Když je přeposílání zapnuté a oba pooly routovatelné, zbývá otázka politiky. Napište pravidlo pro konkrétní tok, ne pro dvojici rozhraní obecně, před použitím ho zobrazte v náhledu a zachovejte stavovou zpáteční cestu, aby odpovědi nebyly blokovány jako nová spojení. Zkušební běh nic nestojí a ukáže přesně, co by se přidalo.

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

Toto jsou pravidla pro přeposílaný provoz, odlišná od naslouchacích pravidel brány pro obě služby VPN. Otevření vnějších portů UDP neautorizuje vnitřní požadavek a autorizace vnitřního požadavku nevyžaduje neomezené SSH k bráně ani výchozí povolení přeposílání. Vlastní firewall cíle a naslouchací adresa se také musí shodovat, protože služba vázaná na loopback odmítne i ten nejpečlivěji routovaný paket. Politika pokrývající jen jeden směr konverzace obvykle selže úspěšným požadavkem a tichou odpovědí, což je ze tří výsledků ten nejmatoucnější.

Vzájemné trasy obvykle znamenají, že překlad zdroje není potřeba, což zachová adresu WireGuard na cíli a dělá logy čitelné. Nepřidávejte plošný masquerading proto, že jsou zapojeny dva protokoly, a neodstraňujte existující pravidlo překladu, aniž byste věděli, co na něm závisí. Pak ověřte jediný tok od začátku do konce a otestujte i jeden zakázaný zdroj nebo port: fungující handshake na každé straně nedokazuje ani kříženou trasu, ani izolaci.