Blockerar ISP:n UDP, eller är det appen inne i tunneln?

Någon rapporterar att VPN:en „blockerar UDP“, och den meningen döljer två helt olika påståenden. Det ena handlar om transporten som åtkomstnätet kan se, det andra om en applikations paket efter att de dekrypterats inne i tunneln. En krypterad tunnel kan filtreras utifrån utan någon nyckel, och en inre UDP-applikation kan misslyckas av skäl som inte har något med filtrering att göra. Bestäm vilket påstående du testar innan du samlar bevis.

Två huvuden, ett ord

I en IPsec-driftsättning med NAT-traversal är det yttre paketet UDP adresserat mellan de två VPN-ändpunkterna, vanligtvis på port 4500. Inuti bär den krypterade nyttolasten allt som tunneln vidarebefordrar, och det kan i sig vara TCP eller UDP. Ordet UDP förekommer därför två gånger, med olika betydelse och olika synlighet.

Ett mellanliggande nätverk ser det yttre huvudet och ingenting av det inre. Det kan tillåta, forma eller släppa den yttre strömmen, och det behöver inte dekryptera något för att göra det. Den asymmetrin är hela anledningen till att de två påståendena blandas ihop: samma ord beskriver vad nätet filtrerar och vad applikationen skickar. Skriv lagret bredvid ordet varje gång du registrerar ett fynd, och förvirringen försvinner till största delen.

Det inre huvudet blir synligt först vid den mottagande ändpunkten, efter dekryptering. Från den punkten vidarebefordras paketet som vilket annat som helst, beroende på rutter, policy och ändpunktens egen filtrering. Det är separata beslut som fattas av olika enheter.

Vad nätet fortfarande kan se

Kryptering döljer nyttolast och det inre transporthuvudet, inte det faktum att en ström finns. Ändpunktsadresser, portar, paketstorlekar och timing förblir synliga, och det räcker för att klassificera trafik heuristiskt eller blockera en viss destination.

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

Den första fångsten visar den yttre strömmen på det fysiska gränssnittet, och den andra visar den inre strömmen på tunnelgränssnittet. Att köra båda samtidigt svarar direkt på frågan: om den yttre strömmen finns och den inre inte, har applikationen aldrig skickat något in i tunneln. Om båda finns och ingenting kommer tillbaka ligger problemet bortom tunneln, vid destinationen eller på returvägen.

RFC 3948 definierar den yttre UDP-inkapslingen, och ESP-specifikationen definierar den skyddade layouten inuti. Ingen av de två dokumenten lovar att ett åtkomstnät släpper igenom den yttre strömmen, och därför är det värt att köra ett nåbarhetstest på den yttre tupeln innan någon teori om den inre. En blockerad yttre tupel ger en tunnel som aldrig bildas, inte en tunnel som bildas och sedan tappar en applikation.

Varför en UDP-app misslyckas inne i en fungerande tunnel

En tunnel som bär en webbapplikation men inte en UDP-applikation har flera rimliga förklaringar, och ISP:ns filtrering av det inre protokollet är inte den första. Den vanligaste är täckning: de två applikationerna kommer inte båda in i samma tunnel, eftersom rutten till UDP-destinationen saknas eller klientens split-tunnelregler utesluter den.

Den andra är ändpunkten. En VPN-server som tillåter en protokolllista, en brandvägg vid destinationen eller en tjänst som aldrig lyssnar på den förväntade porten ger alla en tidsgräns som ser identisk ut med en nätverksblockering.

Den tredje är paketstorlek. UDP-applikationer skickar ofta större datagram än en webbförfrågan, och inkapsling minskar den användbara MTU:n, så ett lyckat handskakning kan följas av tystnad vid den första fullstora nyttolasten. Det mönstret är lätt att feltolka som en blockering, eftersom de små paketen lyckas och de stora försvinner. En snabb MTU-probe avgör saken på under en minut, och svaret är oftast en mindre nyttolast eller en korrigerad MSS snarare än ett nätverksfilter.

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

Det första kommandot testar om ett stort paket överlever vägen med fragmentering avstängd, vilket snabbt avslöjar ett MTU-problem. Det andra skickar en liten, begränsad UDP-ström och rapporterar förlust och jitter. En ström som startar och sedan stannar pekar på storlek snarare än på en blockering.

Rapportera lagret, inte protokollet

Skriv fyndet i en av tre former: yttre leverans misslyckades, inre vidarebefordran misslyckades, eller applikationen misslyckades. Varje har en annan ägare, och att blanda dem skickar ärendet till fel team.

Att ändra en lokal port kan inte skapa en motsvarande lyssnare i andra änden, så en klientlösning som verkar hjälpa är vanligtvis bevis på att den ursprungliga destinationen var fel. På samma sätt bevisar en levererad alternativ profil något om nåbarhet och ingenting om huruvida applikationen är korrekt konfigurerad.

Håll slutsatsen åtskild från observationen. Trafikanalys kan antyda vad en ström är utan att dekryptera den, och det är ett användbart fynd, men det är inte samma påstående som att läsa det inre huvudet. Ange vilket av dem du faktiskt har.