Kas WireGuard klient ei jõua OpenVPN kliendini?

Mõlemad tunnelid ühenduvad, kumbki klient jõuab lüüsini, ja hetkel, mil üks proovib teise aadressi, kaovad paketid. Kummaski käepigistuses pole midagi valesti ja võtmete uuesti väljastamine ei muuda seda. Lüüs kannab tavalisi krüpteerimata IP-pakette kahe oma liidese vahel, seega ei pea protokollid kunagi teineteisest aru saama; vaja on kolme asja, mida ükski käepigistus ei anna. Sihtkoha katvus lähtekliendil, allika omandus lüüsil ja tagasitee kaugemal poolel. Sümptom on kõigil kolmel sama, mistõttu diagnoositakse neid koos.

Sümptomil puudub korraga üks osa

See lahendus kasutab WireGuardi basseini 10.71.0.0/24 liidesel wg1 ja OpenVPN-i basseini 10.72.0.0/24 liidesel tun1, mõlemad lõpevad ühel lüüsil. Testitav päring liigub aadressilt 10.71.0.5 HTTPS-ile aadressil 10.72.0.30. Iga allolev samm puudutab just seda üht voogu. Igal kontrollil on erinev tõrkeallkiri, kuigi kasutaja kogeb neid ühtemoodi, ja tavaliselt puudub korraga ainult üks kolmest.

Alustage kinnitusega, et mõlemad basseinid on tõesti sellel lüüsil ja et edastamine on sisse lülitatud nimeruumis, kus tunnelid elavad. Lüüs, mis lõpetab mõlemad protokollid erinevates nimeruumides, ei edasta nende vahel midagi, ja seda tasub välistada enne mis tahes partneri konfiguratsiooni lugemist.

Laiendage kodara sihtkoha katvust

WireGuardi kliendil peab olemasolev partneri kirje valima lüüsi OpenVPN-i sihtkoha jaoks, mis tähendab, et sihtkoha prefiks peab olema selle partneri lubatud loendis. Selle lisamine ei loo teist tunnelit; see muudab, millise partneri klient selle aadressi otsimisel valib, ja wg-quick korral järgib marsruut tavaliselt loendit automaatselt.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Jätke tegelikud võtme- ja lõpp-punkti read puutumata ning pidage meeles, et haldur, mis kasutab Table = off, ei võta sellest loendist üldse ühtegi marsruuti. Sel juhul peab sama prefiksi paigaldama süsteemi marsruutimistabelisse see, kellele see kuulub, ja puuduv marsruut seal näeb välja täpselt nagu puuduv lubatud prefiks.

Hoidke allika omandus lüüsil

Selle kliendi partneri kirje lüüsil peaks jätkuvalt omama täpselt selle kliendi allikaaadressi. Lubatud aadresse kontrollitakse mõlemas suunas: need valivad väljuva liikluse jaoks partneri ja kinnitavad, et sissetuleva paketi allikas kuulub sellele partnerile, kes selle saatis. OpenVPN-i basseini panemine kodara kirjesse, sest kodar tahab selleni jõuda, on viga, mis suunab liikluse vale osaleja poole.

AllowedIPs = 10.71.0.5/32

Lugege seda kirjet omandusavaldusena, mitte marsruutimise mugavusena. Kõik muu, kuhu klient peab jõudma, kuulub kliendi sihtkohtade loendisse, mitte lüüsi ettekujutusse sellest, mida see partner tohib saata.

Andke OpenVPN-i poolele tagasitee

Sihtkoht vajab nüüd teed tagasi WireGuardi allikani ja basseiniklientide jaoks saabub see tavaliselt OpenVPN-i serveri lükatud marsruudina. Lükake seda ainult klientidele, kellel see peaks olema, ja kinnitage kliendil, et see võeti vastu, selle asemel et eeldada direktiivi rakendumist.

push "route 10.71.0.0 255.255.255.0"

Marsruutide levitamine ei ole autoriseerimine. Kui sihtkoht asub teise OpenVPN-i kliendi taga, mitte basseinis, liituvad kavandiga selle kliendi enda LAN-i omandus ja edastamise nõuded, ja lükatud marsruut on vaid esimene pool. Sõnastage nõue graafina enne direktiivide lisamist: milline sõlm millele prefiksile kuulub ja milline sõlm sinna edastab.

Lubage täpselt see üks teenus, mida kavatsesite lubada

Kui edastamine on sees ja mõlemad basseinid marsruuditavad, jääb küsimus poliitikast. Kirjutage reegel konkreetse voolu jaoks, mitte liidese paari jaoks üldiselt, eelvaadake seda enne rakendamist ja hoidke olekut säilitavat tagasiteed, et vastuseid ei blokeeritaks uute ühendustena. Kuivkäivitus ei maksa midagi ja näitab täpselt, mida lisataks.

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

Need on edastatavad reeglid, eraldi lüüsi kuulamisreeglitest kahe VPN-teenuse jaoks. Väliste UDP-portide avamine ei autoriseeri sisemist päringut ja sisemise päringu autoriseerimine ei nõua piiramatut SSH-d lüüsile ega vaikimisi lubamist edastamisel. Ka sihtkoha enda tulemüür ja kuulamis-aadress peavad ühtima, sest loopbacki külge seotud teenus keeldub ka kõige hoolikamalt marsruuditud paketist. Poliitika, mis katab vestlusest ainult ühe suuna, ebaõnnestub tavaliselt õnnestunud päringu ja vaikiva vastusega, mis on kolmest tulemusest kõige segadusttekitavam.

Vastastikused marsruudid tähendavad tavaliselt, et allika tõlget pole vaja, mis säilitab WireGuardi aadressi sihtkohas ja teeb logid loetavaks. Ärge lisage täielikku maskeerimist sellepärast, et kaasatud on kaks protokolli, ja ärge eemaldage olemasolevat tõlkereeglit teadmata, mis sellest sõltub. Seejärel kontrollige üht voolu otsast lõpuni ja testige ka üht keelatud allikat või porti: mõlemal poolel töötav käepigistus ei tõesta ei ristmarsruuti ega isolatsiooni.