Eikö WireGuard-asiakas tavoita OpenVPN-asiakasta?

Molemmat tunnelit yhdistyvät, kumpikin asiakas tavoittaa yhdyskäytävän, ja heti kun toinen yrittää toisen osoitetta, paketit katoavat. Kummassakaan kättelyssä ei ole mitään vialla, eikä avainten uudelleenmyöntäminen muuta sitä. Yhdyskäytävä välittää tavallisia salaamattomia IP-paketteja kahden oman rajapintansa välillä, joten protokollien ei koskaan tarvitse ymmärtää toisiaan; ne tarvitsevat kolme asiaa, joita mikään kättely ei tarjoa. Kohdepeitto lähtevällä asiakkaalla, lähteen omistus yhdyskäytävällä ja paluupolku kaukana olevalla puolella. Oire on sama kaikilla kolmella, minkä vuoksi ne diagnosoidaan yhdessä.

Oireesta puuttuu yksi osa kerrallaan

Tämä ratkaisu käyttää WireGuard-aluetta 10.71.0.0/24 rajapinnalla wg1 ja OpenVPN-aluetta 10.72.0.0/24 rajapinnalla tun1, ja molemmat päättyvät yhdelle yhdyskäytävälle. Testattava pyyntö kulkee osoitteesta 10.71.0.5 HTTPS-palveluun osoitteessa 10.72.0.30. Jokainen alla oleva vaihe koskee juuri tätä yhtä virtaa. Jokaisella tarkistuksella on erilainen vikakirjoitus, vaikka käyttäjä kokee ne samoin, ja yleensä kerrallaan puuttuu vain yksi kolmesta.

Aloita vahvistamalla, että molemmat alueet ovat todella tällä yhdyskäytävällä ja että edelleenlähetys on käytössä nimiavaruudessa, jossa tunnelit elävät. Yhdyskäytävä, joka päättää molemmat protokollat eri nimiavaruuksissa, ei välitä niiden välillä mitään, ja se kannattaa sulkea pois ennen kuin lukee yhtäkään vertaiskonfiguraatiota.

Laajenna puolan kohdepeittoa

WireGuard-asiakkaassa olevan vertaismerkinnän on valittava yhdyskäytävä OpenVPN-kohteelle, eli kohdeprefiksin on oltava kyseisen vertaisen sallitussa luettelossa. Sen lisääminen ei luo toista tunnelia; se muuttaa, minkä vertaisen asiakas valitsee etsiessään tuota osoitetta, ja wg-quick-työkalulla reitti seuraa luetteloa yleensä automaattisesti.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Jätä varsinaiset avain- ja päätepisterivit koskemattomiksi ja muista, että Table = off-asetusta käyttävä hallinta ei ota tästä luettelosta lainkaan reittiä. Siinä tapauksessa sama prefiksi on asennettava järjestelmän reititystauluun sen omistajan toimesta, ja puuttuva reitti näyttää siellä täsmälleen samalta kuin puuttuva sallittu prefiksi.

Pidä lähteen omistus yhdyskäytävällä

Tämän asiakkaan vertaismerkinnän yhdyskäytävällä tulee edelleen omistaa täsmälleen kyseisen asiakkaan lähdeosoite. Sallitut osoitteet tarkistetaan molempiin suuntiin: ne valitsevat vertaisen lähtevälle liikenteelle ja vahvistavat, että saapuvan paketin lähde kuuluu sille vertaiselle, joka sen lähetti. OpenVPN-alueen laittaminen puolan merkintään siksi, että puola haluaa tavoittaa sen, on se virhe, joka ohjaa liikenteen väärälle osapuolelle.

AllowedIPs = 10.71.0.5/32

Lue tämä merkintä omistuslausumana, ei reitityksen mukavuutena. Kaikki muu, mihin asiakkaan on päästävä, kuuluu asiakkaan kohdeluetteloon, ei yhdyskäytävän käsitykseen siitä, mitä tämä vertainen saa lähettää.

Anna OpenVPN-puolelle paluureitti

Kohde tarvitsee nyt reitin takaisin WireGuard-lähteeseen, ja alueen asiakkaille se saapuu yleensä OpenVPN-palvelimelta työnnettynä reittinä. Työnnä se vain asiakkaille, joilla se pitäisi olla, ja vahvista asiakkaassa, että se hyväksyttiin, sen sijaan että olettaisit direktiivin tulleen käyttöön.

push "route 10.71.0.0 255.255.255.0"

Reittien jakelu ei ole valtuuttamista. Kun kohde on alueen sijaan toisen OpenVPN-asiakkaan takana, kyseisen asiakkaan oma LAN-omistus ja edelleenlähetysvaatimukset liittyvät suunnitelmaan, ja työnnetty reitti on vain ensimmäinen puolisko. Muotoile vaatimus graafina ennen direktiivien lisäämistä: mikä solmu omistaa minkä prefiksin ja mikä solmu välittää sitä kohti.

Salli juuri se yksi palvelu, jonka aioit sallia

Kun edelleenlähetys on käytössä ja molemmat alueet ovat reititettäviä, jäljelle jää kysymys käytännöstä. Kirjoita sääntö yksittäiselle virralle eikä rajapintaparille yleisesti, esikatsele se ennen käyttöönottoa ja pidä tilallinen paluupolku, jotta vastauksia ei estetä uusina yhteyksinä. Kuivaharjoittelu ei maksa mitään ja näyttää täsmälleen, mitä lisättäisiin.

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

Nämä ovat edelleenlähetetyn liikenteen sääntöjä, erillään yhdyskäytävän kahden VPN-palvelun kuuntelusäännöistä. Ulompien UDP-porttien avaaminen ei valtuuta sisempää pyyntöä, eikä sisemmän pyynnön valtuuttaminen vaadi rajoittamatonta SSH-yhteyttä yhdyskäytävälle tai oletusarvoista sallintaa edelleenlähetyksessä. Myös kohteen oma palomuuri ja kuunteluosoite on sovitettava yhteen, sillä loopbackiin sidottu palvelu hylkää huolellisimmin reititetynkin paketin. Käytäntö, joka kattaa vain toisen suunnan keskustelusta, epäonnistuu yleensä onnistuneella pyynnöllä ja äänettömällä vastauksella, mikä on kolmesta tuloksesta hämmentävin.

Vastavuoroiset reitit tarkoittavat yleensä, ettei lähdekäännöstä tarvita, mikä säilyttää WireGuard-osoitteen kohteessa ja tekee lokeista luettavia. Älä lisää kattavaa masqueradingia siksi, että mukana on kaksi protokollaa, äläkä poista olemassa olevaa käännössääntöä tietämättä, mitä siitä riippuu. Tarkista sitten yksittäinen virta päästä päähän ja testaa myös yksi kielletty lähde tai portti: toimiva kättely kummallakin puolella ei todista ristireittiä eikä eristystä.