დიდი ჩამოტვირთვები VPN-ის წინააღმდეგ: აირჩიეთ გზა მოთხოვნისას

„დიდი ჩამოტვირთვები VPN-ის გვერდით გაგზავნე, ხოლო პატარა პასუხები მასზე დატოვე“ მარშრუტიზაციის პოლიტიკას ჰგავს, მაგრამ არ არის. მარშრუტიზატორი გადაწყვეტს იმ მომენტში ხელმისაწვდომი ინფორმაციით: მისამართები, პორტები, პროტოკოლი, firewall-ის ნიშნები, იდენტიფიცირებული ნაკადი. პასუხის საბოლოო ზომა ამ სიმრავლეში არ არის, რადგან ის ჯერ არ მოსულა, და როცა მარშრუტიზატორს ბაიტების გაზომვა შეეძლებოდა, ის უკვე გადააქვს მათ. თუ გსურთ დავალების მიხედვით მართვა, გადაწყვეტილება უნდა გადავიდეს წერტილში, რომელმაც დავალება იცის, და ქვემოთ მოცემული სია გვიჩვენებს, აქვს თუ არა თქვენს დიზაინს ასეთი წერტილი.

რატომ ვერ ზომავს მარშრუტიზატორი პასუხს

იმ მომენტში, როცა პაკეტს მარშრუტი სჭირდება, მარშრუტიზატორს უნახავს ნაკადის მაქსიმუმ პირველი რამდენიმე პაკეტი. მას შეუძლია თქვას, ვინ ვის ესაუბრება, რა პროტოკოლით, რა ნიშნით და რამდენი ბაიტი გავიდა აქამდე. აქამდე გავლილი ბაიტები წარსულს აღწერს. პასუხის ზომა ჯერ შეუქმნელი პასუხის თვისებაა, და დაყოფილ ან ნაკადურ პასუხებში შესაძლოა ის არასოდეს იყოს წინასწარ ცნობილი.

თვით პროტოკოლის მეტამონაცემებიც უფრო სუსტია, ვიდრე ჩანს. HTTP უშვებს პასუხებს, რომელთა სიგრძე სხეულამდე არ გამოცხადდება, და ერთმა მომხმარებლის ქმედებამ შეიძლება ბევრი მოთხოვნა წარმოქმნას, რომელთა საერთო ღირებულება არც ერთი სათაურის მნიშვნელობას არ ჰგავს. სათაურის დავალების ზომად მიჩნევა მოდელირების შეცდომაა, სანამ მარშრუტიზაციის შეცდომა გახდება.

შემოწმება 1: არსებობს გადაწყვეტილების წერტილი, რომელსაც გზის არჩევა შეუძლია?

დაასახელეთ კომპონენტი, რომელიც არჩევანს გააკეთებს, შემდეგ დაასახელეთ, რა იცის არჩევის მომენტში. განახლების პროგრამა, რომელიც დოკუმენტირებული ჰოსტების სიმრავლიდან იღებს, თავის მიზანს გადაცემის დაწყებამდე იცის. ჩამოტვირთვის სერვისი, რომელიც მეტამონაცემებს ამოწმებს და შემდეგ ხსნის მოთხოვნას, დავალებას კავშირის არსებობამდე იცის. თანამშრომლობითი proxy შეიძლება გამოიყენოს მოთხოვნის დონის პოლიტიკა ან ქეშში შეინახოს პასუხი, თავი მარშრუტიზატორად რომ არ მოაჩვენოს.

თუ პასუხი „კარიბჭეა“, სია უკვე ჩავარდა. კარიბჭეს შეუძლია ცნობილი ნაკადები დააჯგუფოს დანიშნულების, ნიშნის ან კლიენტის სეგმენტის მიხედვით და პირველი პაკეტიდან განსაზღვრულ გზაზე გაგზავნოს, რაც ხშირად საკმარისია დამტკიცებული განახლების პროგრამისთვის და არასოდეს არის საკმარისი უცნობი პასუხის ზომისთვის.

შემოწმება 2: რას გეუბნებათ მეტამონაცემები სინამდვილეში?

აპლიკაციის გაცნობიერებული მართვა ისეთივე კარგია, რამდენადაც კარგია ველები, რომლებსაც კითხულობს. პასუხის სიგრძის წესები HTTP-ის სემანტიკა-ში უშვებს შემთხვევებს, როცა სიგრძე დასაწყისში ხელმისაწვდომი არ არის, და შიგთავსის კოდირება მაინც გადაცემული ბაიტების რაოდენობას წარმოდგენის ზომისგან განსხვავებულს ხდის. ამიტომ სათაურის ზღვრის გადალახვისას გზის შემცვლელი პოლიტიკა არათანმიმდევრულად მოიქცევა, და ძირითადად სწორედ იმ დიდ გადაცემებზე, რომლებიც უნდა დაეჭირა.

რასაც აპლიკაციის მეტამონაცემები შეიძლება დაეყრდნოს, დავალების შესახებ გადაწყვეტილებაა: ეს სამუშაო ნაკადი მასობრივი სინქრონიზაციაა, ეს ინტერაქტიულია, ეს ცნობილი წყაროდან პროგრამული განახლებაა. ეს განზრახვის ენით დაწერილი პოლიტიკაა და საკმარისად სტაბილურია გამოსაცდელად. „ეს პასუხი ორმოც მეგაბაიტზე დიდი იქნება“ ასეთი პოლიტიკა არ არის.

შემოწმება 3: ნაკადი უკვე არსებობს?

მარშრუტიზაცია შეიძლება შეიცვალოს ნაკადისთვის კავშირის იდენტობის შეცვლის გარეშე, და ეს განსხვავება ღირს ზუსტად შენარჩუნებას. TCP კავშირი იდენტიფიცირდება მისი ბოლოების მისამართებით და პორტებით, და პაკეტებს შეუძლიათ სხვა გზა აიღონ, თუ მარშრუტიზაციის ცხრილი მათ ქვეშ შეიცვლება. რაც უხილავად ვერ შეიცვლება, ქსელური მისამართების თარგმნის მდგომარეობაა: ტრაფიკის სხვა გასასვლელზე გადატანა ჩვეულებრივ ცვლის საჯარო წყაროს კორტეჟს, და შორეული მხარე დაინახავს სხვა პარტნიორს შესაბამისი მდგომარეობის გარეშე.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

ასე რომ პრაქტიკული წესია: კავშირის შუაში ერთი გასასვლელიდან მეორეზე გადატანა ახალი ურთიერთობაა, არა მიგრაცია. თუ დიზაინი მოითხოვს, რომ იგივე კავშირი გაგრძელდეს, გადაწყვეტილება პირველ SYN-მდე უნდა მიღებულიყო, და მოგვიანებით დამატებული არც ერთი პაკეტის წესი ვერ აღადგენს მას სუფთად.

შემოწმება 4: ნამდვილი მოთხოვნა დაყოვნებაა და არა გასასვლელი?

ძალიან ბევრი მოთხოვნა „მასობრივი ტრაფიკი სხვაგან გაგზავნე“ სინამდვილეში ჩივილია, რომ დიდი გადაცემა ინტერაქტიულ მუშაობას ნელი შეგრძნობით ატარებს. ეს დაგეგმვის პრობლემაა და მას დაგეგმვის პასუხი აქვს: სამართლიანი რიგი ან არსებულ გზაზე მხარდაჭერილი გამტარობის პოლიტიკა ხელს უშლის მასობრივ ნაკადს ჩატის შეტყობინების გაშიმშვილებაში, არც ერთის გადაადგილების გარეშე.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

სიმპტომთან ასე მიდგომა გასასვლელის გადაწყვეტილებას იქ ტოვებს, სადაც უსაფრთხოების პოლიტიკამ დადო, და ის ერთი ბრძანებით შექცევადია. მთელი ტრაფიკის კლასისთვის გასასვლელის შეცვლა პოლიტიკის ცვლილებაა ავთენტიფიკაციის, ჟურნალირებისა და წვდომის წესების შედეგებით, ამიტომ ის არ უნდა იყოს პირველი ინსტრუმენტი დაყოვნების ჩივილისას.

თუ მოთხოვნა ნამდვილად სხვა ინტერნეტ გასასვლელია, თქვით ეს სწორედ იმ სიტყვებით და განახორციელეთ მხარდაჭერილ საზღვარზე: ახალი კავშირი დამტკიცებული სამუშაო ნაკადიდან, ან აპლიკაცია, რომელიც საკუთარ მოთხოვნას არჩეული გასასვლელით ხსნის. შემდეგ ჩაწერეთ, რომელი დავალებები რომელ გასასვლელს იყენებენ, რომ შემდეგ ადამიანს ეს მარშრუტიზაციის ცხრილიდან არ მოუწიოს გამოცნობა.

შეინახეთ სია ცვლილების ჩანაწერში: გადაწყვეტილების წერტილი, მისი მამოძრავებელი ველი ან დავალება, არსებობს თუ არა ნაკადი უკვე და იყო თუ არა გაზომილი სიმპტომი დაყოვნება თუ გასასვლელი. ოთხი კითხვა, და პოლიტიკა, რომელიც ოთხივეს პასუხობს, ისეთია, რომლის ოპერირებაც შეგიძლიათ და არა დაცვა.