Varför blockering av all ICMP bryter en fungerande VPN-väg

En tunnel som autentiserar, bär en ping och sedan hänger på den första stora överföringen är det klassiska tecknet på ett saknat ICMP-meddelande snarare än en trasig VPN. Avsändaren får aldrig veta att paketet var för stort, upprepar samma storlek, och applikationen väntar. Att åtgärda det är ett beslut om brandväggspolicy, inte en ominstallation av klienten. Ordningen spelar roll: mät var storleksgränsen ligger och snäva sedan in regeln som svalde rapporten.

Vad ICMP faktiskt bär på den här vägen

IPv4-vägens MTU-upptäckt bygger på att en router rapporterar att ett paket med don't-fragment-biten satt inte kunde vidarebefordras. Den rapporten är ett ICMP Fragmentation Needed-meddelande, och utan den har avsändaren ingen anledning att minska segmentstorleken. IPv6 är strängare: routrar fragmenterar inte under transport, så ett ICMPv6 Packet Too Big-meddelande är den enda signal som får avsändaren att krympa.

Båda meddelandena är återkoppling på kontrollplanet, och ingen av dem är ett diagnostiskt eko. En policy som blockerar ping och en policy som blockerar all ICMP ser likadana ut i en regellista men beter sig mycket olika i nätet. Den andra kan förvandla en korrekt dimensionerad tunnel till en enkelriktad väg för allt som är större än den minsta länken i kedjan.

Vissa transporter implementerar egen upptäckt med sondpaket, som RFC 4821 beskriver, och de är mindre beroende av denna återkoppling. Det är ett argument att kontrollera vilken transport du kör, inte att anta att varje tunnel är immun.

Felet beror på storleken

Fråga om felet korrelerar med paketstorleken. En inloggningssida, en DNS-fråga och ett kort API-anrop lyckas, medan en filuppladdning, ett stort svar eller en bildnedladdning stannar. Mönstret pekar på en storleksgräns någonstans mellan de två ändarna, inte på autentisering eller routing. En lyckad liten ping säger nästan ingenting om var den gränsen ligger.

Inuti en tunnel finns två lager att beakta: nyttolastpaketet och det yttre inkapslade paketet. Den inre avsändaren kan bete sig korrekt medan den yttre vägen är mindre än tunneln antar, och därför spelar både tunnelns egen MTU-inställning och den fysiska länken under roll.

Mät innan du redigerar regler

Sondera med don't-fragment-biten och en nyttolaststorlek du själv väljer, från den felande klienten mot en skyddad adress:

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

En nyttolast på 1472 byte plus 28 byte huvuden är ett paket på 1500 byte. Om den stora sonderingen misslyckas med ett fragmenteringsfel och den mindre går igenom har du hittat gränsen; justera för tunnelns överhead och upprepa tills den fungerande storleken är stabil.

Bekräfta sedan att gapet är rapporten själv. Om sonderingen misslyckas tyst, utan fel och utan svar, släpps meddelandet troligen i stället för att levereras, och regeln är den misstänkta.

Snäva in regeln och testa sedan uppgiften igen

Rättelsen bör tillåta de specifika kontrollmeddelandena, inte hela protokollet. På en iptables-värd är formen ett typspecifikt tillstånd; anpassa syntaxen till det som hanterar brandväggen på din plattform:

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

Låt eko-svar vara blockerade om det är den lokala policyn, eftersom vägen inte behöver dem. Testa sedan överföringen som ursprungligen misslyckades igen, från en ny anslutning, och bekräfta att regelns räknare visar att meddelandena kommer in.

Om den stora överföringen fortfarande stannar efter att meddelandena tillåtits ligger den kvarvarande gränsen någon annanstans: en tunnel-MTU satt för högt, en proxy som skriver om paket, eller en mellanbox som släpper i stället för att rapportera. ICMP-regeln var nödvändig, inte tillräcklig.