Bi OpenVPN zerbitzaritako bezeroek elkar irits dezakete?

Bigarren OpenVPN zerbitzari bat altxatzeak bezeroak konektatzeko bigarren leku bat ematen dizu, eta ez gehiago. Ez ditu bezero horiek lehen zerbitzariaren sarean jartzen, eta client-to-client izeneko aukerak zerbitzari prozesu bakar baten barruko birbidalketa aldatzen du soilik. Bi multzoak sare bat bihurtzen dira haien artean nahita bideratzean, norabide bakoitzeko arduradun batekin. Beheko guztiak erabiltzaile-espazioko TUN modua suposatzen du barne birbidalketa hori itzalita, beraz nukleoak hartzen du erabakia.

Mitoa: kontu zerrenda bat, sare bat

Autentifikazioa eta irisgarritasuna nahasten dira, biak zerbitzariaren konfigurazioan bizi direlako. Bi pasabideetako edozeinetan saioa has dezakeen erabiltzaile bat, kanpotik, bi ate dituen sistema bakarreko erabiltzaile gisa ikusten da. Barruan, zerbitzari bakoitzak bere multzotik helbideak banatzen ditu eta berak amaitzen dituen bezeroentzat bakarrik instalatzen ditu bideak. Beraz, A pasabideko bezero batek B pasabideko bezero bati paketea bidaltzean, bere zerbitzariak inoiz entzun ez duen helmuga bat eskatzen du. Paketea A-ren bide lehenetsira doa, tunela uzten du eta inoiz baimena eskatu ez zitzaion suebaki batera iristen da.

Bigarren zerbitzari bat gehitzeak, beraz, ez ditu erredundantzia, aurkikuntza edo difusio domeinu partekatua gehitzen. Plana behar duen bideratutako sare bat gehitzen du, eta plana helbideratzearekin hasten da.

Eman pasabide bakoitzari bere multzoa eta transituko helbidea

Beste ezerkin gainjarri ezin diren bi barruti, eta ostalarien arteko transitu esteka txiki bat, hori da helbide plan osoa. Mantendu transitua kontrolatzen duzun segmentu pribatu batean, eta idatzi zenbakiak zerbitzariren batek alokairua eman aurretik.

Erresistitu bi zerbitzariei multzo bera emateko tentazioari, profilek berdin jarrai dezaten. Nukleoko bide batek ezin du esan bi ostalarietatik zeinek duen gaur egun barruti partekatu bateko edozein helbide, beraz bideratze taulak pasabide bat seinalatuko luke eta bezeroa besteari lotuta egon liteke. Interfaze izenak tokiko konbentzioak dira, ez egoera partekatua. Hemen bi ostalariek tun0 deitzen diote tunel gailuari eta transit0 transitu estekari, eta hori ondo dago, inongo paketek ez baitituzte izen horiek eramaten.

Instalatu bidea bi aldeetan

Pasabide bakoitzak bestearen multzorako bide bat behar du transitu helbidetik, eta birbidalketa piztuta egon behar da edozeinek jauzi gisa jardun dezan. Egiaztatu lehenik uneko taula, gero gehitu sarrera eta iraunarazi ostalariaren sare kudeatzailearen bidez, berriz konektatzeko kako baten ordez.

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

Ispilatu hori beste ostalarian multzoak trukatuta. Bide bera script ez-erlazionatu batetik behin eta berriz gehitzea da ostalari batek hainbat kopia eta hurrengoan norbaitek taula irakurtzean aldaketa misteriotsu bat izateko modua. Transitu esteka bera tunel bat bada, bideak tunel horren topologiara seinalatzen du eta jauziak berriz konektatzea gainditu behar du. Hogeita hamar segundoz desagertzen den transitu helbide batek multzoen arteko bidea eramaten du berarekin, eta hori diseinu ezaugarri bat da, aurkitu beharrean adieraztea merezi duena.

Bultzatu bezeroaren bidea jabetza faltsutu gabe

Bezeroek urruneko multzorako bide bat behar dute, bestela haien sistema eragileak paketea bere pasabide lehenetsira bidaltzen du eta tunelak ez du inoiz ikusten. Zerbitzariaren konfigurazioa da hori emateko leku naturala.

push "route 10.64.20.0 255.255.255.0"

Jarri ispilu lerroa beste zerbitzariaren konfigurazioan, gero berriz konektatu probako bezero bat eta irakurri haren taula. Bultzatutako bideak alde batera uzten dituen bezeroak bere konfigurazio onartua behar du, eta inoiz iristen ez den bide bat ez da sarbide kontrola. Ez eman bezero bati iroute beste pasabidearen multzo osorako. Zuzentarau hori konektatutako bezero baten atzeko azpisare baterako dago, eta pasabideen arteko falta den bide bat estaltzeko erabiltzeak sortzen du iritsi ezin dituen helbideak dituela uste duen zerbitzaria.

Frogatu eskaera bat eta ukatu beste bat

Aukeratu eragiketa erreal bat, adibidez HTTPS 10.64.10.21-eko bezero batetik 10.64.20.37-ko zerbitzu batera, eta baimendu zehazki hori bi ostalarietan. Suebaki bakoitzak eskaera sarrerako aldean onartzen du eta jarraitutako erantzuna itzultzeko aldean; helmugaren zerbitzu politikak oraindik onartu behar du.

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

Elkarrekiko bideekin, iturri NAT alferrikakoa da eta hemen aktiboki kaltegarria: iturria itzultzeak ezkutatzen du zein bezerok egin zuen eskaera eta helmugaren aldeko iturri oinarritutako politika gainditzen du. Egiaztatu internet irteerarako masquerade arau batek bide hau ere ez duela harrapatzen. Gero probatu ukoa. B multzoan lokal geratu behar duen zerbitzu bat A multzotik iristen ezinean egon behar da, eta pasabide bereko bezero bikoteak ere probatu behar dira, orain aldatu duzun birbidalketa politika haiei ere aplikatzen baitzaie.

Beste zuzenketa bat buruko ereduan: transitu estekak deskifratutako barne paketeak daramatza, beraz konfiantza muga da eta ez berme pribatua. Kontrolatzen ez duzun sare bat zeharkatzen badu, babestu jauzi hori onartutako tunel zifratu batekin eta bideratu haren topologia errealetik. Muturretik muturrerako TLSek aplikazioa bere kabuz autentifikatzen du oraindik, eta horregatik zerbitzu barnekoak hura erabiltzen jarraitu behar du.