Blokket de ISP UDP, of is it de app yn 'e tunnel?

Immen meldt dat de VPN „UDP blokket“, en dy sin ferberget twa folslein ferskillende bewearingen. De iene giet oer it ferfier dat it tagongsnetwurk sjen kin, de oare oer de pakketten fan in applikaasje nei't se yn 'e tunnel ûntsifere binne. In fersifere tunnel kin fan bûten ôf filtere wurde sûnder hokker kaai dan ek, en in binnenste UDP-applikaasje kin mislearje om redenen dy't neat mei filterjen te krijen hawwe. Beslis hokker bewearing oft jo teste foardat jo bewiis sammelje.

Twa koppen, ien wurd

Yn in IPsec-ynstallaasje mei NAT-traversal is it bûtenste pakket UDP, adressearre tusken de twa VPN-einpunten, meastentiids op poarte 4500. Dêryn draacht de fersifere lading alles wat de tunnel trochstjoert, wat sels TCP of UDP wêze kin. It wurd UDP ferskynt dus twa kear, mei ferskillende betsjutting en ferskillende sichtberens.

In tuskenlizzend netwurk sjocht de bûtenste kop en neat fan 'e binnenste. It kin de bûtenste stream tastean, foarmje of weilitte, en it hoecht dêrfoar neat te ûntsiferjen. Dy asymmetry is de hiele reden dat de twa bewearingen trochinoar helle wurde: itselde wurd beskriuwt wat it netwurk filteret en wat de applikaasje stjoert. Skriuw de laach njonken it wurd telkens as jo in befinning fêstlizze, en de betizing ferdwynt foar it grutste part.

De binnenste kop wurdt pas sichtber by it ûntfangende einpunt, nei ûntsifering. Fan dat punt ôf wurdt it pakket trochstjoerd as elk oar, ûnder foarbehâld fan rûtes, belied en it eigen filterjen fan it einpunt. Dat binne aparte besluten dy't troch ferskillende apparaten nommen wurde.

Wat it netwurk noch sjen kin

Fersifering ferberget de lading en de binnenste ferfierkop, net it feit dat der in stream bestiet. Adressen fan einpunten, poarten, pakketgrutten en timing bliuwe sichtber, en dat is genôch om ferkear heuristysk te klassifisearjen of in bepaald doel te blokkearjen.

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

De earste opname lit de bûtenste stream op 'e fysike ynterface sjen, en de twadde de binnenste stream op 'e tunnel-ynterface. Beide tagelyk draaie beantwurdet de fraach direkt: as de bûtenste stream bestiet en de binnenste net, hat de applikaasje nea eat yn 'e tunnel stjoerd. As beide bestean en der komt neat werom, dan leit it probleem foarby de tunnel, by it doel of op 'e weromwei.

RFC 3948 beskriuwt de bûtenste UDP-ynkapseleing, en de ESP-spesifikaasje beskriuwt de beskerme yndieling dêryn. Gjin fan beide dokuminten ûnthjit dat in tagongsnetwurk de bûtenste stream trochlitte sil, en dêrom is it de muoite wurdich om in berikberensproef op 'e bûtenste tuple te dwaan foardat jo hokker teory oer de binnenste hawwe. In blokkearre bûtenste tuple jout in tunnel dy't nea foarmet, net in tunnel dy't foarmet en dan ien applikaasje ferliest.

Wêrom't ien UDP-app mislearret yn in wurkjende tunnel

In tunnel dy't in webapplikaasje draacht mar gjin UDP-applikaasje hat ferskate oannimlike ferklearrings, en it filterjen fan it binnenste protokol troch de ISP is net de earste. It meast foarkommende is dekking: de twa applikaasjes komme net beide yn deselde tunnel, om't de rûte nei it UDP-doel ûntbrekt of de split-tunnelregels fan 'e klant it útslute.

De twadde is it einpunt. In VPN-tsjinner dy't in protokollist tastean, in firewall by it doel, of in tsjinst dy't nea op 'e ferwachte poarte harket, se sille allegear in time-out jaan dy't der itselde útsjocht as in netwurkblokkade.

De tredde is pakketgrutte. UDP-applikaasjes stjoere faak gruttere datagrammen as in webfersyk, en ynkapseleing ferminderet de brûkbere MTU, sadat nei in slagge handshake stilte folgje kin by de earste folgrutte lading. Dat patroan is maklik ferkeard te lêzen as in blokkade, om't de lytse pakketten slagje en de grutte ferdwine. In flugge MTU-proef beslist it yn minder as in minút, en it antwurd is meastentiids in lytsere lading of in korrizjearre MSS, net in netwurkfilter.

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

It earste kommando testet oft in grut pakket it paad oerlibbet mei fragmintaasje útskeakele, wat in MTU-probleem fluch bleatleit. It twadde stjoert in lytse, beheinde UDP-stream en rapportearret ferlies en jitter. In stream dy't begjint en dan stilstiet wiist op grutte, net op in blokkade.

Rapportearje de laach, net it protokol

Skriuw de befinning yn ien fan trije foarmen: bûtenste ôflevering mislearre, binnenste trochstjoering mislearre, of de applikaasje mislearre. Elk hat in oare eigner, en se trochinoar helje stjoert it ticket nei it ferkearde team.

In lokale poarte feroarje kin gjin byhearrende listener oan 'e oare kant meitsje, dat in oplossing oan 'e klantkant dy't liket te helpen is meastentiids bewiis dat it oarspronklike doel ferkeard wie. Likegoed bewiist in levere alternatyf profyl wat oer berikberens en neat oer oft de applikaasje goed konfigurearre is.

Hâld konklúzje ek skieden fan waarnimming. Ferkearsanalyze kin suggerearje wat in stream is sûnder him te ûntsiferjen, en dat is in nuttige befinning, mar it is net deselde bewearing as it lêzen fan 'e binnenste kop. Jou oan hokker fan beide jo wier hawwe.