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

Երկու տրանսպորտ, մեկ շփոթեցնող ախտանիշ

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

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

Որոշեք փորձով, ոչ ինտուիցիայով

Ամենաէժան փորձը անջատում է UDP տվյալների ալիքը և կրկնում հարցումը։ Օգտագործեք հրամանի տողի հաճախորդը սեղանադրական փաթաթանի փոխարեն, որպեսզի դրոշակն իսկապես կիրառվի՝ openconnect vpn.example.net --user=you --interface=tun0 --no-dtls։ Եթե կախված հարցումը հիմա ավարտվում է, DTLS ոտքն էր խնդիրը, իսկ մնացածը աղմուկ էր։

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

Եթե դրոշակը շտկում է, որոշեք ինչու

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

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

Ստուգեք փաթեթի չափը նախքան շրջանցումը պահելը

Եթե չափն է պատճառը, թունելի ինտերֆեյսը ընդունում է փաթեթներ, որ ուղին չի կարող կրել, և խնդիրը վերադառնում է ցանկացած տրանսպորտով հենց որ բեռը մեծանում է։ Համեմատեք ինտերֆեյսները՝ ip link show tun0 հոսթի վրա, ապա docker network inspect bridge՝ ցանցի ընտրանքներում գրանցված MTU-ն կարդալու համար։ Ավելի քիչ կրող թունելի տակ դեռ 1500 բայթի վրա մնացած կոնտեյներային կամուրջը սովորական գտածո է։

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

Որոշեք, թե ինչի եք պատրաստ փոխանակել

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

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

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