A nuk arrin një klient WireGuard te një klient OpenVPN?

Të dy tunelet lidhen, çdo klient arrin gateway-in, dhe në momentin që njëri provon adresën e tjetrit paketat zhduken. Asnjëra nga dy shtrëngimet e duarve nuk ka gjë të gabuar, dhe riemërtimi i çelësave nuk e ndryshon këtë. Gateway-i transporton paketa IP të zakonshme të paenkriptuara midis dy prej ndërfaqeve të tij, prandaj protokollet nuk kanë nevojë kurrë të kuptojnë njëri-tjetrin; atyre u duhen tre gjëra që asnjë shtrëngim duarsh nuk i jep. Mbulimi i destinacionit në klientin burim, pronësia e burimit në gateway dhe një rrugë kthimi në anën tjetër. Simptoma është e njëjtë për të tre, prandaj diagnostikohen së bashku.

Simptomës i mungon një pjesë në një kohë

Ky dizajn përdor një pishinë WireGuard 10.71.0.0/24 në wg1 dhe një pishinë OpenVPN 10.72.0.0/24 në tun1, të dyja përfundojnë në një gateway të vetëm. Kërkesa në provë shkon nga 10.71.0.5 në HTTPS në 10.72.0.30. Çdo hap më poshtë ka të bëjë me atë rrjedhë të vetme. Çdo kontroll ka një nënshkrim tjetër dështimi ndonëse përdoruesi i përjeton njësoj, dhe zakonisht mungon vetëm njëra nga të treja në një kohë.

Filloni duke konfirmuar se të dyja pishinat janë vërtet në këtë gateway dhe se përçimi është i aktivizuar në hapësirën e emrave ku jetojnë tunelet. Një gateway që përfundon të dy protokollet në hapësira emrash të ndryshme nuk përçon asgjë midis tyre, dhe ia vlen ta përjashtosh para se të lexosh ndonjë konfigurim peer.

Zgjeroni mbulimin e destinacionit të spikës

Në klientin WireGuard, zëri ekzistues i peer-it duhet të zgjedhë gateway-in për destinacionin OpenVPN, që do të thotë se prefiksi i destinacionit duhet të shfaqet në listën e lejuar të atij peer. Shtimi i tij nuk krijon një tunel të dytë; ndryshon cilin peer zgjedh klienti kur kërkon atë adresë, dhe me wg-quick rruga zakonisht ndjek listën automatikisht.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Lërini rreshtat realë të çelësit dhe të pikës fundore të paprekur, dhe mbani mend se një menaxher që përdor Table = off nuk merr asnjë rrugë nga kjo listë. Në atë rast i njëjti prefiks duhet të instalohet në tabelën e rrugëve të sistemit nga ai që e zotëron, dhe një rrugë që mungon atje duket saktësisht si një prefiks i lejuar që mungon.

Mbajeni pronësinë e burimit në gateway

Zëri i peer-it të këtij klienti në gateway duhet të vazhdojë të zotërojë saktësisht adresën e burimit të atij klienti. Adresat e lejuara kontrollohen në të dy drejtimet: zgjedhin një peer për trafikun në dalje dhe vërtetojnë se burimi i një pakete në hyrje i përket peer-it që e dërgoi. Vendosja e pishinës OpenVPN në zërin e spikës sepse spika dëshiron ta arrijë është gabimi që e drejton trafikun te pjesëmarrësi i gabuar.

AllowedIPs = 10.71.0.5/32

Lexojeni atë zë si deklaratë pronësie dhe jo si lehtësi rrugëtimi. Çdo gjë tjetër ku klienti duhet të arrijë i përket listës së destinacioneve të klientit, jo idesë së gateway-it për atë që ky peer lejohet të dërgojë.

Jepini anës OpenVPN një rrugë kthimi

Destinacioni tani ka nevojë për një rrugë përsëri drejt burimit WireGuard, dhe për klientët e pishinës ajo zakonisht vjen si rrugë e shtyrë nga serveri OpenVPN. Shtyjeni vetëm te klientët që duhet ta kenë, dhe konfirmoni në klient se është pranuar në vend që të supozoni se direktiva u zbatua.

push "route 10.71.0.0 255.255.255.0"

Shpërndarja e rrugëve nuk është autorizim. Kur destinacioni qëndron pas një klienti tjetër OpenVPN dhe jo në pishinë, pronësia e LAN-it të vetë atij klienti dhe kërkesat e tij për përçim i bashkohen dizajnit, dhe rruga e shtyrë është vetëm gjysma e parë. Riformulojeni kërkesën si graf para se të shtoni direktiva: cila nyje zotëron cilin prefiks dhe cila nyje përçon drejt tij.

Lejoni vetëm atë shërbimin që kishit ndërmend të lejoni

Me përçimin të aktivizuar dhe të dyja pishinat të rrugëtueshme, pyetja që mbetet është politika. Shkruani rregullin për rrjedhën konkrete dhe jo për çiftin e ndërfaqeve në përgjithësi, shikojeni paraprakisht para se ta zbatoni dhe mbani rrugën e kthimit me gjendje që përgjigjet të mos bllokohen si lidhje të reja. Një provë e thatë nuk kushton asgjë dhe tregon saktësisht çfarë do të shtohej.

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

Këto janë rregulla për trafikun e përçuar, të veçanta nga rregullat e dëgjimit të gateway-it për dy shërbimet VPN. Hapja e porteve UDP të jashtme nuk e autorizon kërkesën e brendshme, dhe autorizimi i kërkesës së brendshme nuk kërkon SSH pa kufi drejt gateway-it ose leje të parazgjedhur në përçim. Edhe firewalls i destinacionit dhe adresa e dëgjimit duhet të përputhen, sepse një shërbim i lidhur me loopback refuzon edhe paketën më me kujdes të rrugëtuar. Një politikë që mbulon vetëm një drejtim të bisedës zakonisht dështon me një kërkesë të suksesshme dhe një përgjigje të heshtur, që është rezultati më konfuz i të trejave.

Rrugët reciproke zakonisht nënkuptojnë se nuk nevojitet përkthim burimi, gjë që e ruan adresën WireGuard në destinacion dhe i bën regjistrat të lexueshëm. Mos shtoni masquerading të përgjithshëm sepse janë të përfshirë dy protokolle, dhe mos hiqni një rregull ekzistues përkthimi pa e ditur se çfarë varet prej tij. Më pas verifikoni rrjedhën e vetme nga fillimi në fund, dhe provoni gjithashtu një burim ose portë të palejuar: një shtrëngim duarsh që funksionon në secilën anë nuk vërteton as rrugën e kryqëzuar as izolimin.