Kāpēc visu ICMP bloķēšana salauž strādājošu VPN ceļu

Tunelis, kas autentificējas, pārnes ping un pēc tam iestrēgst pirmajā lielajā pārsūtīšanā, ir klasiska trūkstoša ICMP ziņojuma pazīme, nevis salauzta VPN. Sūtītājs nekad neuzzina, ka pakets bija pārāk liels, atkārto to pašu izmēru, un lietojumprogramma gaida. To labot ir ugunsmūra politikas lēmums, nevis klienta pārinstalēšana. Secība ir svarīga: izmēriet, kur atrodas izmēra robeža, pēc tam sašauriniet noteikumu, kas aprīja ziņojumu.

Ko ICMP šajā ceļā patiešām pārnēsā

IPv4 ceļa MTU noteikšana balstās uz to, ka maršrutētājs ziņo, ka paketu ar iestatītu don't-fragment bitu nevarēja pārsūtīt. Šis ziņojums ir ICMP Fragmentation Needed, un bez tā sūtītājam nav iemesla samazināt segmenta izmēru. IPv6 ir stingrāks: maršrutētāji tranzītā nedala, tāpēc ICMPv6 Packet Too Big ziņojums ir vienīgais signāls, kas liek sūtītājam sarauties.

Abi ziņojumi ir vadības plaknes atgriezeniskā saite, un neviens no tiem nav diagnostisks atbalss. Politika, kas bloķē ping, un politika, kas bloķē visu ICMP, noteikumu sarakstā izskatās līdzīgi, bet tīklā uzvedas ļoti atšķirīgi. Otrā var pārvērst pareizi dimensētu tuneli vienvirziena ceļā visam, kas ir lielāks par mazāko posmu ķēdē.

Daži transporti savu noteikšanu īsteno ar zondes paketiem, kā apraksta RFC 4821, un tie mazāk ir atkarīgi no šīs atgriezeniskās saites. Tas ir arguments pārbaudīt, kuru transportu jūs darbinat, nevis pieņemt, ka katrs tunelis ir imūns.

Kļūme ir atkarīga no izmēra

Jautājiet, vai kļūme korelē ar paketa izmēru. Pieslēgšanās lapa, DNS vaicājums un īss API izsaukums izdodas, kamēr faila augšupielāde, liela atbilde vai attēla lejupielāde iestrēgst. Šis modelis norāda uz izmēra ierobežojumu kaut kur starp abiem galiem, nevis uz autentifikāciju vai maršrutēšanu. Veiksmīgs mazs ping gandrīz neko nepasaka par to, kur šī robeža atrodas.

Tuneļa iekšpusē ir jāņem vērā divi slāņi: lietderīgās kravas pakets un ārējais iekapsulētais pakets. Iekšējais sūtītājs var uzvesties pareizi, kamēr ārējais ceļš ir mazāks, nekā tunelis pieņem, tāpēc svarīgs ir gan paša tuneļa MTU iestatījums, gan zem tā esošais fiziskais posms.

Izmēriet pirms noteikumu rediģēšanas

Pārbaudiet ar don't-fragment bitu un jūsu izvēlētu lietderīgās kravas izmēru, no bojātā klienta uz aizsargātu adresi:

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

1472 baitu lietderīgā krava plus 28 baiti galveņu veido 1500 baitu paketu. Ja lielā zonde neizdodas ar sadalīšanas kļūdu un mazākā iziet, jūs esat atraduši robežu; ņemiet vērā tuneļa papildu izmaksas un atkārtojiet, līdz strādājošais izmērs ir stabils.

Pēc tam pārliecinieties, ka starpība ir pats ziņojums. Ja zonde neizdodas klusi, bez kļūdas un bez atbildes, ziņojums, iespējams, tiek izmests, nevis piegādāts, un aizdomās turamais ir noteikums.

Sašauriniet noteikumu, pēc tam vēlreiz pārbaudiet uzdevumu

Labojumam jāatļauj konkrētus vadības ziņojumus, nevis viss protokols. Uz iptables resursdatora forma ir konkrēta tipa atļauja; pielāgojiet sintaksi tam, kas pārvalda ugunsmūri jūsu platformā:

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

Atstājiet atbalss atbildes bloķētas, ja tā ir vietējā politika, jo ceļam tās nav vajadzīgas. Pēc tam vēlreiz pārbaudiet sākotnēji neizdevušos pārsūtīšanu no jauna savienojuma un pārliecinieties, ka noteikuma skaitītāji rāda ienākošos ziņojumus.

Ja lielā pārsūtīšana joprojām iestrēgst pēc ziņojumu atļaušanas, atlikušais ierobežojums ir citur: pārāk augstu iestatīts tuneļa MTU, starpniekserveris, kas pārraksta paketus, vai starpmezgls, kas izmet, nevis ziņo. ICMP noteikums bija nepieciešams, nevis pietiekams.