Ali klient WireGuard ne doseže klienta OpenVPN?

Oba tunela se povežeta, vsak klient doseže prehod, in v trenutku, ko eden poskusi naslov drugega, paketi izginejo. Z nobenim od dveh rokovanj ni nič narobe in nobena ponovna izdaja ključev tega ne spremeni. Prehod prenaša običajne nešifrirane pakete IP med dvema svojima vmesnikoma, zato protokolom nikoli ni treba razumeti drug drugega; potrebujejo tri stvari, ki jih nobeno rokovanje ne ponuja. Pokritost cilja na izvornem klientu, lastništvo vira na prehodu in povratna pot na drugi strani. Simptom je pri vseh treh enak, zato jih diagnosticirajo skupaj.

Simptomu manjka vsakič en del

Ta zasnova uporablja bazen WireGuard 10.71.0.0/24 na wg1 in bazen OpenVPN 10.72.0.0/24 na tun1, oba končata na enem prehodu. Preizkušena zahteva gre z 10.71.0.5 na HTTPS na 10.72.0.30. Vsak spodnji korak se nanaša na ta isti tok. Vsako preverjanje ima drugačen podpis okvare, čeprav jih uporabnik doživlja enako, in običajno hkrati manjka le ena od treh.

Začnite s potrditvijo, da sta oba bazena res na tem prehodu in da je posredovanje omogočeno v imenskem prostoru, kjer živijo tuneli. Prehod, ki oba protokola zaključi v različnih imenskih prostorih, med njima ne posreduje ničesar, in to je vredno izključiti, preden preberete katero koli konfiguracijo partnerja.

Razširite pokritost cilja na kraku

Na klientu WireGuard mora obstoječi vnos partnerja izbrati prehod za cilj OpenVPN, kar pomeni, da mora biti predpona cilja na seznamu dovoljenih tega partnerja. Njena dodaja ne ustvari drugega tunela; spremeni, katerega partnerja klient izbere, ko išče ta naslov, in s wg-quick pot običajno samodejno sledi seznamu.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Pustite prave vrstice ključa in končne točke nedotaknjene in zapomnite si, da upravitelj, ki uporablja Table = off, s tega seznama ne vzame nobene poti. V tem primeru mora isto predpono v sistemsko usmerjevalno tabelo vnesti tisti, ki jo ima v lasti, in manjkajoča pot tam izgleda natanko kot manjkajoča dovoljena predpona.

Ohranite lastništvo vira na prehodu

Vnos partnerja tega klienta na prehodu mora še naprej imeti v lasti natanko naslov vira tega klienta. Dovoljeni naslovi se preverjajo v obe smeri: izberejo partnerja za odhodni promet in potrdijo, da izvor dohodnega paketa pripada partnerju, ki ga je poslal. Če bazen OpenVPN postavite v vnos kraka zato, ker želi krak doseči, je to napaka, ki promet usmeri k napačnemu udeležencu.

AllowedIPs = 10.71.0.5/32

Ta vnos berite kot izjavo o lastništvu in ne kot udobnost usmerjanja. Vse drugo, do česar mora klient priti, spada na seznam ciljev klienta, ne v predstavo prehoda o tem, kaj sme ta partner pošiljati.

Dajte strani OpenVPN povratno pot

Cilj zdaj potrebuje pot nazaj do vira WireGuard, pri klientih iz bazena pa običajno pride kot potisnjena pot s strežnika OpenVPN. Potisnite jo le klientom, ki naj bi jo imeli, in na klientu potrdite, da je bila sprejeta, namesto da predpostavljate, da se je direktiva uporabila.

push "route 10.71.0.0 255.255.255.0"

Razdeljevanje poti ni avtorizacija. Ko je cilj za drugim klientom OpenVPN in ne v bazenu, se lastništvo lastnega omrežja LAN tega klienta in njegove zahteve po posredovanju pridružijo zasnovi, potisnjena pot pa je le prva polovica. Preoblikujte zahtevo v graf, preden dodate direktive: katero vozlišče ima katero predpono in katero vozlišče posreduje proti njej.

Dovolite samo tisto eno storitev, ki ste jo nameravali dovoliti

Ko je posredovanje omogočeno in sta oba bazena usmerljiva, ostane vprašanje politike. Pravilo napišite za konkretni tok in ne za par vmesnikov na splošno, pred uporabo ga pokažite v predogledu in ohranite povratno pot z stanjem, da odgovori ne bodo blokirani kot nove povezave. Poskusni tek nič ne stane in pokaže natanko, kaj bi bilo dodano.

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

To so pravila za posredovani promet, ločena od pravil poslušanja prehoda za obe storitvi VPN. Odpiranje zunanjih vrat UDP ne avtorizira notranje zahteve, avtorizacija notranje zahteve pa ne zahteva neomejenega SSH do prehoda ali privzetega dovoljenja pri posredovanju. Tudi požarni zid cilja in njegov naslov poslušanja se morata ujemati, ker storitev, vezana na loopback, zavrne tudi najbolj skrbno usmerjen paket. Politika, ki pokriva samo eno smer pogovora, običajno odpove z uspešno zahtevo in tihim odgovorom, kar je najbolj zmeden od treh izidov.

Vzajemne poti običajno pomenijo, da prevod vira ni potreben, kar ohrani naslov WireGuard na cilju in naredi dnevnike berljive. Ne dodajajte splošnega masqueradinga zato, ker sta vključena dva protokola, in ne odstranjujte obstoječega pravila prevoda, ne da bi vedeli, kaj je od njega odvisno. Nato preverite ta en tok od začetka do konca in preizkusite tudi en prepovedan vir ali vrata: delujoče rokovanje na vsaki strani ne dokazuje niti križne poti niti izolacije.