Waarom al het ICMP blokkeren een werkend VPN-pad breekt

Een tunnel die authenticeert, een ping draagt en dan blijft hangen bij de eerste grote overdracht is het klassieke teken van een ontbrekend ICMP-bericht in plaats van een kapotte VPN. De afzender leert nooit dat een pakket te groot was, probeert dezelfde grootte opnieuw, en de toepassing wacht. Dit oplossen is een beslissing over firewallbeleid, niet een herinstallatie van de client. De volgorde is belangrijk: meet waar de groottegrens ligt en versmal daarna de regel die het rapport opslokte.

Wat ICMP op dit pad werkelijk draagt

IPv4-pad-MTU-detectie leunt erop dat een router meldt dat een pakket met de don't-fragment-bit niet kon worden doorgestuurd. Dat rapport is een ICMP Fragmentation Needed-bericht, en zonder dat heeft de afzender geen reden om zijn segmentgrootte te verkleinen. IPv6 is strenger: routers fragmenteren niet onderweg, dus een ICMPv6 Packet Too Big-bericht is het enige signaal dat de afzender laat krimpen.

Beide berichten zijn feedback van het controlevlak, en geen van beide is een diagnostische echo. Een beleid dat ping blokkeert en een beleid dat al het ICMP blokkeert lijken op elkaar in een regellijst maar gedragen zich op het netwerk heel anders. Het tweede kan een correct gedimensioneerde tunnel veranderen in een eenrichtingspad voor alles groter dan de kleinste schakel in de keten.

Sommige transporten implementeren hun eigen detectie met sondeerpakketten, zoals RFC 4821 beschrijft, en die zijn minder afhankelijk van deze feedback. Dat is een argument om te controleren welk transport je draait, niet om aan te nemen dat elke tunnel immuun is.

De storing hangt van de grootte af

Vraag of de storing samenhangt met de pakketgrootte. Een inlogpagina, een DNS-query en een korte API-aanroep slagen, terwijl een bestandsupload, een groot antwoord of een afbeeldingsdownload blijft hangen. Dat patroon wijst op een groottegrens ergens tussen de twee uiteinden, niet op authenticatie of routing. Een geslaagde kleine ping zegt bijna niets over waar die grens ligt.

Binnen een tunnel zijn er twee lagen te overwegen: het nuttige-lastpakket en het buitenste ingekapselde pakket. De binnenste afzender kan zich correct gedragen terwijl het buitenste pad kleiner is dan de tunnel aanneemt, en daarom doen zowel de eigen MTU-instelling van de tunnel als de fysieke schakel eronder ertoe.

Meet voordat je regels aanpast

Sondeer met de don't-fragment-bit en een lastgrootte die je zelf kiest, van de falende client richting een beschermd adres:

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

Een last van 1472 byte plus 28 byte headers is een pakket van 1500 byte. Als de grote sonde mislukt met een fragmentatiefout en de kleinere doorkomt, heb je de grens gevonden; corrigeer voor tunnel-overhead en herhaal tot de werkende grootte stabiel is.

Bevestig daarna dat de kloof het rapport zelf is. Als de sonde stil mislukt, zonder fout en zonder antwoord, wordt het bericht waarschijnlijk weggegooid in plaats van afgeleverd, en de regel is de verdachte.

Versmal de regel en test de taak daarna opnieuw

De correctie moet de specifieke controlevelberichten toestaan, niet het hele protocol. Op een iptables-host is de vorm een typespecifieke acceptatie; pas de syntaxis aan op wat de firewall op jouw platform beheert:

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

Laat echo-antwoorden geblokkeerd als dat het lokale beleid is, want het pad heeft ze niet nodig. Test daarna de overdracht die oorspronkelijk mislukte opnieuw, vanaf een nieuwe verbinding, en bevestig dat de regeltellers laten zien dat de berichten aankomen.

Als de grote overdracht nog steeds stokt nadat de berichten zijn toegestaan, ligt de resterende grens elders: een tunnel-MTU die te hoog is ingesteld, een proxy die pakketten herschrijft, of een middenbox die weggooit in plaats van te rapporteren. De ICMP-regel was nodig, niet voldoende.