Hvorfor blokering af al ICMP ødelægger en fungerende VPN-rute

En tunnel, der godkender, bærer en ping og derefter hænger på den første store overførsel, er det klassiske tegn på en manglende ICMP-besked frem for en defekt VPN. Afsenderen lærer aldrig, at en pakke var for stor, prøver igen med samme størrelse, og applikationen venter. At rette det er en beslutning om firewallpolitik, ikke en geninstallation af klienten. Rækkefølgen er vigtig: mål, hvor størrelsesgrænsen ligger, og indsnævr derefter reglen, der slugte rapporten.

Hvad ICMP faktisk bærer på denne rute

IPv4-rute-MTU-opdagelse afhænger af, at en router rapporterer, at en pakke med don't-fragment-bitten sat ikke kunne videresendes. Den rapport er en ICMP Fragmentation Needed-besked, og uden den har afsenderen ingen grund til at reducere sin segmentstørrelse. IPv6 er strengere: routere fragmenterer ikke undervejs, så en ICMPv6 Packet Too Big-besked er det eneste signal, der får afsenderen til at krympe.

Begge beskeder er feedback på kontrolplanet, og ingen af dem er et diagnostisk ekko. En politik, der blokerer ping, og en politik, der blokerer al ICMP, ser ens ud på en regelliste og opfører sig meget forskelligt på nettet. Den anden kan forvandle en korrekt dimensioneret tunnel til en ensrettet rute for alt, der er større end det mindste led i kæden.

Nogle transportlag implementerer deres egen opdagelse med probepakker, som RFC 4821 beskriver, og de er mindre afhængige af denne feedback. Det er et argument for at undersøge, hvilken transport du kører, ikke for at antage, at enhver tunnel er immun.

Fejlen afhænger af størrelsen

Spørg, om fejlen hænger sammen med pakkestørrelsen. En login-side, en DNS-forespørgsel og et kort API-kald lykkes, mens en filoverførsel, et stort svar eller en billeddownload går i stå. Det mønster peger på en størrelsesgrænse et sted mellem de to ender, ikke på godkendelse eller routing. En vellykket lille ping siger næsten intet om, hvor den grænse ligger.

Inde i en tunnel er der to lag at overveje: nyttelastpakken og den ydre indkapslede pakke. Den indre afsender kan opføre sig korrekt, mens den ydre rute er mindre, end tunnelen antager, og derfor betyder både tunnelens egen MTU-indstilling og det fysiske led nedenunder noget.

Mål, før du redigerer regler

Sondér med don't-fragment-bitten og en nyttelaststørrelse, du selv vælger, fra den fejlende klient mod en beskyttet adresse:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

En nyttelast på 1472 byte plus 28 byte headere er en pakke på 1500 byte. Hvis den store sondering fejler med en fragmenteringsfejl, og den lille går igennem, har du fundet grænsen; juster for tunnel-overhead, og gentag, indtil den fungerende størrelse er stabil.

Bekræft derefter, at hullet er selve rapporten. Hvis sonderingen fejler lydløst, uden fejl og uden svar, bliver beskeden sandsynligvis droppet frem for leveret, og reglen er den mistænkte.

Indsnævr reglen, og test derefter opgaven igen

Rettelsen skal tillade de specifikke kontrolbeskeder, ikke hele protokollen. På en iptables-vært er formen en typspecifik tilladelse; tilpas syntaksen til det, der styrer firewallen på din platform:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

Lad ekko-svar være blokeret, hvis det er den lokale politik, da ruten ikke har brug for dem. Test derefter den overførsel, der oprindeligt fejlede, igen fra en ny forbindelse, og bekræft, at reglens tællere viser, at beskederne ankommer.

Hvis den store overførsel stadig går i stå, efter at beskederne er tilladt, er den resterende grænse et andet sted: en tunnel-MTU, der er sat for højt, en proxy, der omskriver pakker, eller en mellemboks, der dropper i stedet for at rapportere. ICMP-reglen var nødvendig, ikke tilstrækkelig.