De ce blocarea întregului ICMP rupe o cale VPN funcțională

Un tunel care se autentifică, transportă un ping și apoi se blochează la primul transfer mare este semnătura clasică a unui mesaj ICMP lipsă, nu a unui VPN defect. Emițătorul nu află niciodată că pachetul era prea mare, repetă aceeași dimensiune, iar aplicația așteaptă. Repararea este o decizie de politică a firewall-ului, nu o reinstalare a clientului. Ordinea contează: măsurați unde se află limita de dimensiune, apoi restrângeți regula care a înghițit raportul.

Ce transportă de fapt ICMP pe această cale

Descoperirea MTU a căii IPv4 se bazează pe faptul că un router raportează că un pachet cu bitul don't-fragment setat nu a putut fi forwardat. Acel raport este un mesaj ICMP Fragmentation Needed, iar fără el emițătorul nu are niciun motiv să reducă dimensiunea segmentului. IPv6 este mai strict: routerele nu fragmentează în tranzit, deci un mesaj ICMPv6 Packet Too Big este singurul semnal care îl face pe emițător să se micșoreze.

Ambele mesaje sunt feedback al planului de control și niciunul nu este un ecou de diagnostic. O politică ce blochează ping și una ce blochează tot ICMP arată similar într-o listă de reguli, dar se comportă foarte diferit în rețea. A doua poate transforma un tunel dimensionat corect într-o cale unidirecțională pentru orice este mai mare decât cea mai mică verigă din lanț.

Unele transporturi își implementează propria descoperire cu pachete de sondă, cum descrie RFC 4821, și depind mai puțin de acest feedback. Acesta este un argument pentru a verifica ce transport rulați, nu pentru a presupune că orice tunel este imun.

Defecțiunea depinde de dimensiune

Întrebați dacă defecțiunea se corelează cu dimensiunea pachetului. O pagină de autentificare, o interogare DNS și un apel API scurt reușesc, în timp ce un upload de fișier, un răspuns mare sau o descărcare de imagine se blochează. Acest model indică o limită de dimensiune undeva între cele două capete, nu autentificarea sau rutarea. Un ping mic reușit nu spune aproape nimic despre unde se află această graniță.

În interiorul unui tunel sunt două straturi de luat în considerare: pachetul de payload și pachetul exterior încapsulat. Emițătorul interior se poate comporta corect în timp ce calea exterioară este mai mică decât presupune tunelul, de aceea contează atât setarea MTU a tunelului, cât și legătura fizică de sub el.

Măsurați înainte de a edita reguli

Sondați cu bitul don't-fragment și cu o dimensiune de payload pe care o alegeți, de la clientul defectuos către o adresă protejată:

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

Un payload de 1472 octeți plus 28 octeți de antet formează un pachet de 1500 octeți. Dacă sonda mare eșuează cu o eroare de fragmentare și cea mică trece, ați găsit granița; ajustați pentru suprasarcina tunelului și repetați până când dimensiunea funcțională este stabilă.

Apoi confirmați că golul este raportul însuși. Dacă sonda eșuează în tăcere, fără eroare și fără răspuns, mesajul este probabil aruncat în loc să fie livrat, iar regula este suspecta.

Restrângeți regula, apoi retestați sarcina

Corecția ar trebui să permită mesajele de control specifice, nu întregul protocol. Pe un host cu iptables forma este o acceptare specifică tipului; adaptați sintaxa la ce administrează firewall-ul pe platforma dumneavoastră:

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

Lăsați răspunsurile de ecou blocate dacă aceasta este politica locală, deoarece calea nu are nevoie de ele. Apoi retestați transferul care a eșuat inițial, dintr-o conexiune nouă, și confirmați că contoarele regulii arată mesajele sosind.

Dacă transferul mare încă se blochează după ce mesajele sunt permise, limita rămasă este în altă parte: un MTU de tunel setat prea sus, un proxy care rescrie pachete sau un element intermediar care aruncă în loc să raporteze. Regula ICMP era necesară, nu suficientă.