Lidh dy klientë OpenVPN në një host të vetëm Linux me fwmark

Shtimi i një klienti të dytë OpenVPN në një host të vetëm Linux dështon në një nga dy vendet. Ose klienti i brendshëm nuk arrin serverin e vet sepse tuneli i jashtëm e ka kapur atë transport, ose klienti i dytë rishkruan tabelën e rrugëve dhe tuneli i parë ndalon së punuari. Të dy problemet janë në rrugëzim, jo në kriptim, dhe të dyja zgjidhen para se tuneli i ri të mbajë çfarëdo trafiku aplikacioni. Adresat këtu janë ilustruese: tun0 është tuneli i jashtëm, 203.0.113.9 është serveri i brendshëm dhe TCP 9999 është rrjedha që duhet të përdorë rrugën e brendshme.

Dy mënyra dështimi, një tabelë rrugësh

Një klient i brendshëm hap një socket UDP drejt serverit të vet, dhe ai socket ndjek tabelën aktuale të rrugëve si çdo tjetër. Nëse tuneli i jashtëm e zotëron tashmë rrugën e paracaktuar, paketat e shtrëngimit të duarve shkojnë në tunelin e jashtëm. Kjo funksionon vetëm kur serveri i jashtëm arrin serverin e brendshëm dhe pala tjetër pranon të mbajë rrjedhën; përndryshe shtrëngimi ngec dhe klienti provon përsëri.

Dështimi i dytë vjen nga push i serverit. Push-i i zakonshëm është redirect-gateway def1, i cili instalon 0.0.0.0/1 dhe 128.0.0.0/1 në vend që të zëvendësojë rrugën e paracaktuar. Prandaj dy klientë që instalojnë secili çiftin e vet /1 përplasen, dhe çifti më i ri fiton për pothuajse çdo destinacion. Kërko ato dy prefikse në tabelë kur një tunel vdes pasi lidhet i dyti, sepse vetë rruga e paracaktuar mund të mos jetë ndryshuar kurrë.

Shëno rrjedhën dhe jepi një tabelë

Drejto trafikun e zgjedhur duke e shënuar në tabelën mangle dhe duke përputhur shenjën në një rregull politike. Rregulli tregon një tabelë të dedikuar, rruga e paracaktuar e së cilës është pajisja e brendshme, kështu që vetëm paketat e shënuara marrin rrugën e brendshme.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Shumica e dështimeve në këtë grup rregullash vijnë nga dy gabime. Vlera e shenjës që vendos firewalls dhe vlera që përputh rregulli duhet të jenë identike, sepse mospërputhja nuk jep as gabim as efekt. Dhe PREROUTING sheh vetëm paketa që vijnë nga jashtë, kështu që një lidhje e nisur në këtë host kërkon një rregull OUTPUT me të njëjtën përputhje para se të shënohet fare.

Hiq pronësinë e rrugëve nga klienti i dytë

Dy opsione e ndalojnë klientin e dytë të modifikojë tabelën, dhe veprojnë në pika të ndryshme. route-nopull injoron opsionet e rrugëve të dërguara me push, kështu që nuk instalohet asgjë. route-noexec i pranon opsionet e dërguara në mjedisin e klientit, por e lë ndryshimin e tabelës te një hook, dhe kjo është ajo që dëshiron kur duhet të shohësh çfarë ofroi serveri.

Hook-u ekzekutohet me vlerat e dërguara në mjedisin e vet dhe duhet të shtojë vetëm hyrjet që ke miratuar. Bëje idempotent: zbraz tabelën që zotëron para se ta rindërtosh dhe mos supozosh se ekzekutimi i mëparshëm la një gjendje të pastër. Një rilidhje e thërret hook-un përsëri, dhe një hook që shton pa pastruar grumbullon rrugë të dyfishta.

Zgjidh një pronar dhe shkruaje. Një profil që vendos të dy opsionet, ose një hook që konkurron me një skript manual, prodhon një tabelë që askush nuk mund ta shpjegojë më vonë.

Fikso të dy adresat e serverëve

Serveri i brendshëm ka nevojë për një rrugë hosti përmes pajisjes së jashtme para se klienti i brendshëm të lidhet. Është pikërisht ai zë që e mban transportin e brendshëm brenda tunelit të jashtëm në vend që ta lërë të ndjekë të paracaktuaren.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Shto gjithashtu një rrugë hosti përputhëse për serverin e jashtëm në tabelën kryesore, përndryshe një rilidhje mund ta drejtojë transportin e vetë klientit të jashtëm në tunelin e vet. Rendi nuk është opsional: shtoji këto zëra pasi të ekzistojë ndërfaqja përkatëse, pra një hook ose skript që ekzekutohet pas lidhjes. Një rrugë që tregon një pajisje të fikur hiqet ose injorohet, kështu që një zë i shkruar në nisje nuk i mbijeton sekuencës që supozuat.

Kontrollo kërkimin në vend që të lexosh të gjithë tabelën. Rezultati i kërkimit të rrugës emërton pajisjen dhe adresën burimore që do të përdorë kernel-i, dhe kjo është saktësisht ajo që merr klienti kur hap socket-in e vet.

Testo zinxhirin dhe bëje dështimin të dukshëm

Kap në ndërfaqen e jashtme ndërsa klienti i brendshëm lidhet. Shtrëngimi i brendshëm i duarve duhet të shfaqet si ngarkesë e kriptuar brenda tunelit të jashtëm; nëse shfaqet si UDP i thjeshtë drejt 203.0.113.9, mungon rruga e hostit dhe zinxhiri nuk u ndërtua kurrë.

Një zinxhir që kthehet në heshtje në uplink-un fizik është rezultati më i keq, sepse gjendja e ndërfaqes nuk njofton asgjë dhe trafiku i brendshëm del nga adresa burimore e gabuar. Nëse klienti i dytë mund të rilidhet drejtpërdrejt kur tuneli i jashtëm bie, çaktivizo atë rrugë ose lidhe me ndërfaqen e jashtme që dështimi të jetë i dukshëm.

Përfundo me dy rrjedha dhe një dump rregullash: një lidhje e shënuar dhe një e pashënuar duhet të ndjekin rrugë të ndryshme, dhe ip rule show duhet të listojë përparësinë që kishe ndërmend. Nëse të dyja rrjedhat ndjekin të njëjtën rrugë, shenja nuk po zbatohet atje ku mendon.