კონტეინერის HTTPS კორპორატიულ VPN-ში იჭედება? შეამოწმეთ DTLS ფეხი

კორპორატიული 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 ექსპერიმენტის ნაშთი.