Սովորույթն այն է, որ WireGuard-ի սխալ պահվածքի դեպքում անմիջապես իջեցնում են MTU-ն, և այդ սովորույթը թաքցնում է մեկ այլ խափանում։ Դարպասը, որը չի փոխանցում, և ուղին, որը չի տանում մեծ փաթեթներ, տալիս են տարբերակելի պատկերներ՝ մեկը ձախողվում է երկու ուղղությամբ էլ և ամեն չափի դեպքում, մյուսը դիմանում է փոքր հարցումներին և մահանում մեծերի վրա։ Որոշեք, թե որ ձևն ունեք, նախքան որևէ թիվ փոխելը։ Փորձարկումը էժան է և վերացնում է հնարավոր պատճառների կեսը։

Երկու խափանում, երկու տարբեր ձև

Փոխանցման խնդիրը ի հայտ է գալիս սերվերից անմիջապես հետո։ Ձեռքսեղմումը հաջողվում է, թունելի հասցեն պատասխանում է, և դարպասի հետևում ոչինչ հասանելի չէ նույնիսկ փոքրիկ հարցումով։ Փաթեթը հասել է սերվերին և չի փոխանցվել, կամ պատասխանը վերադարձի ուղի չի ունեցել։

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

Այդ նկարագրությունները մատնացույց են անում տարբեր մարդկանց և տարբեր կազմաձևման ֆայլերի, այդ պատճառով ձևը չափելն ավելի արժեքավոր է, քան գուշակելը։ Դարպասին ուղղված մեկ ping չի կարող բաժանել նրանց։

Բացառեք փոխանցումը, նախքան որևէ բան փոքրացնելը

Փորձարկեք դարպասից այն կողմ գտնվող նպատակակետը, ոչ թե դարպասը։ Սերվերի թունելի հասցեին ուղղված ping-ը միայն ապացուցում է, որ ինտերֆեյսը միացած է և որ հասնում եք թունելը ավարտող մեքենային։ Ավելի լայն ցանցի երթևեկությունը կախված է այդ մեքենայի վրա IP փոխանցման միացված լինելուց և փոխանցվող հոսքը թույլատրող firewall-ից։ Երկուսն էլ պետք է ճիշտ լինեն, և եթե մեկը սխալ է, ստացվում է նույն լռությունը։

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

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

Չափեք, թե որտեղից է սկսվում ընդհատումը

Նախ կարդացեք փոխանցման վիճակը և զտման կանոնները։ Սրանք միայն ընթերցման ստուգումներ են և պատասխանում են էժան հարցին՝

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Այնուհետև փորձարկեք չափերը don’t-fragment բիթով, հաճախորդից, դեպի դարպասից այն կողմ գտնվող հոսթ՝

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

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

ObservationPoints towardWhere to look
Nothing beyond the gateway worksForwarding or return routeForwarding flag, filter rules, routing table
Small works, large stallsPacket size on the pathTunnel MTU and the link underneath
Only names failDNS resolutionThe resolver configured for the tunnel
Works sometimesMultiple paths or state expiryFlow selection and NAT state

Վերանորոգեք ձեր ապացուցած շերտը

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

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

Գրեք՝ թե որ ձևն եք դիտել փոփոխությունից առաջ։ Այդ մեկ տողը՝ ուղղման կողքին գրանցված, այն է, ինչը խանգարում է հաջորդ մարդուն իջեցնել MTU, որը երբեք խնդիրը չի եղել։

Առնչվող հոդվածներ