Blokkerer ISP-en UDP, eller er det appen inne i tunnelen?

Nokon rapporterer at VPN-en „blokkerer UDP“, og den setninga skjuler to heilt ulike påstandar. Den eine handlar om transporten aksessnettet kan sjå, den andre om pakkane til ein applikasjon etter at dei er dekrypterte inne i tunnelen. Ein kryptert tunnel kan filtrerast utanfrå utan nokon nøkkel, og ein indre UDP-applikasjon kan feile av grunnar som ikkje har noko med filtrering å gjere. Bestem kva påstand du testar før du samlar bevis.

To headerar, eitt ord

I ein IPsec-utrulling med NAT-traversal er den ytre pakken UDP adressert mellom dei to VPN-endepunkta, vanlegvis på port 4500. Innanfor ber den krypterte nyttelasta alt tunnelen vidaresender, og det kan sjølv vere TCP eller UDP. Ordet UDP førekjem derfor to gonger, med ulik tyding og ulik synlegheit.

Eit mellomliggande nettverk ser den ytre headeren og ingenting av den indre. Det kan tillate, forme eller droppe den ytre straumen, og det treng ikkje dekryptere noko for å gjere det. Den asymmetrien er heile grunnen til at dei to påstandane blir blanda saman: det same ordet skildrar det nettet filtrerer og det applikasjonen sender. Skriv laget ved sida av ordet kvar gong du registrerer eit funn, og forvirringa forsvinn stort sett.

Den indre headeren blir først synleg ved mottakande endepunkt, etter dekryptering. Frå det punktet blir pakken vidaresend som kvar annan, underlagd ruter, policy og filtreringa til endepunktet sjølv. Det er separate avgjerder tekne av ulike boksar.

Kva nettet framleis kan sjå

Kryptering skjuler nyttelast og den indre transportheaderen, ikkje det faktum at ein straum finst. Endepunktadresser, portar, pakkestorleikar og timing blir verande synlege, og det er nok til å klassifisere trafikk heuristisk eller blokkere ein bestemt destinasjon.

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

Den første opptaka viser den ytre straumen på det fysiske grensesnittet, og den andre viser den indre straumen på tunellgrensesnittet. Å køyre begge samtidig svarar på spørsmålet direkte: om den ytre straumen finst og den indre ikkje, har applikasjonen aldri sendt noko inn i tunnelen. Om begge finst og ingenting kjem tilbake, ligg problemet utanfor tunnelen, ved destinasjonen eller på returvegen.

RFC 3948 definerer den ytre UDP-innkapslinga, og ESP-spesifikasjonen definerer det verna oppsettet inni. Ingen av dei to dokumenta lovar at eit aksessnett vil sleppe den ytre straumen gjennom, og derfor er det verdt å køyre ein tilgjengelegheitstest på den ytre tuppelen før nokon teori om den indre. Ein blokkert ytre tuppel gir ein tunnel som aldri blir danna, ikkje ein tunnel som blir danna og deretter mistar éin applikasjon.

Kvifor éin UDP-app feilar inne i ein fungerande tunnel

Ein tunnel som ber ein webapplikasjon men ikkje ein UDP-applikasjon har fleire plausible forklaringar, og filtreringa av den indre protokollen frå ISP-en er ikkje den første. Den vanlegaste er dekning: dei to applikasjonane kjem ikkje begge inn i same tunnel, fordi ruta til UDP-destinasjonen manglar eller split-tunnel-reglane til klienten utelukkar henne.

Den andre er endepunktet. Ein VPN-server som tillèt ei protokolliste, ein brannmur ved destinasjonen eller ein teneste som aldri lyttar på den venta porten, vil alle gi ein tidsavbrot som ser identisk ut med ei nettverksblokkering.

Den tredje er pakkestorleik. UDP-applikasjonar sender ofte større datagram enn ein webførespurnad, og innkapsling reduserer den brukbare MTU-en, så eit vellukka handtrykk kan følgjast av stillheit på den første fullstore nyttelasta. Det mønsteret er lett å lese feil som ei blokkering, fordi dei små pakkane lukkast og dei store forsvinn. Ei rask MTU-prøve avgjer det på under eitt minutt, og svaret er vanlegvis ei mindre nyttelast eller ein korrigert MSS snarare enn eit nettverksfilter.

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

Den første kommandoen testar om ein stor pakke overlever vegen med fragmentering slått av, noko som avdekkjer eit MTU-problem raskt. Den andre sender ein liten, avgrensa UDP-straum og rapporterer tap og jitter. Ein straum som startar og deretter stoppar, peikar på storleik snarare enn på ei blokkering.

Rapporter laget, ikkje protokollen

Skriv funnet i ein av tre former: ytre levering mislukkast, indre vidaresending mislukkast, eller applikasjonen mislukkast. Kvar har ein ulik eigar, og å blande dei sender saka til feil team.

Å endre ein lokal port kan ikkje skape ein tilsvarande lyttar i den andre enden, så ein klient-side omveg som ser ut til å hjelpe er vanlegvis bevis på at den opphavlege destinasjonen var feil. På same måte beviser ein levert alternativ profil noko om tilgjengelegheit og ingenting om korvidt applikasjonen er rett konfigurert.

Hald slutninga skild frå observasjonen. Trafikkanalyse kan antyde kva ein straum er utan å dekryptere han, og det er eit nyttig funn, men det er ikkje den same påstanden som å lese den indre headeren. Oppgi kva av dei du faktisk har.