OpenVPN 443an oraindik blokeatuta? Begiratu sareak zer ikuskatzen duen

Tunela etxeko lerrotik konektatzen da eta hotel edo bulegoko sare batean gelditzen da, eta zerbitzaria 443 portura eramateak ez zuen ezer aldatu. Emaitza hori nahikoa da forma bat izateko: portua zati erraza zen, eta erabakiaren gainerakoa bezeroaren eta zerbitzariaren artean dagoen guztiarena da. Bi galderak argitzen dituzte kasu gehienak, eta batek ere ez du zifratzeaz hitz egiten. Sareak onartzen du TLS esku-eman bat helbide horretara, eta bezeroak bere bilgarriranzko bide bat mantentzen du tunela altxatuta dagoen bitartean?

Esku-emanak zenbakia baino gehiago salatzen du

TCP 443ko VPN entzule natibo batek bere protokolo propioan hitz egiten du lehen paketetik. ClientHello batek bertsio-eremu bat, balio aleatorio bat eta luzapenen zerrenda bat ditu, eta ehunka byte irakurtzen dituen gailu batek aldea nabaritu dezake ezer deszifratu gabe. Portu-zenbakiak merkeak dira asetzeko, eta protokoloaren forma da iragazkiak benetan egiaztatzen duena. Arauak normalean protokolo bakoitzeko ere idazten dira, beraz TLS ikuskatzen duen politikak ezer ez du esaten UDPri buruz.

TLS saio baliodun bat eskatzen duen proxy garden batek konexioa uzten du ezarpenean zehar, askotan TCP esku-emana amaitu ondoren. Xehetasun horrek geroago du garrantzia, socket-a ezarri ondoren bezeroaren erregistroa gelditzen dela esan nahi duelako.

Fluxua bilgatzeak bi hutsegite-puntu sortzen ditu

stunnel bezalako TLS bilgarri batek espero zen forma berreskuratzen du: bezeroa tokiko entzule batera konektatzen da, bilgarriak benetako TLS saio bat irekitzen du zerbitzariarekin 443an, eta zerbitzariko bigarren bilgarri batek deszifratutako byteak VPN daemonari pasatzen dizkio. Kanpoko saioa orain beste edozein HTTPS konexio bezalakoa da. Zerbitzariko VPN daemonak loopbackean bakarrik entzun beharko luke, bilgarritik kanpo ezerk ez baitu hara iritsi behar.

Hiru gauza bereizi behar dira bat etor daitezen diseinu horretarako. Bezeroaren profilek tokiko entzulea seinalatzen du, zerbitzariaren ziurtagiriak bezeroak egiaztatzen duen izenarekin bat egiten du, eta zerbitzari aldeko birbidaltzeak daemonak benetan erabiltzen duen portua du helburu. Edozeinetan huts eginez gero, konexioa hil egiten da VPN geruza iritsi aurretik. Orduan ziurtagiri-desadostasuna bilgarriaren errore gisa agertzen da, ez VPN errore gisa, eta horregatik merezi du bi erregistroak elkarren ondoan irakurtzea.

Bilgarriranzko bidea da tranpa

Tunela altxatzean, bide lehenetsia hartara seinalatzen du, eta kanpoko TLS saioak eramaten duen tunelera sartzen ez den bide bat behar du. VPN bezero arrunt batek markatzen duen helbidea babesten du; bilgatutako bezero batek bere loopbacka markatzen du, beraz bilgarriaren helburu-helbidea ikusezina da babes horretarako.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Helbide zehatzak zuk bete behar dituzu, eta bideak konexioaren bizitza osoan zehar egon behar du, ez abioan bakarrik. Bezeroaren aurretik bidea gehitzen eta ondoren kentzen duen bilgarri script txiki bat gogoratutako komando bat baino fidagarriagoa da.

Androiden, salbuespen horren baliokidea aplikazio bakoitzeko ezarpena da: utzi bilgarri aplikazioa tunelatik kanpo, bere trafikoa mugikor konexioaren bidez irten dadin. Salbuespenik gabe, bilgarria eraiki nahi duen tunelera bideratzen da, eta berrikonexio begizta zerbitzariaren arazo bat ematen du.

Irakurri denbora-ezarpena ezer aldatu aurretik

Aldi berean tarte beraren ondoren hiltzen den saioa politika baten sinadura da, ez hutsegite kriptografikoa, eta epe luzeko fluxu-mugek hain zuzen ere eredu hori sortzen dute. Esku-emanaren ondoren berehala berrezartzen den konexioak ziurtagiri-katea gustuko ez zuen proxy bat iradokitzen du.

Konparatu ohiko HTTPS gune baten ziurtagiriaren jaulkitzailea bi sareetatik. Sare mugatuan jaulkitzailea desberdina bada, zerbait TLS amaitzen ari da erdian, eta inolako bilgarrik ez du atzemate hori aldaketarik gabe gaindituko. Konparazio berak esaten dizu blokeoak zure zerbitzariaren izena edo helbide horretako TLS saio guztiak duen helburu.

Idatzi ikusitako portaera: zenbat iraun zuen saioak, socket-a ireki zen, bilgarriak esku-eman bat erregistratu zuen. Horietako bakoitzak hurrengo proba estutzen du.

Proba ezazu aldagai bat aldi berean

Egiaztatu lehenengo UDP, sare batzuek erabat botatzen baitute eta UDP hutsegiteak ez baitu ezer esaten 443ri buruz. Gero probatu TCP 443 bilgarririk gabe, eta gero bilgarria 443an. Irakurri bezeroaren erregistroa urrats bakoitzean eta gelditu portaera aldatzen den bezain laster.

Aldatu elementu bat saiakerako. Portu berri bat, bilgarri berri bat eta zifratze berri bat txanda berean uzten zaitu hiruretatik zein izan zen garrantzitsua esan ezinik.