VPN-ի ping-ը աշխատում է, բայց կայքը կախվում է. ստուգեք չափը

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

Անցե՛ք ամենափոքր հարցից ամենամեծին և գրի՛ առեք, թե յուրաքանչյուր քայլ ինչ ապացուցեց իրականում։

Արձագանքը պատասխանում է շատ ավելի փոքր հարցի

Արձագանքը ասում է, որ նպատակակետի IP կույտը պատասխանել է ձեր աղբյուրից եկած ICMP հարցմանը։ Այն ոչինչ չի ասում այն մասին, թե արդյոք ձեզ անհրաժեշտ պորտում կա TCP լսող, արդյոք քաղաքականությունը թույլատրում է այդ պորտը, կամ արդյոք նպատակակետ հոսթը զտում է տրաֆիկը դարպասից անկախ։ Դարպասը, որը թույլատրում է մեկ ծառայություն, կարող է գցել մյուսը, մինչ երկու թիրախներն էլ պատասխանում են ping-ին։ Կարդացե՛ք պատասխանը որպես մեկ փաստ մեկ փաթեթի և մեկ ուղղության մասին։

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

Պարզե՛ք՝ արդյոք կապը սկսվել է

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Գրի՛ առեք, թե այդ երեքից որն եք տեսել, նախքան MTU-ի կարգավորումներին դիպչելը։ Թունելի չափը փոխելը՝ մերժված կապը շտկելու համար, վատնում է փոփոխությունը և որոշ ժամանակ թաքցնում իրական պատճառը։

Չափե՛ք չափը նշված թվով

Երբ կանգը հայտնվում է ծանրաբեռնվածության տակ, ստուգե՛ք մեկ փաթեթի չափ՝ բեկորավորումն արգելող բիթով և նշե՛ք հաշվարկը, որպեսզի արդյունքը իմաստ ունենա։ iputils-ով Linux-ում 1392 բայթ օգտակար բեռը գումարած 8 բայթ ICMP վերնագիրը և 20 բայթ IPv4 վերնագիրը տալիս են ուղիղ 1420 բայթ ներքին փաթեթ։ Նշե՛ք այդ հաշվարկը տոմսում, որովհետև դարպասին հասնող մերկ ping-ը ոչինչ չի ապացուցում հավելվածի մասին։

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

Հաշվի՛ առեք արտաքին ուղին

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

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

Փոխե՛ք մեկ թիվ և նորից ստուգե՛ք հավելվածը

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

Պահե՛ք հաշվարկը փոփոխության գրառման մեջ. չափված չափը, ձեր ենթադրած լրացուցիչ ծախսը և ձեր սահմանած արժեքը։ Ով հետագայում վերանայի դա, կկարողանա ստուգել ենթադրությունը՝ ping-ի էկրանակադրից նորից ածանցելու փոխարեն։

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