Ինչու ամբողջ ICMP-ի արգելափակումը կոտրում է աշխատող VPN ուղին

Թունելը, որը նույնականացում է անցնում, ping է տանում և հետո կախվում է առաջին մեծ փոխանցման վրա, բացակայող ICMP հաղորդագրության դասական նշան է, ոչ թե կոտրված VPN-ի։ Ուղարկողը երբեք չի իմանում, որ փաթեթը չափազանց մեծ էր, կրկնում է նույն չափը, և հավելվածը սպասում է։ Սա ուղղելը firewall-ի քաղաքականության որոշում է, ոչ թե հաճախորդի վերատեղադրում։ Հերթականությունը կարևոր է. չափեք, թե որտեղ է չափի սահմանը, ապա նեղացրեք այն կանոնը, որը կուլ տվեց հաշվետվությունը։

Ինչ է ICMP-ն իրականում տանում այս ուղով

IPv4 ուղու MTU հայտնաբերում հիմնված է այն բանի վրա, որ երթուղիչը հաղորդում է, որ don't-fragment բիտով փաթեթը հնարավոր չէր փոխանցել։ Այդ հաղորդումը ICMP Fragmentation Needed հաղորդագրություն է, և առանց դրա ուղարկողը պատճառ չունի փոքրացնելու իր սեգմենտի չափը։ IPv6-ը ավելի խիստ է. երթուղիչները տրանզիտում չեն մասնատում, ուստի ICMPv6 Packet Too Big հաղորդագրությունը միակ ազդանշանն է, որը ստիպում է ուղարկողին կծկվել։

Երկու հաղորդագրություններն էլ կառավարման հարթության հետադարձ կապ են, և ոչ մեկը ախտորոշիչ արձագանք չէ։ Ping-ը արգելափակող քաղաքականությունը և ամբողջ ICMP-ն արգելափակող քաղաքականությունը կանոնների ցանկում նման են երևում, բայց ցանցում շատ տարբեր են վարվում։ Երկրորդը կարող է ճիշտ չափված թունելը դարձնել միակողմանի ուղի շղթայի ամենափոքր օղակից մեծ ամեն ինչի համար։

Որոշ տրանսպորտներ իրականացնում են իրենց սեփական հայտնաբերումը զոնդային փաթեթներով, ինչպես նկարագրում է RFC 4821-ը, և դրանք ավելի քիչ են կախված այս հետադարձ կապից։ Սա փաստարկ է ստուգելու, թե որ տրանսպորտն եք աշխատեցնում, ոչ թե ենթադրելու, որ յուրաքանչյուր թունել անխոցելի է։

Ձախողումը կախված է չափից

Հարցրեք՝ արդյոք ձախողումը կապված է փաթեթի չափի հետ։ Մուտքի էջը, DNS հարցումը և կարճ API կանչը անցնում են, մինչդեռ ֆայլի վերբեռնումը, մեծ պատասխանը կամ պատկերի ներբեռնումը կախվում են։ Այս օրինաչափությունը մատնանշում է չափի սահմանը ինչ-որ տեղ երկու ծայրերի միջև, ոչ թե նույնականացումը կամ երթուղավորումը։ Հաջող փոքր ping-ը գրեթե ոչինչ չի ասում այն մասին, թե որտեղ է այդ սահմանը։

Թունելի ներսում պետք է հաշվի առնել երկու շերտ՝ օգտակար բեռի փաթեթը և արտաքին ինկապսուլացված փաթեթը։ Ներքին ուղարկողը կարող է ճիշտ վարվել, մինչ արտաքին ուղին ավելի փոքր է, քան թունելը ենթադրում է, և դրա համար կարևոր են և՛ թունելի սեփական MTU կարգավորումը, և՛ դրա տակ գտնվող ֆիզիկական օղակը։

Չափեք կանոնները խմբագրելուց առաջ

Զոնդավորեք don't-fragment բիտով և ձեր ընտրած օգտակար բեռի չափով, ձախողված հաճախորդից դեպի պաշտպանված հասցե.

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

1472 բայթ օգտակար բեռը գումարած 28 բայթ վերնագրեր կազմում է 1500 բայթ փաթեթ։ Եթե մեծ զոնդը ձախողվում է մասնատման սխալով, իսկ փոքրը անցնում է, դուք գտել եք սահմանը. հաշվի առեք թունելի հավելյալ ծախսը և կրկնեք, մինչև աշխատող չափը կայունանա։

Ապա հաստատեք, որ բացը հենց հաշվետվությունն է։ Եթե զոնդը ձախողվում է լուռ, առանց սխալի և պատասխանի, հաղորդագրությունը հավանաբար դեն է նետվում, ոչ թե առաքվում, և կասկածելին կանոնն է։

Նեղացրեք կանոնը, ապա նորից ստուգեք առաջադրանքը

Ուղղումը պետք է թույլ տա կոնկրետ կառավարման հաղորդագրություններ, ոչ թե ամբողջ արձանագրությունը։ iptables հոսթում ձևը տիպ-հատուկ թույլտվություն է. հարմարեցրեք շարահյուսությունը նրան, ինչը ձեր հարթակում կառավարում է firewall-ը.

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

Թողեք արձագանք-պատասխանները արգելափակված, եթե դա տեղական քաղաքականությունն է, քանի որ ուղին դրանց կարիքը չունի։ Ապա նորից ստուգեք ի սկզբանե ձախողված փոխանցումը նոր միացումից և հաստատեք, որ կանոնի հաշվիչները ցույց են տալիս հաղորդագրությունների ժամանումը։

Եթե մեծ փոխանցումը դեռ կախվում է հաղորդագրությունները թույլատրելուց հետո, մնացած սահմանափակումը այլ տեղ է. չափազանց բարձր սահմանված թունելի MTU, փաթեթները վերագրող proxy կամ միջանկյալ արկղ, որը դեն է նետում հաղորդելու փոխարեն։ ICMP կանոնը անհրաժեշտ էր, բայց ոչ բավարար։