Hvorfor blokkering av all ICMP ødelegger en fungerende VPN-rute

En tunnel som autentiserer, bærer en ping og deretter henger ved den første store overføringen, er det klassiske tegnet på en manglende ICMP-melding fremfor en defekt VPN. Avsenderen lærer aldri at pakken var for stor, gjentar samme størrelse, og applikasjonen venter. Å rette dette er en beslutning om brannmurpolitikk, ikke en reinstallasjon av klienten. Rekkefølgen betyr noe: mål hvor størrelsesgrensen ligger, og avgrens deretter regelen som svelget rapporten.

Hva ICMP egentlig bærer på denne ruten

IPv4-rute-MTU-oppdagelse hviler på at en ruter rapporterer at en pakke med don't-fragment-biten satt ikke kunne videresendes. Den rapporten er en ICMP Fragmentation Needed-melding, og uten den har avsenderen ingen grunn til å redusere segmentstørrelsen. IPv6 er strengere: rutere fragmenterer ikke underveis, så en ICMPv6 Packet Too Big-melding er det eneste signalet som får avsenderen til å krympe.

Begge meldingene er tilbakemelding fra kontrollplanet, og ingen av dem er et diagnostisk ekko. En policy som blokkerer ping og en policy som blokkerer all ICMP ser like ut i en regelliste, men oppfører seg svært forskjellig i nettet. Den andre kan gjøre en riktig dimensjonert tunnel om til en enveisrute for alt som er større enn den minste lenken i kjeden.

Noen transportlag implementerer egen oppdagelse med sondepakker, som RFC 4821 beskriver, og de er mindre avhengige av denne tilbakemeldingen. Det er et argument for å sjekke hvilken transport du kjører, ikke for å anta at hver tunnel er immun.

Feilen avhenger av størrelsen

Spør om feilen samvarierer med pakkestørrelsen. En innloggingsside, en DNS-spørring og et kort API-kall lykkes, mens en filopplasting, et stort svar eller en bildenedlasting stopper. Mønsteret peker mot en størrelsesgrense et sted mellom de to endene, ikke mot autentisering eller ruting. En vellykket liten ping sier nesten ingenting om hvor den grensen ligger.

Inne i en tunnel er det to lag å vurdere: nyttelastpakken og den ytre innkapslede pakken. Den indre avsenderen kan oppføre seg riktig mens den ytre ruten er mindre enn tunnelen forutsetter, og derfor betyr både tunnelens egen MTU-innstilling og den fysiske lenken under noe.

Mål før du redigerer regler

Sondér med don't-fragment-biten og en nyttelaststørrelse du velger selv, fra den feilende klienten mot 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 pluss 28 byte headere er en pakke på 1500 byte. Hvis den store sonderingen feiler med en fragmenteringsfeil og den lille går gjennom, har du funnet grensen; juster for tunnel-overhead og gjenta til den fungerende størrelsen er stabil.

Bekreft deretter at gapet er rapporten selv. Hvis sonderingen feiler lydløst, uten feil og uten svar, blir meldingen sannsynligvis forkastet i stedet for levert, og regelen er den mistenkte.

Avgrens regelen, og test deretter oppgaven på nytt

Rettelsen bør tillate de spesifikke kontrollmeldingene, ikke hele protokollen. På en iptables-vert er formen en typspesifikk tillatelse; tilpass syntaksen til det som styrer brannmuren på plattformen din:

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

La ekko-svar være blokkert hvis det er den lokale policyen, siden ruten ikke trenger dem. Test deretter overføringen som opprinnelig feilet på nytt, fra en ny tilkobling, og bekreft at regeltellerne viser at meldingene kommer inn.

Hvis den store overføringen fortsatt stopper etter at meldingene er tillatt, er den gjenværende grensen et annet sted: en tunnel-MTU satt for høyt, en proxy som skriver om pakker, eller en mellomliggende boks som forkaster i stedet for å rapportere. ICMP-regelen var nødvendig, ikke tilstrekkelig.