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

En tunnel som autentiserer, bærer en ping og deretter henger på den første store overføringen, er det klassiske tegnet på en manglende ICMP-melding fremfor en defekt VPN. Avsenderen lærer aldri at en pakke var for stor, prøver på nytt med samme størrelse, og applikasjonen venter. Å rette det er en beslutning om brannmurpolicy, ikke en reinstallasjon av klienten. Rekkefølgen er viktig: mål hvor størrelsesgrensen ligger, og snevre deretter inn regelen som slukte rapporten.

Hva ICMP faktisk bærer på denne ruten

IPv4-rute-MTU-oppdagelse avhenger av 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 på 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 på nettet. Den andre kan gjøre en korrekt dimensjonert tunnel om til en enveisrute for alt som er større enn den minste lenken i kjeden.

Noen transportlag implementerer sin egen oppdagelse med sondepakker, slik 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 enhver tunnel er immun.

Feilen avhenger av størrelsen

Spør om feilen korrelerer 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. Det mønsteret peker på en størrelsesgrense et sted mellom de to endene, ikke på 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 korrekt mens den ytre ruten er mindre enn tunnelen antar, 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 selve rapporten. Hvis sonderingen feiler stille, uten feil og uten svar, blir meldingen sannsynligvis droppet i stedet for levert, og regelen er den mistenkte.

Snevre inn 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 reglens tellere 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 dropper i stedet for å rapportere. ICMP-regelen var nødvendig, ikke tilstrekkelig.