A e bllokon ISP-ja UDP-në, apo është aplikacioni brenda tunelit?

Dikush raporton se VPN-ja „bllokon UDP-në“, dhe kjo frazë fsheh dy pretendime krejt të ndryshme. Njëri ka të bëjë me transportin që rrjeta e aksesit mund të shohë, tjetri me paketat e një aplikacioni pasi dekriptohen brenda tunelit. Një tunel i kriptuar mund të filtrohet nga jashtë pa asnjë çelës, dhe një aplikacion UDP i brendshëm mund të dështojë për arsye që nuk kanë asnjë lidhje me filtrimin. Vendosni cilin pretendim po testoni përpara se të mblidhni prova.

Dy koka, një fjalë

Në një vendosje IPsec me NAT-traversal, paketa e jashtme është UDP e adresuar midis dy pikave fundore të VPN-së, zakonisht në portën 4500. Brenda saj, ngarkesa e kriptuar mbart gjithçka që tuneli përcjell, e cila mund të jetë vetë TCP ose UDP. Fjala UDP pra shfaqet dy herë, me kuptim dhe dukshmëri të ndryshme.

Një rrjet i ndërmjetëm sheh kokën e jashtme dhe asgjë nga ajo e brendshme. Ai mund të lejojë, të formësojë ose të hedhë poshtë rrjedhën e jashtme, dhe nuk ka nevojë të dekriptojë asgjë për ta bërë këtë. Pikërisht kjo asimetri është e gjithë arsyeja pse dy pretendimet ngatërrohen: e njëjta fjalë përshkruan atë që filtron rrjeta dhe atë që dërgon aplikacioni. Shkruani shtresën pranë fjalës sa herë që regjistroni një gjetje, dhe konfuzioni kryesisht zhduket.

Koka e brendshme bëhet e dukshme vetëm në pikën fundore marrëse, pas dekriptimit. Nga ai moment paketa përcjellët si çdo tjetër, në varësi të rrugëve, politikës dhe filtrimit të vetë pikës fundore. Këto janë vendime të ndara që merren nga pajisje të ndryshme.

Çfarë mund të shohë ende rrjeta

Kriptimi fsheh ngarkesën dhe kokën e transportit të brendshëm, jo faktin që ekziston një rrjedhë. Adresat e pikave fundore, portat, madhësitë e paketave dhe koha mbeten të dukshme, dhe kjo mjafton për të klasifikuar trafikun në mënyrë heuristike ose për të bllokuar një destinacion të caktuar.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

Kapja e parë tregon rrjedhën e jashtme në ndërfaqen fizike, dhe e dyta tregon rrjedhën e brendshme në ndërfaqen e tunelit. Ekzekutimi i të dyjave njëkohësisht i përgjigjet pyetjes drejtpërdrejt: nëse rrjedha e jashtme ekziston dhe ajo e brendshme jo, aplikacioni nuk ka dërguar kurrë asgjë në tunel. Nëse të dyja ekzistojnë dhe asgjë nuk kthehet, problemi është përtej tunelit, në destinacion ose në rrugën e kthimit.

RFC 3948 përcakton enkapsulimin e jashtëm UDP, dhe specifikimi ESP përcakton paraqitjen e mbrojtur brenda tij. Asnjëri prej dy dokumenteve nuk premton se një rrjet aksesi do ta kalojë rrjedhën e jashtme, prandaj vlen të ekzekutohet një provë arritshmërie mbi tuple-n e jashtme përpara çdo teorie për atë të brendshme. Një tuple e jashtme e bllokuar prodhon një tunel që nuk formohet kurrë, jo një tunel që formohet dhe pastaj humbet një aplikacion.

Pse një aplikacion UDP dështon brenda një tuneli që funksionon

Një tunel që mbart një aplikacion web por jo një aplikacion UDP ka disa shpjegime të besueshme, dhe filtrimi i protokollit të brendshëm nga ISP-ja nuk është i pari. Më i zakonshmi është mbulimi: të dy aplikacionet nuk hyjnë të dy në të njëjtin tunel, sepse mungon rruga drejt destinacionit UDP ose rregullat e tunelit të ndarë të klientit e përjashtojnë atë.

I dyti është pika fundore. Një server VPN që lejon një listë protokollesh, një mur zjarri në destinacion ose një shërbim që nuk dëgjon kurrë në portën e pritur do të prodhojnë të gjithë një afat të skaduar që duket identik me një bllokim rrjeti.

I treti është madhësia e paketës. Aplikacionet UDP shpesh dërgojnë datagrame më të mëdha se një kërkesë web, dhe enkapsulimi zvogëlon MTU-në e përdorshme, kështu që pas një shtrëngimi duarsh të suksesshëm mund të vijë heshtje në ngarkesën e parë me madhësi të plotë. Ky model lexohet lehtë gabimisht si bllokim, sepse paketat e vogla kalojnë dhe ato të mëdha zhduken. Një provë e shpejtë MTU e zgjidh çështjen në më pak se një minutë, dhe përgjigjja zakonisht është një ngarkesë më e vogël ose një MSS i korrigjuar, jo një filtër rrjeti.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

Komanda e parë teston nëse një paketë e madhe i mbijeton rrugës me fragmentimin e çaktivizuar, gjë që zbulon shpejt një problem MTU. E dyta dërgon një rrjedhë UDP të vogël dhe të kufizuar dhe raporton humbje dhe jitter. Një rrjedhë që fillon dhe pastaj ndalon tregon madhësinë, jo një bllokim.

Raportoni shtresën, jo protokollin

Shkruani gjetjen në një nga tre format: dorëzimi i jashtëm dështoi, përcjellja e brendshme dështoi, ose aplikacioni dështoi. Secila ka një pronar të ndryshëm, dhe përzierja e tyre e dërgon biletën te ekipi i gabuar.

Ndryshimi i një porte lokale nuk mund të krijojë një dëgjues përkatës në skajin e largët, prandaj një zgjidhje anashkaluese në anën e klientit që duket se ndihmon është zakonisht provë se destinacioni origjinal ishte i gabuar. Po ashtu, një profil alternativ i ofruar provon diçka për arritshmërinë dhe asgjë për atë nëse aplikacioni është konfiguruar saktë.

Mbajeni konkluzionin të ndarë nga vëzhgimi. Analiza e trafikut mund të sugjerojë çfarë është një rrjedhë pa e dekriptuar, dhe kjo është një gjetje e dobishme, por nuk është i njëjti pretendim si leximi i kokës së brendshme. Tregoni cilën prej tyre e keni në të vërtetë.