რატომ იზიარებს ბევრი აპის კავშირი ერთ OpenVPN სესიას

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

ერთი გარე საუბარი, ბევრი შიდა ნაკადი

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

არაფერი ინგრევა. შიდა ხუთეულები ბოლომდე რჩება და სწორედ ამიტომ შორეული მხარე კვლავ არჩევს სამ ნაკადს ერთმანეთისგან.

პორტი, რომელიც უცვლელი რჩება

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

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

რას ცვლის დეკაფსულაცია შორეულ ბოლოში

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

ამიტომ გარე ტრანსპორტის დაშვების წესი არ არის იგივე, რაც შიდა სერვისის დაშვება. პირველი აღწერს გზას, მეორე — ნებართვას.

გარე TCP ნიშნავს ერთ ნაკადს და არა ერთ კავშირს

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

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

აღწერეთ საკუთარი კონფიგურაცია ზუსტად

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

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