Kial blokado de la tuta ICMP rompas funkciantan VPN-vojon

Tunelo, kiu aŭtentikas, portas ping kaj poste haltas ĉe la unua granda transigo, estas la klasika signo de mankanta ICMP-mesaĝo, ne de rompita VPN. La sendanto neniam ekscias, ke pakaĵo estis tro granda, ripetas la saman grandecon, kaj la aplikaĵo atendas. Ripari tion estas decido pri fajroŝirma politiko, ne reinstalo de la kliento. La ordo gravas: mezuru, kie kuŝas la grandeca limo, poste mallarĝigu la regulon, kiu englutis la raporton.

Kion ICMP vere portas sur ĉi tiu vojo

IPv4-voja MTU-malkovro dependas de tio, ke enkursigilo raportu, ke pakaĵo kun la bito don't-fragment agordita ne povis esti plusendita. Tiu raporto estas mesaĝo ICMP Fragmentation Needed, kaj sen ĝi la sendanto havas neniun kialon malpliigi sian segmentan grandecon. IPv6 estas pli strikta: enkursigiloj ne fragmentigas dum transiro, do mesaĝo ICMPv6 Packet Too Big estas la sola signalo, kiu igas la sendanton ŝrumpi.

Ambaŭ mesaĝoj estas retrokuplo de la rega ebeno, kaj neniu el ili estas diagnoza eĥo. Politiko, kiu blokas ping, kaj politiko, kiu blokas la tutan ICMP, aspektas simile en regula listo kaj kondutas tre malsame en la reto. La dua povas transformi ĝuste dimensiitan tunelon en unudirektan vojon por io ajn pli granda ol la plej malgranda ĉenero en la ĉeno.

Kelkaj transportoj realigas sian propran malkovron per sondaj pakaĵoj, kiel priskribas RFC 4821, kaj ili malpli dependas de ĉi tiu retrokuplo. Tio estas argumento kontroli, kiun transporton vi uzas, ne supozi, ke ĉiu tunelo estas imuna.

La malsukceso dependas de la grandeco

Demandu, ĉu la malsukceso korelacias kun la pakaĵa grandeco. Ensaluta paĝo, DNS-demando kaj mallonga API-alvoko sukcesas, dum dosiera alŝuto, granda respondo aŭ bilda elŝuto haltas. Tiu ŝablono indikas grandecan limon ie inter la du finoj, ne aŭtentikadon aŭ enkursigadon. Sukcesa malgranda ping diras preskaŭ nenion pri tio, kie kuŝas tiu limo.

Ene de tunelo estas du tavoloj konsiderindaj: la utilŝarĝa pakaĵo kaj la ekstera enkapsuligita pakaĵo. La interna sendanto povas konduti ĝuste dum la ekstera vojo estas pli malgranda ol la tunelo supozas, kaj tial gravas kaj la propra MTU-agordo de la tunelo kaj la fizika ligilo sub ĝi.

Mezuru antaŭ ol redakti regulojn

Sondi per la bito don't-fragment kaj per utilŝarĝa grandeco, kiun vi mem elektas, de la misa kliento al protektita adreso:

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

Utilŝarĝo de 1472 bajtoj plus 28 bajtoj da kaplinioj estas pakaĵo de 1500 bajtoj. Se la granda sondo malsukcesas kun fragmenta eraro kaj la malgranda trapasas, vi trovis la limon; alĝustigu por la tunela superŝarĝo kaj ripetu ĝis la funkcianta grandeco stabiliĝos.

Poste konfirmu, ke la breĉo estas la raporto mem. Se la sondo malsukcesas silente, sen eraro kaj sen respondo, la mesaĝo verŝajne estas forĵetata anstataŭ liverata, kaj la regulo estas la suspektato.

Mallarĝigu la regulon, poste retestu la taskon

La korekto devus permesi la koncernajn regajn mesaĝojn, ne la tutan protokolon. Sur gastiganto kun iptables la formo estas tipo-specifa permeso; adaptu la sintakson al tio, kio administras la fajroŝirmon sur via platformo:

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

Lasu eĥajn respondojn blokitaj se tio estas la loka politiko, ĉar la vojo ne bezonas ilin. Poste retestu la transigon, kiu origine malsukcesis, el nova konekto, kaj konfirmu, ke la regulaj nombriloj montras la mesaĝojn alvenantaj.

Se la granda transigo ankoraŭ haltas post kiam la mesaĝoj estas permesitaj, la restanta limo estas aliloke: tro alta tunela MTU, prokurilo, kiu reskribas pakaĵojn, aŭ meza skatolo, kiu forĵetas anstataŭ raporti. La ICMP-regulo estis necesa, ne sufiĉa.