Bi DNS izen, OpenVPN ataka bat: zer aukeratzen duen benetan

Bi A erregistro, helbide bat, deabru bat: erabiltzaileak idatz dezakeen izena idatzita ere, iristen den paketea berbera da, eta 1194 atakari lotutako prozesuak ez du biak bereizteko ezer. Hau ez da konpondu zain dagoen konfigurazio oker bat; izenen bilaketak adieraz dezakeenaren muga da. Bi OpenVPN instantziaren artean aukeratzen duen edozer bezeroak konexioan jartzen duen eta frontendak berriro irakur dezakeen balio bat izan behar da, eta OpenVPN bezero estandar batek ez du halako baliorik agerian jartzen. Hurrengoak erakusten du horrek non uzten zaituen, eta zein antolamenduk bereizten duen trafikoa benetan.

Hasi resolverrak itzultzen duenarekin

Bezero batek vpn-a.example eskatzen du eta helbide bat jasotzen du; helbide hori gehi ataka bat da markatzen duen guztia. Izena lokalean gastatzen da, bilaketan zehar, eta ez da inoiz hari gaineko eremu bihurtzen, beraz beste muturreko entzuleak ezin du ikusi zein etiketa erabili zen. Bideratu vpn-a.example eta vpn-b.example ostalari berera eta bi bilaketek helmuga bera emango dute, eta horregatik deabruak bi konexioak instantzia bakarrean xurgatzen ditu aldea erregistratu gabe. Helbidean oinarritutako profilek izenean oinarritutakoek bezalaxe jokatzen dute, arrazoi berarengatik.

Horrek irtenbide tentagarrien familia bat ere ixten du: alias gehigarriak, socket bakarrean izen bakoitzeko ziurtagiria aukeratzea edo galdetu den izenari lotutako suebaki-arau bat. Horietako batek ere ezin du jada baztertutako informazioaren gainean jardun, lehen paketeak bezeroa utzi aurretik. Bi zerbitzari bereizita egon behar badira, banaketak konexioarekin batera bidaiatu behar du, hau da, helbide bat, ataka bat edo protokoloak definitzen duen karga-eremu bat.

Kontatzen den hautatzaile bakarra paketearen barruan doa

HTTPk Host goiburu batekin konpontzen du, eta TLSk ClientHello-n zerbitzari-izen luzapen batekin, eta horrela helbide batek gune asko zerbitzatzen ditu entzule baten atzean. Biek funtzionatzen dute hari gaineko protokoloak zerbitzu zehatz baterako eskaera daramalako. OpenVPNi buruzko datu garrantzitsua da bi eremu horietako bat ere ez dagoela bitarteko kutxa batek aztertzen duen mailan.

Antolamendu estandarrean kontrol-kanala babesten duen TLS eskuko elkarrizketa kanpoko saioa ezarri ondoren gertatzen da eta haren barruan eramaten da, beraz saio hura amaitu ez duen entzule batek fluxu opaku bat ikusten du. Oraindik esan dezake OpenVPN dela, hasierako byteetan opcodea eta markoa ezagutzekoak baitira, baina zerbitzari-izena, existitzen bada, zifratutako atalean dago. Kanpoko paketetik ostalari birtuala irakurtzea espero duen diseinu batek protokoloak inoiz han idazten ez duen eremu bat irakurtzen ari da. Hori tunela nola eraikita dagoenetik dator, patroi-konparaketa argiago batek itxi zezakeen hutsune batetik baino.

Non gelditzen den protokolo-banatzaile bat

sslh proiektuak dokumentatzen duen motako multiplexadoreak ataka bakarrean entzuten du, hasierako byteak aztertzen ditu eta konexioa ezagutu duen protokoloa hitz egiten duen backendari ematen dio. Hori benetako balioa da ataka bakar batek SSH, HTTPS eta OpenVPN elkarrekin zerbitzatu behar dituenean.

sslhk protokolo bakoitzeko sonda bereizia mantentzen du, eta haren TLS sonda gai da ClientHello benetako batetik zerbitzari-izen bat edo ALPN balio bat ateratzeko. OpenVPN natiboa ezagutzea TLS luzapen bat irakurtzea ez bezalako sailkapena da, eta biak ez dira konbinatzen, entzun-socketari inoiz ClientHello bidaltzen ez dion bezeroak sonda irakurtzeko ezer gabe uzten baitu. Beraz, OpenVPNekin bat datorren arau batek “OpenVPN bezero bat da hau” erantzuten du eta ez doa harago. Arau horren atzean dauden bi OpenVPN backend bereizezinak dira, frontendak ez du aukeratzeko oinarririk, eta saio bakoitza leku berean lurreratzen da. Multiplexatzeak ataka bat partekatzen du zerbitzu ezberdinen artean; ez du hosting birtualik egiten zerbitzu baten barruan.

Bi zerbitzari benetan bereizten dituzten antolamenduak

Bereizketa zintzo merkeena bigarren helbide publiko bat da, bata instantzia bakoitzeko, eta lehendik dauden profilek behar dena dakarte jada helbide ezberdinetara baitoaz. Hurrengoa helbide berean ataka ezberdin bat da, eta horrek profil bakoitzean zenbaki bat baino ez du kostatzen. TCPk eta UDPk ataka-taulak bereizita mantentzen dituzte, beraz 1194/tcp eta 1194/udp socket erlazionatu gabeak dira eta bakoitzetik bat elkarrekin egon daiteke ostalari berean; hori garraio-bereizketa da eta ez izen-bideratzea, eta sarritan nahasten da harekin. Bi aukerak suebaki-berrikuspen bat gainditzen dute, arauak paketeak benetan duen zerbaiti egiten baitio bat.

Behar duzun muga bi inplementazioren artean beharrean erabiltzaile-taldeen artean doa, bertsio batek bezero-konfigurazio ezberdinekin, bere ziurtagiri-kudeaketarekin eta sarbide-politika espresu batekin estal dezake. Horrek zerbitzari baten barruko politika erosten du, ez zerbitzarien arteko isolamendua, eta biak eskakizun ezberdinak dira. Konpromisoaren pean eutsi behar duen isolamenduak helbidea edo suebakiaren ertza behar ditu oraindik.

OpenVPNren aurrean jarritako TLS amaitzaile batek benetako zerbitzari-izena erakuts diezaioke frontend gai bati, baina bezeroaren aldea ere geruza gehigarri horretarako konfiguratuta dagoenean soilik. Lehendik dauden profilek ez dute portaera hori lortzen helbide berera bideratuta.

Frogatu hautatzailea eraiki aurretik

Izendatu backend bat identifikatuko duen eremua, eta gero egiaztatu bezeroak benetan bidaltzen duela; erantzuna helbide bat bada, planak eusten du, eta entzulera inoiz iristen ez den eskuko elkarrizketa baten barruko zerbitzari-izena bada, DNS lanik ez du salbatuko. Hiru komandok entzulearen aldea azkar konpontzen dute.

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

openssl lerroak ziurtagiri bat ematen du helbide horretan zerbait TLS amaitzen duen tokian soilik; OpenVPN entzule natiboaren aurka trabatu edo huts egiten du, eta hori bera da kanpoko geruzak zer erakusten duen erantzuna. journal lerroak, backend bakoitzean irakurrita, erakusten du zein instantziak onartu zuen saioa. Frontendaren erregistroek sailkatu zena idazten dute eta inoiz ez zegoena, beraz backend-a da erabiltzailea non lurreratu zen jakiteko autoritate bakarra.

Amaitu zerbitzari ezberdinak lortzeko pentsatutako bi profilekin, konektatu batak bestea eta idatzi backend erregistroa bakoitzarentzat. Bi saioak journal berean agertzen badira, hautatzailea falta da gaizki konfiguratuta egon beharrean, eta konponbidea bezeroak helbidera dezakeen helbide edo ataka bat da. Bideratze-araua editatzeak ez du lagunduko, arauari inoiz ez zaiolako ezer eman bideratzeko. Banaketa erreala denean, idatzi profileen ondoan, hurrengo pertsonak bigarren alias bat gehitu eta lan hori egingo duela espero ez dezan.