Vai WireGuard klients nevar sasniegt OpenVPN klientu?

Abi tuneļi savienojas, katrs klients sasniedz vārteju, un tajā brīdī, kad viens izmēģina otra adresi, paketes pazūd. Nevienā no abām roku saspiešanām nav nekā nepareiza, un atslēgu atkārtota izsniegšana to nemaina. Vārteja pārvieto parastas nešifrētas IP paketes starp divām savām saskarnēm, tāpēc protokoliem nekad nav jāsaprot viens otru; tiem vajadzīgas trīs lietas, ko neviena roku saspiešana nesniedz. Galamērķa pārklājums sākotnējā klientā, avota īpašumtiesības vārtejā un atgriešanās ceļš otrā pusē. Simptoms visiem trim ir vienāds, tāpēc tos diagnosticē kopā.

Simptomam vienmēr trūkst vienas daļas

Šis dizains izmanto WireGuard baseinu 10.71.0.0/24 saskarnē wg1 un OpenVPN baseinu 10.72.0.0/24 saskarnē tun1, un abi beidzas vienā vārtejā. Pārbaudāmais pieprasījums iet no 10.71.0.5 uz HTTPS 10.72.0.30 adresē. Katrs solis zemāk attiecas uz šo vienu plūsmu. Katrai pārbaudei ir atšķirīgs atteices paraksts, lai gan lietotājs tās piedzīvo vienādi, un parasti vienlaikus trūkst tikai viena no trim.

Sāciet, apstiprinot, ka abi baseini patiešām ir šajā vārtejā un ka pārsūtīšana ir ieslēgta nosaukumtelpā, kurā dzīvo tuneļi. Vārteja, kas abus protokolus pabeidz dažādās nosaukumtelpās, starp tām neko nepārsūta, un to ir vērts izslēgt pirms jebkuras partnera konfigurācijas lasīšanas.

Paplašiniet spieķa galamērķa pārklājumu

WireGuard klientā esošajam partnera ierakstam jāizvēlas vārteja OpenVPN galamērķim, tas nozīmē, ka galamērķa prefiksam jāatrodas šī partnera atļauto sarakstā. Tā pievienošana neveido otru tuneli; tā maina, kuru partneri klients izvēlas, meklējot šo adresi, un ar wg-quick maršruts parasti automātiski seko sarakstam.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Atstājiet īstās atslēgas un galapunkta rindas neskartas un atcerieties, ka pārvaldnieks, kas izmanto Table = off, no šī saraksta neņem vispār nevienu maršrutu. Tādā gadījumā tas pats prefikss jāievada sistēmas maršrutu tabulā tam, kam tas pieder, un tur trūkstošs maršruts izskatās tieši kā trūkstošs atļautais prefikss.

Saglabājiet avota īpašumtiesības vārtejā

Šī klienta partnera ierakstam vārtejā jāturpina piederēt tieši šī klienta avota adresei. Atļautās adreses pārbauda abos virzienos: tās izvēlas partneri izejošajai plūsmai un apstiprina, ka ienākošās paketes avots pieder partnerim, kurš to nosūtījis. OpenVPN baseina ievietošana spieķa ierakstā tāpēc, ka spieķis grib to sasniegt, ir tā kļūda, kas novirza plūsmu pie nepareizā dalībnieka.

AllowedIPs = 10.71.0.5/32

Lasiet šo ierakstu kā īpašumtiesību deklarāciju, nevis kā maršrutēšanas ērtību. Viss pārējais, kas klientam jāsasniedz, pieder klienta galamērķu sarakstam, nevis vārtejas priekšstatam par to, ko šim partnerim ir atļauts sūtīt.

Dodiet OpenVPN pusei atgriešanās maršrutu

Galamērķim tagad vajadzīgs maršruts atpakaļ uz WireGuard avotu, un baseina klientiem tas parasti pienāk kā no OpenVPN servera aizstumts maršruts. Stumiet to tikai tiem klientiem, kuriem tas jābūt, un klientā apstipriniet, ka tas ir pieņemts, nevis pieņemiet, ka direktīva tika piemērota.

push "route 10.71.0.0 255.255.255.0"

Maršrutu izplatīšana nav atļauja. Kad galamērķis atrodas aiz cita OpenVPN klienta, nevis baseinā, šī klienta paša LAN īpašumtiesības un pārsūtīšanas prasības pievienojas dizainam, un aizstumtais maršruts ir tikai pirmā puse. Pārformulējiet prasību kā grafu pirms direktīvu pievienošanas: kurš mezgls kam prefiksam pieder un kurš mezgls pārsūta uz to.

Atļaujiet tieši to vienu pakalpojumu, kuru gribējāt atļaut

Kad pārsūtīšana ir ieslēgta un abi baseini ir maršrutējami, paliek politikas jautājums. Rakstiet noteikumu konkrētajai plūsmai, nevis saskarņu pārim kopumā, pirms piemērošanas apskatiet to priekšskatījumā un saglabājiet stāvokli saglabājošo atgriešanās ceļu, lai atbildes netiktu bloķētas kā jauni savienojumi. Sausā palaide neko nemaksā un parāda tieši to, kas tiktu pievienots.

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

Šie ir pārsūtītās plūsmas noteikumi, atsevišķi no vārtejas klausīšanās noteikumiem diviem VPN pakalpojumiem. Ārējo UDP portu atvēršana nepiešķir atļauju iekšējam pieprasījumam, un iekšējā pieprasījuma atļaušanai nav vajadzīgs neierobežots SSH uz vārteju vai noklusējuma atļauja pārsūtīšanā. Arī galamērķa ugunsmūrim un klausīšanās adresei jāsakrīt, jo pie loopback piesaistīts pakalpojums noraida pat visrūpīgāk maršrutēto paketi. Politika, kas aptver tikai vienu sarunas virzienu, parasti cieš neveiksmi ar veiksmīgu pieprasījumu un klusu atbildi, un tas ir mulsinošākais no trim rezultātiem.

Savstarpēji maršruti parasti nozīmē, ka avota tulkošana nav vajadzīga, kas saglabā WireGuard adresi galamērķī un padara žurnālus lasāmus. Nepievienojiet visaptverošu masquerading tāpēc, ka iesaistīti divi protokoli, un nenoņemiet esošu tulkošanas noteikumu, nezinot, kas no tā ir atkarīgs. Pēc tam pārbaudiet vienu plūsmu no sākuma līdz beigām un izmēģiniet arī vienu aizliegtu avotu vai portu: strādājoša roku saspiešana abās pusēs nepierāda ne krustoto maršrutu, ne izolāciju.