A mund t'i arrijnë klientët në dy servera OpenVPN njëri-tjetrin?

Ngritja e një OpenVPN serveri të dytë ju jep një vend të dytë ku klientët mund të lidhen, dhe asgjë më shumë. Ai nuk i vendos ata klientë në rrjetin e serverit të parë, dhe opsioni i quajtur client-to-client ndryshon vetëm përcjelljen brenda një procesi të vetëm serveri. Dy grupet bëhen një rrjet kur rrugëtoni mes tyre, me qëllim, me një pronar për çdo drejtim. Gjithçka më poshtë supozon modalitetin TUN në hapësirën e përdoruesit me atë përcjellje të brendshme të fikur, kështu që vendimin e merr kernel-i.

Miti: një listë llogarish, një rrjet

Vërtetimi dhe arritshmëria ngatërrohen sepse të dyja jetojnë në konfigurimin e serverit. Një përdorues që mund të hyjë në cilindo nga dy portat duket, nga jashtë, si një përdorues në një sistem me dy dyer. Brenda, çdo server shpërndan adresa nga grupi i vet dhe instalon rrugë vetëm për klientët që përfundon. Pra, një klient në portën A që dërgon një paketë te një klient në portën B po kërkon një destinacion për të cilin serveri i tij nuk ka dëgjuar kurrë. Paketa shkon te rruga e paracaktuar e A, del nga tuneli dhe mbërrin te një firewall të cilit nuk i është kërkuar kurrë ta lejojë.

Shtimi i një serveri të dytë, pra, nuk shton tepricë, zbulim ose një domen transmetimi të përbashkët. Ai shton një rrjet të rrugëtuar që ka nevojë për një plan, dhe plani fillon me adresimin.

Jepini çdo porte grupin dhe adresën e tranzitit të vet

Dy intervale që nuk mund të mbivendosen me asgjë tjetër, plus një lidhje e vogël tranziti mes hosteve, është i gjithë plani i adresave. Mbajeni tranzitin në një segment privat që e kontrolloni, dhe shkruajini numrat përpara se ndonjë server të japë një qira.

Rezistojini tundimit për t'u dhënë të dy serverëve të njëjtin grup që profilet të mbeten identike. Një rrugë kernel-i nuk mund të thotë cili prej dy hosteve zotëron aktualisht një adresë arbitrare brenda një intervali të përbashkët, kështu që tabela e rrugëtimit do të tregonte një portë dhe klienti mund të ishte i lidhur me tjetrën. Emrat e ndërfaqeve janë konvencione lokale, jo gjendje e përbashkët. Të dy hostet këtu e quajnë pajisjen e tunelit tun0 dhe lidhjen e tranzitit transit0, gjë që është në rregull sepse asnjë paketë nuk i mbart ata emra.

Instaloni rrugën në të dy anët

Çdo portë ka nevojë për një rrugë drejt grupit të tjetrës përmes adresës së tranzitit, dhe përcjellja duhet të jetë e ndezur që cilado të veprojë si hop. Konfirmoni së pari tabelën aktuale, pastaj shtoni hyrjen dhe bëjeni të qëndrueshme përmes menaxherit të rrjetit të hostit, jo përmes një grepi rilidhjeje.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Pasqyrojeni këtë në hostin tjetër me grupet të ndërruara. Shtimi i përsëritur i së njëjtës rrugë nga një skript i palidhur është mënyra se si një host përfundon me disa kopje dhe një ndryshim misterioz herën tjetër që dikush lexon tabelën. Nëse lidhja e tranzitit është vetë një tunel, rruga tregon topologjinë e atij tuneli dhe hop-i duhet t'i mbijetojë rilidhjes së tij. Një adresë tranziti që zhduket për tridhjetë sekonda merr me vete shtegun mes grupeve, gjë që është një veti e projektimit që ia vlen të thuhet, jo të zbulohet.

Shtyjeni rrugën e klientit pa falsifikuar pronësinë

Klientët kanë nevojë për një rrugë drejt grupit të largët, përndryshe sistemi i tyre operativ e dërgon paketën te porta e paracaktuar dhe tuneli nuk e sheh kurrë. Konfigurimi i serverit është vendi i natyrshëm për t'ia dorëzuar.

push "route 10.64.20.0 255.255.255.0"

Vendosni rreshtin pasqyrë në konfigurimin e serverit tjetër, pastaj rilidhni një klient testues dhe lexoni tabelën e tij. Një klient që i injoron rrugët e shtyra ka nevojë për konfigurimin e vet të miratuar, dhe një rrugë që nuk mbërrin kurrë nuk është kontroll aksesi. Mos i jepni një klienti iroute për të gjithë grupin e portës tjetër. Ai direktiv ekziston për një nënrrjet pas një klienti të lidhur, dhe përdorimi i tij për të mbuluar një rrugë që mungon mes portave prodhon një server që beson se zotëron adresa që nuk mund t'i arrijë.

Provoni një kërkesë dhe refuzoni një tjetër

Zgjidhni një operacion real, për shembull HTTPS nga një klient në 10.64.10.21 drejt një shërbimi në 10.64.20.37, dhe lejoni pikërisht atë në të dy hostet. Çdo firewall e pranon kërkesën në anën hyrëse dhe përgjigjen e gjurmuar në anën e kthimit; politika e vetë shërbimit të destinacionit duhet ende ta pranojë atë.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Me rrugë të ndërsjella, NAT-i i burimit është i panevojshëm dhe këtu aktivisht i dëmshëm: përkthimi i burimit fsheh cili klient e bëri kërkesën dhe dështon politikën e bazuar në burim në anën e destinacionit. Kontrolloni që një rregull ekzistues masquerade për daljen në internet të mos e kapë edhe këtë shteg. Pastaj testoni refuzimin. Një shërbim që duhet të mbetet lokal në grupin B duhet të mbetet i paarritshëm nga grupi A, dhe çiftet e klientëve në të njëjtën portë duhet të testohen gjithashtu, pasi politika e përcjelljes që sapo ndryshuat vlen edhe për ta.

Një korrigjim tjetër i modelit mendor: lidhja e tranzitit mbart paketa të brendshme të dekriptuara, pra është kufi besimi dhe jo garanci private. Nëse kalon nëpër një rrjet që nuk e kontrolloni, mbrojeni atë hop me një tunel të kriptuar të miratuar dhe rrugëtoni përmes topologjisë së tij reale. TLS nga skaji në skaj ende e vërteton aplikacionin vetë, prandaj shërbimi i brendshëm duhet të vazhdojë ta përdorë.