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

ოთხი გადაწყვეტა, ოთხი განსხვავებული დაპირება

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

DesignWho initiatesPromise you getPromise you do not get
Routed VPN hubBoth ends, outbound to the hubA routed path to permitted prefixesAccess to services no policy allows
Peer traversal with ICEBoth peers to a rendezvous serviceA path tested between the two peersA direct path through every NAT
TURN relayClient outbound to a relayTransport that survives symmetric NATPeer discovery or a usable directory
Application brokerWorkstation outbound to a brokerOne audited application sessionSubnet-wide reachability

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

ჰაბი ცვლის იმას, ვინ გადის გარეთ, და არა იმას, რა არის ნებადართული

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

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

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

გავლა მუშაობს მხოლოდ მაშინ, როცა ორივე სტეკი ახორციელებს მას

თანასწორებს შორის გავლა კონკრეტული სისტემის შესაძლებლობაა და არა VPN-ის გამაუმჯობესებელი პარამეტრი. Interactive Connectivity Establishment აგროვებს რამდენიმე კანდიდატ მისამართს და ამოწმებს წყვილებს, სანამ ერთი იმუშავებს: ჰოსტის კანდიდატები ლოკალურ ინტერფეისებზე, სერვერის ამრეკლავი კანდიდატები, აგებული იმაზე, რასაც NAT ამჟღავნებს, და რელეზე გამოყოფილი რელეს კანდიდატები. მხოლოდ კერძო მისამართი გზა არ არის, რადგან მეორე მხარეს მასთან მარშრუტიზაცია არ შეუძლია.

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

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

ბროკერი ქსელზე უფრო ვიწროა

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

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

შეადარეთ ნდობის საზღვრები, შემდეგ შეამოწმეთ გზა

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

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

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

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

დაკავშირებული სტატიები