VPN NAT-ის უკან, რომელსაც ვერ აწყობთ: რა მუშაობს ჯერ კიდევ

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

რუკების ცხრილი ყველაფერს წყვეტს

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

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

რა შეუძლია და რა არ შეუძლია შეხვედრის სერვისს

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

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

Keepalive, გადატვირთვები და მოძრავი ბოლო წერტილი

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

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

სამი გზა დაკარგული გადამისამართების გვერდის ავლით

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

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

შეუსაბამეთ შემოვლითი გზა როუტერის მფლობელს

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

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