Zakaj blokiranje vsega ICMP pokvari delujočo pot VPN

Tunel, ki se overi, prenese ping in se nato ustavi pri prvem velikem prenosu, je klasičen znak manjkajočega sporočila ICMP in ne pokvarjenega VPN. Pošiljatelj nikoli ne izve, da je bil paket prevelik, ponavlja enako velikost, aplikacija pa čaka. Popraviti to je odločitev o politiki požarnega zidu, ne ponovna namestitev odjemalca. Vrstni red je pomemben: izmerite, kje je meja velikosti, nato zožite pravilo, ki je pogoltnilo poročilo.

Kaj ICMP v resnici prenaša na tej poti

Odkrivanje MTU poti IPv4 se opira na to, da usmerjevalnik sporoči, da paketa z nastavljenim bitom don't-fragment ni bilo mogoče posredovati. To poročilo je sporočilo ICMP Fragmentation Needed, brez njega pa pošiljatelj nima razloga za zmanjšanje velikosti segmenta. IPv6 je strožji: usmerjevalniki med prehodom ne drobijo, zato je sporočilo ICMPv6 Packet Too Big edini signal, ki pošiljatelja prisili k skrčenju.

Obe sporočili so povratna informacija krmilne ravnine in nobeno ni diagnostični odmev. Politika, ki blokira ping, in politika, ki blokira ves ICMP, sta na seznamu pravil videti podobni, a se v omrežju obnašata zelo različno. Druga lahko pravilno dimenzioniran tunel spremeni v enosmerno pot za vse, kar je večje od najmanjšega člena v verigi.

Nekateri transporti izvajajo lastno odkrivanje s sondirnimi paketi, kot opisuje RFC 4821, in so manj odvisni od te povratne informacije. To je argument za preverjanje, kateri transport poganjate, ne za domnevo, da je vsak tunel imun.

Okvara je odvisna od velikosti

Vprašajte, ali je okvara povezana z velikostjo paketa. Prijavna stran, poizvedba DNS in kratek klic API uspejo, medtem ko se nalaganje datoteke, velik odgovor ali prenos slike ustavi. Ta vzorec kaže na omejitev velikosti nekje med obema koncema, ne na overjanje ali usmerjanje. Uspešen majhen ping skoraj nič ne pove o tem, kje je ta meja.

Znotraj tunela je treba upoštevati dva sloja: paket koristne obremenitve in zunanji zapakiran paket. Notranji pošiljatelj se lahko obnaša pravilno, medtem ko je zunanja pot manjša, kot predvideva tunel, zato sta pomembni tako lastna nastavitev MTU tunela kot fizična povezava pod njim.

Izmerite, preden urejate pravila

Sondirajte z bitom don't-fragment in velikostjo obremenitve, ki jo izberete sami, od okvarjenega odjemalca proti zaščitenemu naslovu:

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

Obremenitev 1472 bajtov plus 28 bajtov glav je paket velikosti 1500 bajtov. Če velika sonda spodleti z napako drobljenja, manjša pa gre skozi, ste našli mejo; upoštevajte dodatne stroške tunela in ponavljajte, dokler delujoča velikost ni stabilna.

Nato potrdite, da je vrzel poročilo samo. Če sonda spodleti tiho, brez napake in brez odgovora, se sporočilo verjetno zavrže, namesto da bi bilo dostavljeno, in sumljivo je pravilo.

Zožite pravilo in nato znova preizkusite nalogo

Popravek mora dovoliti določena krmilna sporočila, ne celotnega protokola. Na gostitelju z iptables je oblika dovoljenje za določen tip; prilagodite sintakso tistemu, kar upravlja požarni zid na vaši platformi:

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

Pustite odgovore odmeva blokirane, če je to lokalna politika, saj jih pot ne potrebuje. Nato znova preizkusite prenos, ki prvotno ni uspel, iz nove povezave, in potrdite, da števci pravila kažejo prihod sporočil.

Če se velik prenos še vedno ustavi po tem, ko so sporočila dovoljena, je preostala omejitev drugje: previsoko nastavljen MTU tunela, posrednik, ki prepisuje pakete, ali vmesna naprava, ki zavrže, namesto da bi poročala. Pravilo ICMP je bilo nujno, ne zadostno.