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

Noen rapporterer at VPN-en „blokkerer UDP“, og den setningen skjuler to helt forskjellige påstander. Den ene handler om transporten aksessnettet kan se, den andre om en applikasjons pakker etter at de er dekryptert inne i tunnelen. En kryptert tunnel kan filtreres utenfra uten noen nøkkel, og en indre UDP-applikasjon kan feile av grunner som ikke har noe med filtrering å gjøre. Bestem hvilken påstand du tester før du samler bevis.

To headere, ett ord

I en IPsec-utrulling med NAT-traversal er den ytre pakken UDP adressert mellom de to VPN-endepunktene, vanligvis på port 4500. Inni den bærer den krypterte nyttelasten alt tunnelen videresender, og det kan selv være TCP eller UDP. Ordet UDP forekommer derfor to ganger, med ulik betydning og ulik synlighet.

Et mellomliggende nettverk ser den ytre headeren og ingenting av den indre. Det kan tillate, forme eller droppe den ytre strømmen, og det trenger ikke dekryptere noe for å gjøre det. Den asymmetrien er hele grunnen til at de to påstandene blandes sammen: det samme ordet beskriver det nettet filtrerer og det applikasjonen sender. Skriv laget ved siden av ordet hver gang du registrerer et funn, og forvirringen forsvinner stort sett.

Den indre headeren blir først synlig ved mottakende endepunkt, etter dekryptering. Fra det punktet videresendes pakken som enhver annen, underlagt ruter, policy og endepunktets egen filtrering. Det er separate beslutninger tatt av forskjellige bokser.

Hva nettet fortsatt kan se

Kryptering skjuler nyttelast og den indre transportheaderen, ikke det faktum at en strøm finnes. Endepunktadresser, porter, pakkestørrelser og timing forblir synlige, og det er nok til å klassifisere trafikk heuristisk eller blokkere en bestemt destinasjon.

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

Den første opptaket viser den ytre strømmen på det fysiske grensesnittet, og det andre viser den indre strømmen på tunellgrensesnittet. Å kjøre begge samtidig svarer på spørsmålet direkte: hvis den ytre strømmen finnes og den indre ikke, har applikasjonen aldri sendt noe inn i tunnelen. Hvis begge finnes og ingenting kommer tilbake, ligger problemet utenfor tunnelen, ved destinasjonen eller på returveien.

RFC 3948 definerer den ytre UDP-innkapslingen, og ESP-spesifikasjonen definerer det beskyttede oppsettet inni. Ingen av de to dokumentene lover at et aksessnett vil slippe den ytre strømmen gjennom, og derfor er det verdt å kjøre en tilgjengelighetstest på den ytre tuppelen før noen teori om den indre. En blokkert ytre tuppel gir en tunnel som aldri dannes, ikke en tunnel som dannes og deretter mister én applikasjon.

Hvorfor én UDP-app feiler inne i en fungerende tunnel

En tunnel som bærer en webapplikasjon men ikke en UDP-applikasjon har flere plausible forklaringer, og ISP-ens filtrering av den indre protokollen er ikke den første. Den vanligste er dekning: de to applikasjonene kommer ikke begge inn i samme tunnel, fordi ruten til UDP-destinasjonen mangler eller klientens split-tunnel-regler utelukker den.

Den andre er endepunktet. En VPN-server som tillater en protokollliste, en brannmur ved destinasjonen eller en tjeneste som aldri lytter på den forventede porten, vil alle gi en tidsavbrudd som ser identisk ut med en nettverksblokkering.

Den tredje er pakkestørrelse. UDP-applikasjoner sender ofte større datagrammer enn en webforespørsel, og innkapsling reduserer den brukbare MTU-en, så et vellykket håndtrykk kan følges av stillhet på den første fullstore nyttelasten. Det mønsteret er lett å lese feil som en blokkering, fordi de små pakkene lykkes og de store forsvinner. En rask MTU-prøve avgjør det på under et minutt, og svaret er vanligvis en mindre nyttelast eller en korrigert MSS snarere enn et 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 tester om en stor pakke overlever veien med fragmentering slått av, noe som avdekker et MTU-problem raskt. Den andre sender en liten, avgrenset UDP-strøm og rapporterer tap og jitter. En strøm som starter og deretter stopper, peker på størrelse snarere enn på en blokkering.

Rapporter laget, ikke protokollen

Skriv funnet i en av tre former: ytre levering mislyktes, indre videresending mislyktes, eller applikasjonen mislyktes. Hver har en forskjellig eier, og å blande dem sender saken til feil team.

Å endre en lokal port kan ikke skape en tilsvarende lytter i den andre enden, så en klient-side omvei som ser ut til å hjelpe er vanligvis bevis på at den opprinnelige destinasjonen var feil. På samme måte beviser en levert alternativ profil noe om tilgjengelighet og ingenting om hvorvidt applikasjonen er riktig konfigurert.

Hold slutningen atskilt fra observasjonen. Trafikkanalyse kan antyde hva en strøm er uten å dekryptere den, og det er et nyttig funn, men det er ikke den samme påstanden som å lese den indre headeren. Oppgi hvilken av dem du faktisk har.