Nedostane sa klient WireGuard ku klientovi OpenVPN?

Oba tunely sa pripoja, každý klient dosiahne bránu a v okamihu, keď jeden skúsi adresu druhého, pakety zmiznú. Na žiadnom z dvoch podaní rúk nie je nič zlé a žiadne opätovné vydanie kľúčov to nezmení. Brána prenáša bežné nešifrované IP pakety medzi dvoma svojimi rozhraniami, takže protokoly nikdy nemusia rozumieť jeden druhému; potrebujú tri veci, ktoré žiadne podanie ruky neposkytuje. Pokrytie cieľa na východiskovom klientovi, vlastníctvo zdroja na bráne a spiatočná cesta na druhej strane. Príznak je pri všetkých troch rovnaký, a preto sa diagnostikujú spoločne.

Príznaku chýba vždy jedna časť

Tento návrh používa pool WireGuard 10.71.0.0/24 na wg1 a pool OpenVPN 10.72.0.0/24 na tun1, oba končia na jednej bráne. Testovaná požiadavka ide z 10.71.0.5 na HTTPS na 10.72.0.30. Každý krok nižšie sa týka tohto jedného toku. Každá kontrola má iný podpis zlyhania, aj keď ich používateľ prežíva rovnako, a zvyčajne chýba vždy len jedna z troch.

Začnite potvrdením, že oba pooly sú skutočne na tejto bráne a že preposielanie je zapnuté v namespace, kde tunely žijú. Brána, ktorá ukončuje oba protokoly v rôznych namespace, medzi nimi nič nepreposiela, a to sa oplatí vylúčiť pred čítaním akejkoľvek konfigurácie partnera.

Rozšírte pokrytie cieľa na lúči

Na klientovi WireGuard musí existujúci záznam partnera vybrať bránu pre cieľ OpenVPN, čo znamená, že prefix cieľa musí byť v zozname povolených tohto partnera. Jeho pridanie nevytvorí druhý tunel; mení, ktorého partnera klient vyberie pri hľadaní tejto adresy, a s wg-quick trasa zvyčajne zoznam sleduje automaticky.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Nechajte skutočné riadky kľúča a koncového bodu nedotknuté a pamätajte, že správca používajúci Table = off neberie z tohto zoznamu žiadnu trasu. V takom prípade musí ten istý prefix nainštalovať do systémovej smerovacej tabuľky ten, kto ho vlastní, a chýbajúca trasa tam vyzerá presne ako chýbajúci povolený prefix.

Zachovajte vlastníctvo zdroja na bráne

Záznam partnera tohto klienta na bráne má naďalej vlastniť presne zdrojovú adresu tohto klienta. Povolené adresy sa kontrolujú v oboch smeroch: vyberajú partnera pre odchádzajúcu prevádzku a overujú, že zdroj prichádzajúceho paketu patrí partnerovi, ktorý ho poslal. Umiestniť pool OpenVPN do záznamu lúča preto, že sa k nemu lúč chce dostať, je chyba, ktorá ženie prevádzku k nesprávnemu účastníkovi.

AllowedIPs = 10.71.0.5/32

Čítajte ten záznam ako vyhlásenie o vlastníctve a nie ako smerovaciu pohodlnosť. Všetko ostatné, kam sa klient musí dostať, patrí do zoznamu cieľov klienta, nie do predstavy brány o tom, čo tento partner smie posielať.

Dajte strane OpenVPN spiatočnú trasu

Cieľ teraz potrebuje trasu späť k zdroju WireGuard, a pri klientoch z poolu zvyčajne prichádza ako pretlačená trasa zo servera OpenVPN. Pretlačte ju len klientom, ktorí ju majú mať, a na klientovi potvrďte, že bola prijatá, namiesto predpokladu, že sa direktíva použila.

push "route 10.71.0.0 255.255.255.0"

Distribúcia trás nie je autorizácia. Keď cieľ stojí za iným klientom OpenVPN namiesto v poole, vlastníctvo vlastnej LAN tohto klienta a jeho požiadavky na preposielanie sa pridávajú do návrhu, a pretlačená trasa je len prvá polovica. Preformulujte požiadavku ako graf pred pridaním direktív: ktorý uzol vlastní ktorý prefix a ktorý uzol k nemu preposiela.

Povoľte len tú jednu službu, ktorú ste chceli povoliť

Keď je preposielanie zapnuté a oba pooly smerovateľné, zostáva otázka politiky. Napíšte pravidlo pre konkrétny tok, nie pre dvojicu rozhraní všeobecne, pred použitím ho zobrazte v náhľade a zachovajte stavovú spiatočnú cestu, aby odpovede neboli blokované ako nové spojenia. Skúšobný beh nič nestojí a ukáže presne, čo by sa pridalo.

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 sú pravidlá pre preposielanú prevádzku, oddelené od pravidiel počúvania brány pre obe služby VPN. Otvorenie vonkajších portov UDP neautorizuje vnútornú požiadavku a autorizácia vnútornej požiadavky nevyžaduje neobmedzené SSH k bráne ani predvolené povolenie preposielania. Vlastný firewall cieľa a jeho adresa počúvania sa tiež musia zhodovať, keďže služba viazaná na loopback odmietne aj ten najstarostlivejšie smerovaný paket. Politika pokrývajúca len jeden smer rozhovoru zvyčajne zlyhá úspešnou požiadavkou a tichou odpoveďou, čo je z troch výsledkov ten najzavádzajúcejší.

Vzájomné trasy zvyčajne znamenajú, že preklad zdroja nie je potrebný, čo zachová adresu WireGuard na cieli a robí logy čitateľnými. Nepridávajte plošný masquerading preto, že sú zapojené dva protokoly, a neodstraňujte existujúce pravidlo prekladu bez toho, aby ste vedeli, čo na ňom závisí. Potom overte jediný tok od začiatku do konca a otestujte aj jeden zakázaný zdroj alebo port: fungujúce podanie ruky na každej strane nedokazuje ani kríženú trasu, ani izoláciu.