Kvifor blokkering av all ICMP øydelegg ein fungerande VPN-rute

Ein tunnel som autentiserer, ber ein ping og deretter heng på den første store overføringa, er det klassiske teiknet på ei manglande ICMP-melding framfor ein defekt VPN. Avsendaren lærer aldri at ein pakke var for stor, prøver på nytt med same storleik, og applikasjonen ventar. Å rette dette er ei avgjerd om brannmurpolitikk, ikkje ein reinstallasjon av klienten. Rekkjefølgja er viktig: mål kvar storleiksgrensa ligg, og snevra deretter inn regelen som sluka rapporten.

Kva ICMP faktisk ber på denne ruta

IPv4-rute-MTU-oppdaging er avhengig av at ein ruter rapporterer at ein pakke med don't-fragment-biten sett ikkje kunne videresendast. Den rapporten er ei ICMP Fragmentation Needed-melding, og utan henne har avsendaren ingen grunn til å redusere segmentstorleiken. IPv6 er strengare: rutarar fragmenterer ikkje undervegs, så ei ICMPv6 Packet Too Big-melding er det einaste signalet som får avsendaren til å krympe.

Båe meldingane er tilbakemelding på kontrollplanet, og ingen av dei er eit diagnostisk ekko. Ein politikk som blokkerer ping og ein politikk som blokkerer all ICMP ser like ut i ei regelliste, men oppfører seg svært ulikt på nettet. Den andre kan gjere ein rett dimensjonert tunnel om til ei einvegsrute for alt som er større enn den minste lenkja i kjeda.

Nokre transportlag implementerer si eiga oppdaging med sondepakkar, slik RFC 4821 skildrar, og dei er mindre avhengige av denne tilbakemeldinga. Det er eit argument for å sjekke kva transport du køyrer, ikkje for å anta at kvar tunnel er immun.

Feilen er avhengig av storleiken

Spør om feilen korrelerer med pakkestorleiken. Ei innloggingsside, eit DNS-spørsmål og eit kort API-kall lukkast, medan ein filopplasting, eit stort svar eller ei bildenedlasting stoppar. Det mønsteret peikar på ei storleiksgrense ein stad mellom dei to endane, ikkje på autentisering eller ruting. Ein vellukka liten ping seier nesten ingenting om kvar den grensa ligg.

Inne i ein tunnel er det to lag å vurdere: nyttelastpakken og den ytre innkapsla pakken. Den indre avsendaren kan oppføre seg rett medan den ytre ruta er mindre enn tunnelen antek, og difor spelar både tunnelens eigen MTU-innstilling og den fysiske lenkja under noko.

Mål før du redigerer reglar

Sondér med don't-fragment-biten og ein nyttelaststorleik du vel sjølv, frå den feilande klienten mot ei verna adresse:

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

Ein nyttelast på 1472 byte pluss 28 byte hovud er ein pakke på 1500 byte. Viss den store sonderinga feilar med ein fragmenteringsfeil og den litle går gjennom, har du funne grensa; juster for tunnel-overhead og gjer om til den fungerande storleiken er stabil.

Stadfest deretter at gapet er sjølve rapporten. Viss sonderinga feilar stille, utan feil og utan svar, blir meldinga truleg droppa i staden for levert, og regelen er den mistenkte.

Snevra inn regelen, og test deretter oppgåva på nytt

Rettinga bør tillate dei spesifikke kontrollmeldingane, ikkje heile protokollen. På ein iptables-vert er forma ei typspesifikk tillating; tilpass syntaksen til det som styrer brannmuren på plattforma di:

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

Lat ekko-svar vere blokkerte viss det er den lokale politikken, sidan ruta ikkje treng dei. Test deretter overføringa som opphavleg feila på nytt, frå ei ny tilkopling, og stadfest at teljarane til regelen viser at meldingane kjem inn.

Viss den store overføringa framleis stoppar etter at meldingane er tillatne, er den gjenverande grensa ein annan stad: ein tunnel-MTU sett for høgt, ein proxy som skriv om pakkar, eller ein mellomliggjande boks som droppar i staden for å rapportere. ICMP-regelen var nødvendig, ikkje tilstrekkeleg.