Dy tunele OpenVPN në një host të vetëm Linux: e kujt është rruga?

Dy profile janë të lidhur, dhe njëri prej tyre mbart në heshtje trafik të destinuar për tjetrin. Një host Linux mund t'i ekzekutojë të dy klientët OpenVPN njëkohësisht pa vështirësi. Ajo që nuk mund të bëjë është të vendosë në vendin tuaj se cili proces mund të kërkojë cilën prefiks. Ky vendim duhet të merret përpara se të ngrihet tuneli i dytë, jo pasi një burim ndalon së përgjigjuri.

Filloni nga puna që duhet të bëjë lidhja e dytë

Një zyrë e arritshme përmes një profili dhe një laborator i arritshëm përmes një tjetri kërkojnë që të dy tunelet të jenë lart dhe asnjëri prej tyre të mos kërkojë gjithçka. Një aplikacion kokëfortë që duhet të dalë përmes profilit të dytë ka nevojë për një rregull politike, jo për një rrugë të dytë të parazgjedhur. Një lidhje rezervë ka nevojë vetëm për një tunel që punon në një kohë, kështu që rezerva nuk duhet të nisë me makinën.

Këto janë tre konfigurime të ndryshme, dhe ngatërrohen sepse të treja fillojnë në të njëjtën mënyrë: një profil i dytë dhe një lidhje e suksesshme. Shkruani fillimisht rregullimin e synuar, pastaj konfiguroni drejt tij. Një fjali për qëllimin kursen një orë kapje paketash.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Komanda e parë liston instancat që po ekzekutohen, duke përfshirë ato të nisura me dorë jashtë menaxherit. E dyta printon kërkesën aktuale të parazgjedhur, dhe ky është gjendja që do të duhet të shpjegoni më vonë.

Pishinat që mbivendosen thyhen përpara rrugëtimit

Dy serverë do të caktojnë me gëzim adresa nga i njëjti 10.8.0.0/24. Klienti më pas mban dy ndërfaqe brenda një prefiksi pa asgjë që thotë se cili destinacion i takon cilit, dhe sjellja që rezulton duket si një defekt rrugëtimi, por në të vërtetë është një defekt numërimi. Rinumerimi i një pishine kushton një redaktim konfigurimi; çdo anashkalim rrugëtimi pas kësaj kushton një fundjavë. Kontrolloni pishinën përpara se t'i shtoni një rrugë.

Shikoni edhe LAN-in lokal. Një LAN shtëpiak i numëruar 192.168.1.0/24 që një tunel gjithashtu e ekspozon prodhon të njëjtën paqartësi, dhe simptomi është një emër hosti që zgjidhet ndërsa lidhja nuk përfundon kurrë. Kjo duket si një defekt zgjidhjeje emrash derisa të printoni rrugët.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Krahasoni të dyja daljet me të dyja konfigurimet e serverit përpara se të prekni klientin. Nëse prefikset mbivendosen, ndaloni dhe rinumeroni, sepse asnjë sasi rinisjesh nuk do t'i ndajë ato.

Jepini çdo profili njësinë e vet dhe çdo prefiksi një pronar

Çdo profil merr emrin e vet të instancës dhe skedarin e vet të konfigurimit, kështu që instanca e quajtur office ngarkon office.conf ndërsa ajo e quajtur lab ngarkon lab.conf. Konfirmoni atë hartëzim përmes menaxherit të shërbimeve në vend që të besoni një listim drejtorie, sepse një drop-in mund të ndryshojë cili skedar ngarkohet. Hartëzimi i gabuar do të thotë që po rregulloni profilin që nuk po ekzekutohet.

Më pas vendosni kush i instalon rrugët. Kur serverët shtyjnë grupe të papajtueshme, ose refuzoni shtytjen dhe listoni vetë prefikset, ose lini një profil të mbajë të parazgjedhurin dhe drejtojeni tjetrin me rregulla politike. Dy procese që të dyja instalojnë një të parazgjedhur përfundojnë me një fitues të heshtur dhe pa asnjë regjistrim të shkruar të vendimit.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

E para tregon njësinë me çdo anashkalim që ndryshon argumentet e saj. E dyta tregon nëse profili pranon fare rrugët e shtyra, dhe ky është çelësi që vendos gjithçka më tej.

Shenjat i mbajnë përgjigjet në ndërfaqen nga e cila erdhën

Kur çdo tunel shërben burime të ndryshme, një përgjigje mund të dalë përmes lidhjes së gabuar dhe lidhja vdes pas paketës së parë. Modeli që qëndron është të shënoni paketat që mbërrijnë sipas ndërfaqes hyrëse, të rivendosni atë shenjë në përgjigje dhe t'i jepni çdo shenje një tabelë me portën e vet të parazgjedhur.

Filtrimi i lirshëm i rrugës së kthimit zakonisht duhet lehtësuar për ndërfaqet e prekura, sepse një përgjigje mbërrin në mënyrë legjitime përmes një lidhjeje që tabela kryesore nuk do ta zgjidhte kurrë. Mbani shenjat të ngushta që të mos kapin kurrë trafikun e kriptuar të vetë tuneleve, gjë që do ta dërgonte tunelin përmes vetvetes.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Lexoni rregullat ekzistuese përpara se të shtoni një tjetër. Prioritetet e dyfishta dhe tabelat e harruara janë arsyeja e zakonshme pse një politikë shenjash duket se nuk ka fare efekt.

Provoni izolimin duke ndalur një lidhje

Me të dy tunelet lart, regjistroni adresën e çdo ndërfaqeje, rrugën drejt një hosti pas çdo tuneli dhe rrugën që merr një destinacion i palidhur. Kërkojini kernelit kërkimin në vend që të lexoni një tabelë të vetme, sepse një tabelë nuk tregon kurrë vendimin përfundimtar.

Më pas ndaloni një instancë dhe shikoni ndërfaqen dhe rrugët e saj të zhduken ndërsa tjetra vazhdon. Një ndërprerje tek ajo që mbijeton do të thotë që të dyja ndajnë akoma një emër pajisjeje, një rrugë ose një rregull firewally që askush nuk i ndau.

Kthejeni profilin e ndalur dhe përsëritni të njëjtat kontrolle. Kur një tunel mbijeton vetëm në nisjen e parë pas një rindezjeje, po shikoni një defekt cikli jetësor dhe jo një dizajn rrugëtimi.