Blokerer udbyderen UDP, eller er det appen inde i tunnelen?

Nogen rapporterer, at VPN'en »blokerer UDP«, og den sætning skjuler to helt forskellige påstande. Den ene handler om den transport, adgangsnettet kan se, den anden om en applikations pakker, efter de er dekrypteret inde i tunnelen. En krypteret tunnel kan filtreres udefra uden nogen nøgle, og en indre UDP-applikation kan fejle af grunde, der intet har med filtrering at gøre. Afgør, hvilken påstand du tester, før du indsamler beviser.

To headers, ét ord

I en IPsec-udrulning med NAT-traversal er den ydre pakke UDP adresseret mellem de to VPN-endepunkter, typisk på port 4500. Indeni bærer den krypterede nyttelast alt, hvad tunnelen videresender, hvilket selv kan være TCP eller UDP. Ordet UDP optræder derfor to gange med forskellig betydning og forskellig synlighed.

Et mellemliggende netværk ser den ydre header og intet af den indre. Det kan tillade, forme eller droppe den ydre strøm, og det behøver ikke dekryptere noget for at gøre det. Den asymmetri er hele grunden til, at de to påstande blandes sammen: det samme ord beskriver, hvad netværket filtrerer, og hvad applikationen sender. Skriv laget ved siden af ordet, hver gang du registrerer et fund, og forvirringen forsvinder stort set.

Den indre header bliver først synlig ved det modtagende endepunkt, efter dekryptering. Fra det punkt videresendes pakken som enhver anden, underlagt ruter, politik og endepunktets egen filtrering. Det er separate beslutninger, som træffes af forskellige bokse.

Hvad netværket stadig kan se

Kryptering skjuler nyttelast og den indre transportheader, ikke det faktum, at der findes en strøm. Endepunktsadresser, porte, pakkestørrelser og timing forbliver synlige, og det er nok til at klassificere trafik heuristisk eller blokere en bestemt destination.

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

Den første optagelse viser den ydre strøm på det fysiske interface, og den anden viser den indre strøm på tunnel-interfacet. At køre begge samtidigt besvarer spørgsmålet direkte: hvis den ydre strøm findes, og den indre ikke gør, har applikationen aldrig sendt noget ind i tunnelen. Hvis begge findes, og der ikke kommer noget tilbage, ligger problemet ud over tunnelen, ved destinationen eller på returvejen.

RFC 3948 definerer den ydre UDP-indkapsling, og ESP-specifikationen definerer det beskyttede layout indeni. Ingen af dokumenterne lover, at et adgangsnetværk vil føre den ydre strøm igennem, og derfor er det værd at køre en tilgængelighedstest på den ydre tuple, før man har nogen teori om den indre. En blokeret ydre tuple giver en tunnel, der aldrig dannes, ikke en tunnel, der dannes og derefter mister én applikation.

Hvorfor én UDP-app fejler inde i en fungerende tunnel

En tunnel, der bærer en webapplikation men ikke en UDP-applikation, har flere plausible forklaringer, og udbyderens filtrering af den indre protokol er ikke den første. Den mest almindelige er dækning: de to applikationer kommer ikke begge ind i den samme tunnel, fordi ruten til UDP-destinationen mangler, eller fordi klientens split-tunnel-regler udelukker den.

Den anden er endepunktet. En VPN-server, der tillader en protokol liste, en firewall ved destinationen eller en tjeneste, der aldrig lytter på den forventede port, vil alle give en timeout, der ser identisk ud med en netværksblokering.

Den tredje er pakkestørrelse. UDP-applikationer sender ofte større datagrammer end en webanmodning, og indkapsling reducerer den brugbare MTU, så et fungerende handshake kan følges af tavshed ved den første nyttelast i fuld størrelse. Det mønster er let at læse forkert som en blokering, fordi de små pakker lykkes, og de store forsvinder. En hurtig MTU-test afgør det på under et minut, og svaret er som regel en mindre nyttelast eller en rettet MSS snarere end et netværksfilter.

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 kommando tester, om en stor pakke overlever vejen med fragmentering slået fra, hvilket hurtigt afslører et MTU-problem. Den anden sender en lille, afgrænset UDP-strøm og rapporterer tab og jitter. En strøm, der starter og derefter går i stå, peger på størrelse snarere end på en blokering.

Rapportér laget, ikke protokollen

Skriv fundet i en af tre former: ydre levering fejlede, indre videresendelse fejlede, eller applikationen fejlede. Hver har en forskellig ejer, og at blande dem sender billetten til det forkerte team.

At ændre en lokal port kan ikke skabe en tilsvarende lytter i den anden ende, så en klient-side workaround, der ser ud til at hjælpe, er som regel bevis på, at den oprindelige destination var forkert. Ligeledes beviser en leveret alternativ profil noget om tilgængelighed og intet om, hvorvidt applikationen er konfigureret korrekt.

Hold slutning adskilt fra observation. Trafikanalyse kan antyde, hvad en strøm er, uden at dekryptere den, og det er et nyttigt fund, men det er ikke den samme påstand som at læse den indre header. Angiv, hvilken af dem du faktisk har.