ISPak UDP blokeatzen du, edo tunel barruko aplikazioa da?
ISP batek kanpoko UDP garraioa baztertu dezake barneko goiburu zifratua irakurri gabe. Bereizi kanpoko entrega, barne birbidalketa eta aplikazioaren jokabidea.
Norbaitek VPNak «UDP blokeatzen du» salatzen du, eta esaldi horrek erabat desberdinak diren bi baieztapen ezkutatzen ditu. Bata sarbide-sareak ikus dezakeen garraioari buruzkoa da, bestea tunelaren barruan deszifratu ondorengo aplikazio baten paketeei buruzkoa. Tunel zifratu bat kanpotik filtratu daiteke gakorik gabe, eta barneko UDP aplikazio batek huts egin dezake filtratzearekin zerikusirik ez duten arrazoiengatik. Erabaki zein baieztapen ari zaren probatzen frogak bildu aurretik.
Bi goiburu, hitz bat
NAT-traversal duen IPsec inplementazio batean, kanpoko paketea UDP da, bi VPN muturren artean helbideratuta, normalean 4500 portuan. Horren barruan, karga zifratuak tunelak birbidaltzen duen guztia darama, eta hori bera TCP edo UDP izan daiteke. Beraz, UDP hitza bitan agertzen da, esanahi eta ikusgaitasun desberdinekin.
Bitarteko sare batek kanpoko goiburua ikusten du eta barneko ezer ez. Kanpoko fluxua onartu, moldatu edo baztertu dezake, eta ez du ezer deszifratu behar horretarako. Asimetria hori da bi baieztapenak nahasteko arrazoi osoa: hitz berak deskribatzen du sareak iragazten duena eta aplikazioak bidaltzen duena. Idatzi geruza hitzaren ondoan aurkitutakoa erregistratzen duzun bakoitzean, eta nahasmena ia desagertu egiten da.
Barneko goiburua hartzaile den muturrean soilik bihurtzen da ikusgai, deszifratu ondoren. Une horretatik aurrera paketea beste edozein bezala birbidaltzen da, ibilbideen, politikaren eta muturraren beraren iragazketaren mende. Erabaki bereiziak dira, gailu desberdinek hartuak.
Sareak oraindik zer ikus dezakeen
Zifratzeak karga eta barneko garraio-goiburua ezkutatzen ditu, fluxu bat dagoelako egitatea ez. Muturren helbideak, portuak, paketeen tamainak eta denborak ikusgai jarraitzen dute, eta hori nahikoa da trafikoa heuristikoki sailkatzeko edo helmuga zehatz bat blokeatzeko.
sudo tcpdump -ni eth0 'udp port 4500' sudo tcpdump -ni tun0 'udp port 5201'
Lehen kapturak kanpoko fluxua erakusten du interfaze fisikoan, eta bigarrenak barneko fluxua tunelaren interfazean. Biak aldi berean exekutatzeak galderari zuzenean erantzuten dio: kanpoko fluxua badago eta barnekoa ez, aplikazioak ez zuen ezer tunelera bidali. Biak badaude eta ezer itzultzen ez bada, arazoa tunelaz harago dago, helmugan edo itzulera-bidean.
RFC 3948 kanpoko UDP kapsulatzea definitzen du, eta ESP zehaztapenak haren barneko diseinu babestua definitzen du. Bi dokumentuetako batek ere ez du agintzen sarbide-sare batek kanpoko fluxua pasatuko duenik, eta horregatik merezi du kanpoko tuplaren gaineko irisgarritasun-proba bat egitea barnekoari buruzko edozein teoriaren aurretik. Blokeatutako kanpoko tupla batek inoiz eratzen ez den tunela sortzen du, ez eratu eta gero aplikazio bat galtzen duen tunela.
Zergatik huts egiten duen UDP aplikazio batek funtzionatzen ari den tunel baten barruan
Web aplikazio bat baina UDP aplikazio bat eramaten ez duen tunel batek hainbat azalpen sinesgarri ditu, eta ISPak barneko protokoloa iragaztea ez da lehena. Ohikoena estaldura da: bi aplikazioak ez dira tunel berean sartzen, UDP helmugarako ibilbidea falta delako edo bezeroaren tunel zatituaren arauek baztertu egiten dutelako.
Bigarrena muturra da. Protokolo-zerrenda onartzen duen VPN zerbitzari batek, helmugako suebaki batek edo espero den portuan inoiz entzuten ez duen zerbitzu batek denek itxaron-denbora sortuko dute, sare-blokeo baten berdin-berdina dirudiena.
Hirugarrena paketearen tamaina da. UDP aplikazioek web eskaera bat baino datagrama handiagoak bidaltzen dituzte sarritan, eta kapsulatzeak erabil daitekeen MTUa murrizten du, beraz esku-ukaldi arrakastatsu baten ondoren isiltasuna etor daiteke tamaina osoko lehen karga-irteeran. Eredu hori blokeo gisa oker irakurtzea erraza da, pakete txikiek arrakasta lortzen dutelako eta handiek desagertu egiten direlako. MTU proba azkar batek minutu bat baino gutxiagoan erabakitzen du, eta erantzuna normalean karga txikiagoa edo MSS zuzendua izaten da, ez sare-iragazkia.
ping -M do -s 1400 -c 2 10.60.0.20 iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5
Lehen komandoak pakete handi batek bidea gainditzen duen probatzen du fragmentazioa desgaituta, eta horrek MTU arazoa azkar agerian uzten du. Bigarrenak UDP fluxu txiki eta mugatua bidaltzen du eta galera eta jitter-ari buruzko berri ematen du. Hasi eta gero trabatzen den fluxu batek tamainari egiten dio keinu, ez blokeoari.
Eman geruza, ez protokoloa
Idatzi aurkitutakoa hiru formetako batean: kanpoko entrega huts egin zuen, barne birbidalketa huts egin zuen, edo aplikazioak huts egin zuen. Bakoitzak arduradun desberdina du, eta horiek nahasteak txartela talde okerrora bidaltzen du.
Portu lokal bat aldatzeak ezin du urruneko muturrean entzule egokirik sortu, beraz bezeroaren aldean laguntzen duen irtenbide bat froga izaten da jatorrizko helmuga okerra zela. Era berean, emandako profil alternatibo batek irisgarritasunari buruz zerbait frogatzen du eta aplikazioa behar bezala konfiguratuta dagoenari buruz ezer ez.
Mantendu inferentzia behaketatik bereizita. Trafikoaren analisiak fluxu bat zer den iradoki dezake deszifratu gabe, eta aurkikuntza erabilgarria da, baina ez da barneko goiburua irakurtzearen baieztapen bera. Adierazi zein duzun benetan.