Hoekom die blokkering van alle ICMP 'n werkende VPN-roete breek

'n Tonnel wat authentiseer, 'n ping dra en dan by die eerste groot oordrag hang, is die klassieke teken van 'n ontbrekende ICMP-boodskap eerder as van 'n stukkende VPN. Die sender leer nooit dat 'n pakket te groot was nie, bly dieselfde grootte herprobeer, en die toepassing wag. Om dit reg te maak is 'n besluit oor die firewall-beleid, nie 'n herinstallasie van die kliënt nie. Die volgorde maak saak: meet waar die groottegrens lê, en vernou dan die reël wat die verslag ingesluk het.

Wat ICMP werklik op hierdie roete dra

IPv4-roete-MTU-ontdekking berus daarop dat 'n router rapporteer dat 'n pakket met die don't-fragment-bis geset nie aangestuur kon word nie. Daardie verslag is 'n ICMP Fragmentation Needed-boodskap, en daarsonder het die sender geen rede om sy segmente-grootte te verklein nie. IPv6 is strenger: routers fragmenteer nie in transito nie, so 'n ICMPv6 Packet Too Big-boodskap is die enigste sein wat die sender laat krimp.

Albei boodskappe is kontrole-vlak terugvoer, en nie een is 'n diagnostiese eggo nie. 'n Beleid wat ping blokkeer en 'n beleid wat alle ICMP blokkeer, lyk in 'n reëllijst soortgelyk en gedra hulle baie anders op die draad. Die tweede kan 'n korrek gegrootte tonnel in 'n eenrigtingroete verander vir enigiets groter as die kleinste skakel in die ketting.

Sommige transportlae implementeer hul eie ontdekking met peilpakkette, soos RFC 4821 beskryf, en dié is minder afhanklik van hierdie terugvoer. Dit is 'n argument om te kyk watter transport jy gebruik, nie om aan te neem elke tonnel is immuun nie.

Die fout hang van die grootte af

Vra of die fout met pakketgrootte verband hou. 'n Aanmeldbladsy, DNS-navraag en kort API-oproep slaag, terwyl 'n lêeroplaai, 'n groot antwoord of 'n beeldaftog staak. Daardie patroon wys na 'n groottegrens ergens tussen die twee punte, nie na authenticasie of roetering nie. 'n Geslaagde klein ping sê amper niks oor waar daardie grens lê nie.

Binne 'n tonnel is daar twee lae om te oorweeg: die nutspakket en die buitenste ingekapselde pakket. Die binneste sender kan korrek werk terwyl die buitenste roete kleiner is as wat die tonnel aanneem, en daarom maak die tonnel se eie MTU-instelling en die fisiese skakel daaronder albei saak.

Meet voordat jy reëls wysig

Peil met die don't-fragment-bis en 'n nutgrootte wat jy kies, van die foutende kliënt na 'n beskermde adres:

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

'n Nutsvrag van 1472 grepe plus 28 grepe se kopvelde is 'n pakket van 1500 grepe. As die groot peiling met 'n fragmentasiefout misluk en die kleiner een deurkom, het jy die grens gevind; pas aan vir tonnel-oorhoofse koste en herhaal tot die werkende grootte stabiel is.

Bevestig dan dat die gaping die verslag self is. As die peiling stil misluk, sonder fout en sonder antwoord, word die boodskap waarskynlik laat val eerder as afgelewer, en die reël is die verdagte.

Vernou die reël en toets dan die taak weer

Die regstelling moet die spesifieke kontroleboodskappe toelaat, nie die hele protokol nie. Op 'n iptables-gasheer is die vorm 'n tipe-spesifieke aanvaarding; pas die sintaks aan by wat die firewall op jou platform bestuur:

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

Hou eggo-antwoorde geblokkeer as dit die plaaslike beleid is, want dit is nie wat die roete nodig het nie. Toets dan die oordrag wat oorspronklik misluk het weer, vanaf 'n nuwe verbinding, en bevestig dat die reëltellers wys die boodskappe kom aan.

As die groot oordrag steeds staak nadat die boodskappe toegelaat is, is die oorblywende beperking elders: 'n tonnel-MTU wat te hoog gestel is, 'n proxy wat pakkette herskryf, of 'n middlebox wat laat val in plaas van rapporteer. Die ICMP-reël was nodig, nie voldoende nie.