WireGuard-kliënt bereik nie ’n OpenVPN-kliënt nie?

Beide tonnels verbind, elke kliënt kan die gateway bereik, en die oomblik wanneer een die ander se adres probeer, verdwyn die pakkies. Niks is verkeerd met enige van die handdrukke nie, en geen hoeveelheid heruitreiking van sleutels verander dit nie. Die gateway hou gewone onversleutelde IP-pakkies tussen twee van sy eie koppelvlakke, so die protokolle hoef mekaar nooit te verstaan nie; wat hulle nodig het, is drie dinge wat geen handdruk verskaf nie. Bestemmingsdekking op die oorsprongkliënt, bron-eienaarskap by die gateway, en ’n terugpad aan die ander kant. Die simptoom is dieselfde vir al drie, en daarom word hulle saam gediagnoseer.

Die simptoom het een ontbrekende stuk op ’n slag

Hierdie ontwerp gebruik ’n WireGuard-poel van 10.71.0.0/24 op wg1 en ’n OpenVPN-poel van 10.72.0.0/24 op tun1, wat albei op een gateway eindig. Die navraag onder toets loop van 10.71.0.5 na HTTPS op 10.72.0.30. Elke stap hieronder handel oor daardie een vloei. Elke kontrole het ’n ander foutprofiel, selfs al ervaar die gebruiker hulle identies, en gewoonlik ontbreek net een van die drie op ’n slag.

Begin deur te bevestig dat albei poele werklik op hierdie gateway is en dat aanstuur geaktiveer is in die naamruimte waar die tonnels woon. ’n Gateway wat albei protokolle in verskillende naamruimtes eindig, stuur niks tussen hulle aan nie, en dit is die moeite werd om dit uit te skakel voordat enige eweknie-konfigurasie gelees word.

Brei die spoke se bestemmingsdekking uit

Op die WireGuard-kliënt moet die bestaande eweknie-inskrywing die gateway vir die OpenVPN-bestemming kies, wat beteken dat die bestemmingsvoorvoegsel in daardie eweknie se toegelate lys moet verskyn. Om dit by te voeg skep nie ’n tweede tonnel nie; dit verander watter eweknie die kliënt kies wanneer hy daardie adres opsoek, en met wg-quick volg die roete gewoonlik outomaties die lys.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Los die werklike sleutel- en eindpuntlyne ongemoeid, en onthou dat ’n bestuurder wat Table = off gebruik, glad geen roete uit hierdie lys neem nie. In daardie geval moet dieselfde voorvoegsel deur wie dit ook al besit in die stelsel se roetelys geïnstalleer word, en ’n ontbrekende roete daar lyk presies soos ’n ontbrekende toegelate voorvoegsel.

Hou bron-eienaarskap by die gateway

Die gateway se eweknie-inskrywing vir hierdie kliënt moet steeds presies daardie kliënt se bronadres besit. Toegelate adresse word in albei rigtings nagegaan: hulle kies ’n eweknie vir uitgaande verkeer en hulle valideer dat ’n inkomende pakkie se bron aan die eweknie wat dit gestuur het, behoort. Om die OpenVPN-poel in die spoke se inskrywing te plaas omdat die spoke dit wil bereik, is die fout wat verkeer na die verkeerde deelnemer laat beweeg.

AllowedIPs = 10.71.0.5/32

Lees daardie inskrywing as ’n verklaring van eienaarskap eerder as ’n roetegerief. Enigiets anders wat die kliënt moet bereik, hoort in die kliënt se bestemmingslys, nie in die gateway se idee van wat hierdie eweknie toegelaat word om te stuur nie.

Gee die OpenVPN-kant ’n terugroete

Die teiken het nou ’n roete terug na die WireGuard-bron nodig, en vir gepoel kliënte kom dit gewoonlik as ’n gestuurde roete van die OpenVPN-bediener. Stuur dit net aan kliënte wat dit behoort te hê, en bevestig op die kliënt dat dit aanvaar is eerder as om aan te neem dat die richtlijn toegepas is.

push "route 10.71.0.0 255.255.255.0"

Roeteverspreiding is nie magtiging nie. Wanneer die bestemming agter ’n ander OpenVPN-kliënt sit in plaas van in die poel, sluit daardie kliënt se eie LAN-eienaarskap en aanstuurvereistes by die ontwerp aan, en die gestuurde roete is net die eerste helfte. Herformuleer die vereiste as ’n grafiek voordat richtlyne bygevoeg word: watter nodus besit watter voorvoegsel, en watter nodus stuur daarnatoe aan.

Laat net die een diens toe wat jy bedoel het om toe te laat

Met aanstuur geaktiveer en albei poele routeerbaar, is die oorblywende vraag beleid. Skryf die reël vir die spesifieke vloei eerder as vir die koppelvlakpaar in die algemeen, voorskou dit voordat dit toegepas word, en hou die toestandvolle terugpad sodat antwoorde nie as nuwe verbindings geblokkeer word nie. ’n Proeflopie kos niks en wys presies wat bygevoeg sou word.

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

Hierdie is aangestuurde reëls, apart van die gateway se luisterreëls vir die twee VPN-dienste. Om die buitenste UDP-poorte oop te maak, magtig nie die binneste versoek nie, en om die binneste versoek te magtig vereis nie onbeperkte SSH na die gateway of ’n verstek-toelaat op aanstuur nie. Die teiken se eie firewall en luisteradres moet ook saamstem, aangesien ’n diens wat aan loopback gebind is die mees sorgvuldig gerouteerde pakkie weier. Beleid wat net een rigting van die gesprek dek, faal gewoonlik met ’n suksesvolle versoek en ’n stille antwoord, wat die mees verwarrende uitkoms van die drie is.

Wedersydse roetes beteken gewoonlik dat geen brontoewysing nodig is nie, wat die WireGuard-adres by die teiken bewaar en logs leesbaar maak. Moet nie ’n blinde masquerading byvoeg omdat twee protokolle betrokke is nie, en moet nie ’n bestaande toewysingsreël verwyder sonder om te weet wat daarvan afhanklik is nie. Verifieer dan die enkele vloei van punt tot punt, en toets ook een nie-toegelate bron of poort: ’n werkende handdruk aan elke kant bewys nóg die kruisroete nóg die isolasie.