Ar WireGuard klientas nepasiekia OpenVPN kliento?

Abu tuneliai prisijungia, kiekvienas klientas pasiekia tinklų sietuvą, ir tą akimirką, kai vienas bando kito adresą, paketai dingsta. Nė viename iš dviejų rankos paspaudimų nėra nieko blogo, ir joks raktų perleidimas to nepakeis. Sietuvas perduoda įprastus neužšifruotus IP paketus tarp dviejų savo sąsajų, todėl protokolams niekada nereikia vienas kito suprasti; jiems reikia trijų dalykų, kurių joks rankos paspaudimas nesuteikia. Paskirties aprėptis pradiniame kliente, šaltinio nuosavybė sietuve ir grįžimo kelias kitoje pusėje. Simptomas visiems trims vienodas, todėl jie diagnozuojami kartu.

Simptomui vis trūksta vienos dalies

Ši konstrukcija naudoja WireGuard baseiną 10.71.0.0/24 sąsajoje wg1 ir OpenVPN baseiną 10.72.0.0/24 sąsajoje tun1, abu baigiasi viename sietuvo. Bandomoji užklausa eina iš 10.71.0.5 į HTTPS adresu 10.72.0.30. Kiekvienas žingsnis žemiau yra apie tą vieną srautą. Kiekviena patikra turi skirtingą gedimo parašą, nors naudotojas juos patiria vienodai, ir paprastai vienu metu trūksta tik vieno iš trijų.

Pradėkite patvirtindami, kad abu baseinai tikrai yra šiame sietuve ir kad perdavimas įjungtas vardų erdvėje, kurioje gyvena tuneliai. Sietuvas, kuris abu protokolus užbaigia skirtingose vardų erdvėse, nieko tarp jų neperduoda, ir tai verta atmesti prieš skaitant bet kokią partnerio konfigūraciją.

Išplėskite mentės paskirties aprėptį

WireGuard kliente esamas partnerio įrašas turi pasirinkti sietuvą OpenVPN paskirčiai, o tai reiškia, kad paskirties priešdėlis turi būti to partnerio leidžiamų sąraše. Jo pridėjimas nesukuria antro tunelio; jis pakeičia, kurį partnerį klientas pasirenka ieškodamas to adreso, o su wg-quick maršrutas paprastai sąrašą seka automatiškai.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Palikite tikrąsias rakto ir galinio taško eilutes nepaliestas ir atminkite, kad valdyklė, naudojanti Table = off, iš šio sąrašo visiškai neima jokio maršruto. Tokiu atveju tą patį priešdėlį į sistemos maršrutų lentelę turi įrašyti tas, kas jį valdo, o ten trūkstamas maršrutas atrodo lygiai kaip trūkstamas leidžiamas priešdėlis.

Išsaugokite šaltinio nuosavybę sietuve

Šio kliento partnerio įrašas sietuve turi ir toliau valdyti būtent to kliento šaltinio adresą. Leidžiami adresai tikrinami abiem kryptimis: jie parenka partnerį išeinančiam srautui ir patvirtina, kad įeinančio paketo šaltinis priklauso jį siuntusiam partneriui. OpenVPN baseino įrašymas į mentės įrašą todėl, kad mentė nori jį pasiekti, yra ta klaida, kuri nukreipia srautą pas netinkamą dalyvį.

AllowedIPs = 10.71.0.5/32

Skaitykite tą įrašą kaip nuosavybės deklaraciją, o ne kaip maršrutizavimo patogumą. Visa kita, ką klientas turi pasiekti, priklauso kliento paskirčių sąrašui, o ne sietuvo įsivaizdavimui, ką šis partneris gali siųsti.

Suteikite OpenVPN pusei grįžimo maršrutą

Paskirčiai dabar reikia maršruto atgal į WireGuard šaltinį, o baseino klientams jis paprastai atkeliauja kaip stumiamas maršrutas iš OpenVPN serverio. Stumkite jį tik tiems klientams, kurie turi jį turėti, ir kliente patvirtinkite, kad jis priimtas, o ne manykite, kad direktyva pritaikyta.

push "route 10.71.0.0 255.255.255.0"

Maršrutų platinimas nėra įgaliojimas. Kai paskirtis yra už kito OpenVPN kliento, o ne baseine, to kliento pačios LAN nuosavybė ir perdavimo reikalavimai prisijungia prie konstrukcijos, o stumiamas maršrutas tėra pirmoji pusė. Perrašykite reikalavimą kaip grafą prieš pridėdami direktyvas: kuris mazgas valdo kurį priešdėlį ir kuris mazgas perduoda link jo.

Leiskite tik tą vieną paslaugą, kurią ketinote leisti

Kai perdavimas įjungtas ir abu baseinai maršrutizuojami, lieka politikos klausimas. Rašykite taisyklę konkrečiam srautui, o ne sąsajų porai apskritai, peržiūrėkite ją prieš taikydami ir išlaikykite būseną palaikantį grįžimo kelią, kad atsakymai nebūtų blokuojami kaip nauji ryšiai. Bandomasis paleidimas nieko nekainuoja ir parodo, kas būtų pridėta.

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

Tai perduodamo srauto taisyklės, atskiros nuo sietuvo dviejų VPN paslaugų klausymo taisyklių. Išorinių UDP prievadų atidarymas neįgalioja vidinės užklausos, o vidinės užklausos įgaliojimas nereikalauja neriboto SSH į sietuvą ar numatytojo leidimo perduodant. Paskirties ugniasienė ir klausymo adresas taip pat turi sutapti, nes prie loopback pririšta paslauga atmeta net kruopščiausiai maršrutizuotą paketą. Politika, kuri apima tik vieną pokalbio kryptį, paprastai žlunga sėkminga užklausa ir tyliu atsakymu, o tai yra painiausias iš trijų rezultatų.

Abipusiai maršrutai paprastai reiškia, kad šaltinio vertimo nereikia, o tai išsaugo WireGuard adresą paskirtyje ir daro žurnalus įskaitomus. Nepridėkite visuotinio masquerading vien todėl, kad dalyvauja du protokolai, ir nepašalinkite esamos vertimo taisyklės nežinodami, kas nuo jos priklauso. Tada patikrinkite tą vieną srautą nuo pradžios iki galo ir išbandykite vieną draudžiamą šaltinį ar prievadą: veikiantis rankos paspaudimas abiejose pusėse neįrodo nei kryžminio maršruto, nei izoliacijos.