Per què bloquejar tot l'ICMP trenca un camí VPN que funciona

Un túnel que s'autentica, porta un ping i després s'encalla en la primera transferència gran és el senyal clàssic d'un missatge ICMP que falta, no d'una VPN trencada. L'emissor no arriba a saber mai que un paquet era massa gran, reintenta la mateixa mida i l'aplicació espera. Arreglar-ho és una decisió de política del tallafoc, no reinstal·lar el client. L'ordre importa: mesureu on és el límit de mida i després estrenyeu la regla que s'havia empassat l'informe.

Què porta realment l'ICMP en aquest camí

Descoberta de l'MTU del camí IPv4 es basa que un encaminador informi que un paquet amb el bit don't-fragment activat no s'ha pogut reenviar. Aquest informe és un missatge ICMP Fragmentation Needed i, sense ell, l'emissor no té cap motiu per reduir la mida del segment. IPv6 és més estricte: els encaminadors no fragmenten en trànsit, així que un missatge ICMPv6 Packet Too Big és l'únic senyal que fa encongir l'emissor.

Tots dos missatges són retroalimentació del pla de control i cap dels dos no és un eco de diagnòstic. Una política que bloqueja el ping i una que bloqueja tot l'ICMP semblen iguals en una llista de regles i es comporten de manera molt diferent a la xarxa. La segona pot convertir un túnel ben dimensionat en un camí d'un sol sentit per a qualsevol cosa més gran que l'enllaç més petit de la cadena.

Alguns transports implementen la seva pròpia descoberta amb paquets de sonda, com descriu l'RFC 4821, i depenen menys d'aquesta retroalimentació. Això és un argument per comprovar quin transport feu servir, no per suposar que tot túnel és immune.

La fallada depèn de la mida

Pregunteu si la fallada es correlaciona amb la mida del paquet. Una pàgina d'inici de sessió, una consulta DNS i una crida curta a l'API passen, mentre que una pujada de fitxer, una resposta gran o una baixada d'imatge s'encallen. Aquest patró apunta a un límit de mida en algun punt entre els dos extrems, no a l'autenticació ni a l'encaminament. Un ping petit correcte no diu gairebé res sobre on és aquesta frontera.

Dins d'un túnel hi ha dues capes a considerar: el paquet de càrrega útil i el paquet extern encapsulat. L'emissor intern pot comportar-se correctament mentre el camí extern és més petit del que el túnel suposa, i per això tant la configuració d'MTU del túnel com l'enllaç físic de sota tenen importància.

Mesureu abans d'editar regles

Sondegeu amb el bit don't-fragment i una mida de càrrega útil que trieu, des del client afectat cap a una adreça protegida:

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

Una càrrega útil de 1472 bytes més 28 bytes de capçaleres és un paquet de 1500 bytes. Si la sonda gran falla amb un error de fragmentació i la petita passa, heu trobat la frontera; ajusteu pel sobrecost del túnel i repetiu fins que la mida funcional sigui estable.

Després confirmeu que el buit és l'informe mateix. Si la sonda falla en silenci, sense error ni resposta, el missatge probablement es descarta en lloc de lliurar-se, i la regla és la sospitosa.

Estrenyeu la regla i torneu a provar la tasca

La correcció ha de permetre els missatges de control concrets, no tot el protocol. En un amfitrió amb iptables la forma és una acceptació per tipus; adapteu la sintaxi al que gestioni el tallafoc a la vostra plataforma:

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

Deixeu les respostes d'eco bloquejades si aquesta és la política local, perquè el camí no les necessita. Després torneu a provar la transferència que havia fallat, des d'una connexió nova, i confirmeu que els comptadors de la regla mostren els missatges arribant.

Si la transferència gran encara s'encalla després de permetre els missatges, el límit restant és en un altre lloc: un MTU de túnel massa alt, un proxy que reescriu paquets o un element intermedi que descarta en lloc d'informar. La regla ICMP era necessària, però no suficient.