OpenVPN etxean dabil baina sare batean ez: UDP edo TCP?

Profil berak etxetik konektatzen du eta hotel, campus edo sukurtsal sare batean trabatzen da. Kredentzialak ez dira aldatu, beraz aldagai interesgarria bidea da: paketeei OpenVPN irakurri aurretik zer gertatzen zaien. Lau kausa posible probatu daitezkeen ordenan konparatzeak hobea da ziurtagiriei buruz asmatzea baino. Bakoitzak arrasto desberdina uzten du, eta arrastoa da horiek bereizten dituena.

Zein etapok huts egin zuen esaten du zein konparaziok duen garrantzia

Bezeroaren erregistroak dagoeneko jasotzen du noraino iritsi zinen. TLS gakoaren negoziazioa epemugaren barruan gertatu ez zela dioen lerroak lehen pakete bat atera zela eta ez zela ezer erabilgarririk itzuli esan nahi du, eta horrek bidera seinalatzen du. Ziurtagiri baten ezeztapenak ez du horren antzik: erantzun bat iristen da, eta gero egiaztatze-errore zehatz batek arrazoia izendatzen du. Ohartu berriro saiatzeko begizta aurreko azken lerroaz, hori baita sareen artean konparatzen duzun balioa.

Grabatu berriro saiatzen zaren bitartean, ez geroago. Bezeroan, tcpdump -ni any udp port 1194 ikusten du erantzunen bat bueltatzen den ala ez. Errepikatu zuk kontrolatzen duzun zerbitzari baten WAN interfazean, eta horrek erakusten du pakete horiek urrutiko muturrera iristen diren.

Alde bakarreko trafikoa da hemen eskuragarri dagoen emaitzarik erabilgarriena, kexa aldizkakoa ikerketa-norabide bihurtzen duelako. Gorde grabazio-fitxategiak, arazo beraren hurrengo txostena errazagoa baita frogekin ixtea deskribapen batekin baino.

UDP iragazketa ataka itxi baten aurka

Sarbide-sare askok UDP jarraitua susmagarritzat hartzen dute, eta zenbait hornitzaile ados daude. Ataka itxi batek isiltasun bera sortzen du bezeroaren aldetik. Desberdintasuna hautakortasuna da: iragazkiak joera du aukeratzen zein helmuga edo ataka botatzen dituen, ataka itxi batek ataka horretara zuzendutako guztia ukatzen duen bitartean.

443 atakako TCP profil bat ohiko irtenbidea da, HTTPS jario arrunt baten antza duelako eta captive atari eta irteera-iragazki gehienak pasatzen dituelako. Bi baldintza bete behar dira. Zerbitzariak proto tcp-server erabiliz entzun behar du eta bezeroak proto tcp-client erabiliz bat etorri behar du, eta operadoreak ordezko amaiera-puntu hori argitaratu behar du. Funtzionatzen duen UDP profil bat TCP 443 dela aldarrikatzeko berridazteak ez du inora eramaten beste muturrean inor entzuten ez badago.

Ataka itxi bat konfigurazio-arazoa da, ez zentsura-arazoa. Etxeko router baten atzean dagoen zerbitzari batek bere UDP ataka birbidalia behar du, eta routerraren suebakiak hori baimendu behar du. Ataka inoiz baimendu ez bada, bezero guztiek huts egiten dute negoziazioan kredentzialak edozein direla, eta hutsak zerbitzaria jarraitzen du, ez sarea.

Protokolo zaharrak gaizki konparatzen dira ardatz honetan. PPTP-k TCP 1723 gehi GRE behar ditu, eta GRE IP protokolo 47 da, ez ataka, beraz ataka-birbidalketa arrunt batek ez du hori adierazten.

Kommutadorea denean paketeak botatzen dituena

Kommutadore kudeatu batek tunela nahita bota dezake. HPE eta Aruba modelo batzuek UDP uholdearen aurkako babes-kontrol bat eskaintzen dute segurtasun aurreratuaren atalean, batzuetan Prevent UDP Blat Attack etiketarekin. Kontrol hori aktibo dagoenean, kommutadorearen atzeko zerbitzariak ez du ezer erantzuten eta bezero guztiak denbora-mugaraino iristen dira modu berean. Hori desgaitzea eta uneko konfigurazioa gordetzea da konponketa osoa, baina kommutadorea benetan bidean dagoela egiaztatu ondoren soilik.

Aurkako frogak dira kommutadorearen jaurtiketa hornitzailearen blokeotik bereizten dutenak. Irakurri interfazearen kontagailuak eta uholdearen aurkako babes-erregistroa ISParekin txartela ireki aurretik. DoS edo uholdearen aurkako babesa duten kontsumo-routerrek modu berean huts egiten dute, eta UDP geldialdi-denbora laburra duen bitarteko edozein gailuk ere bai. Inoiz amaitzen ez den eskuko heltze batek jaurtiketa iradokatzen du, eta minutu batzuetako isiltasunaren ondoren hiltzen den tunel batek denbora-muga.

Idatzi bezeroaren eta zerbitzariaren arteko gailu bakoitza profil bat aldatu aurretik. Geruza okerrean aplikatutako konponketa zuzena dirudi hurrengo sarera arte. Zerrenda horrek hurrengo ingeniariari non begiratu esaten dio, ikerketa osoa errepikatu gabe.

DNS hutsegite baten antza duen helbide-gainjartze bat

10.0.0.0/8 barruan zenbakitutako sarbide-sare batek tunelaren multzoarekin gainjar daiteke, eta ebazlea multzo horren barruan bizi ohi da. Ordenagailu eramangarri batek 10.184.178.50 bezalako helbide bat jasotzen duenean /8 maskararekin Wi-Fi sarean, 10.x helmuga bakoitza tokikoa da definizioz. 10.4.0.1 rako paketeak LANera joaten dira orduan, tunela altxatuta geratzen da, eta izenen ebazpenak huts egiten du.

ip addr gainjartzea begi-kolpean erakusten du, eta ip route get 10.4.0.1 paketea benetan nora entregatuko litzatekeen erakusten du. Ikusgai dagoen sintoma ebazlearen hutsegitea denez, honek sarritan DNS aldaketen hainbat txanda gainditzen ditu.

Zenbakitu berriro multzoa edo eduki sarbide-sare hori esparrutik kanpo. Bezeroaren aldeko ezarpen batek ere ez du gainjartze batetik berreskuratzen.

TCP ordezko baten eta bidearen konponketaren artean erabakitzea

Aukeratu TCP ordezkoa bidea kontrolatzen ez duzunean eta erabiltzaileek gaur lan egin behar dutenean, eta onartu bere kostuak: TCP TCP barruan gaizki portatzen da galerak dituzten loturetan, eta ordezkoak zuk kudeatzen duzun entzule bat behar du. Aukeratu bidearen konponketa blokeoa zurea den azpiegitura batean dagoenean, suebaki-arau bat bigarren entzule bat baino merkeagoa baita. Nolanahi ere, joan geruzak ordenan: esteka, kanpoko garraioa, negoziazioa, barne bideratzea. Sare horretan huts egin zuen etapa da axola duen gertaera bakarra.

Erregistratu emaitza sareka, ez erabiltzaileka. Hutsegite beraren hurrengo txostena etapa ezagun batetik hasten da orduan, ziurtagiri-teoria batetik beharrean. Erregistro horrek bigarren entzule iraunkor bat ere justifikatzen du, inoiz beharrezkoa bada.