L2TP/IPsec NAT-ის გავლით: რა იშლება სინამდვილეში და რატომ

მტკიცება, რომ NAT L2TP/IPsec-ს ამტვრევს, ნახევრად მართალია და ამიტომ უსარგებლოა. მისამართების გარდაქმნა ნორმალურია, NAT traversal სწორედ ამის გადასატანად არსებობს, და მილიონები კლიენტები ყოველდღე როუტერის უკნიდან უკავშირდებიან. იშლება კონკრეტული გაცვლის კონკრეტული ეტაპი: IKE პასუხს ვერასდროს იღებს, კაფსულირებული გვირაბი უქმდება პოლიტიკით, რომელიც მხოლოდ ერთ პროტოკოლს უშვებს, ან გარდაქმნის მაპინგი იწურება, სანამ გვირაბი უმოქმედოა. როგორც კი გაიგებთ, რომელ ეტაპზე ხართ, გამოსწორება ჩვეულებრივ ერთი წესი ან keepalive-ია და არა ახალი VPN დიზაინი.

მითი არასწორი კითხვაა

სასარგებლო კითხვა არ არის „უშლის თუ არა NAT ამას“, არამედ „გაცვლის რომელი ნაწილი გარდაიქმნება და რას აკეთებს მასთან გარდამქმნელი მოწყობილობა“. L2TP/IPsec ფენოვანი პროტოკოლია: IKE მოლაპარაკებას აწარმოებს, ESP იცავს, და L2TP ამ დაცვის შიგნით PPP-ს გადააქვს. მისამართების გარდაქმნა თითოეულ ფენაზე სხვანაირად მოქმედებს, და უკმარისობის ნიშნები გაირჩევა, თუ შეხედავთ მოლაპარაკების ეტაპს და არა შეცდომის დიალოგს.

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

ეტაპი 1: IKE-მა საერთოდ უნდა მიიღოს პასუხი

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

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

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

ეტაპი 2: კაფსულირება ცვლის იმას, რასაც firewall ხედავს

ESP IP პროტოკოლია და არა TCP ან UDP პორტი, და ჩვეულებრივ პორტის მისამართების გარდაქმნას პორტის ველი არ აქვს გადასაწერად. ამიტომ NAT traversal დაცულ დატვირთვას UDP 4500-ში გადააქვს: კაფსულირება გარდამქმნელ მოწყობილობას აძლევს იმას, რისი გარდაქმნაც იცის. როგორც კი ეს მოხდება, მხოლოდ UDP 500-ისთვის დაწერილი firewall წესი მოლაპარაკებას დაუშვებს და გვირაბს ჩამოაგდებს, რაც იძლევა დამაბნეველ შედეგს, სადაც ჟურნალი აჩვენებს წარმატებულ 1-ლ ფაზას და ტრაფიკს არა.

თავად IKE გაცვლა ასევე შეიძლება გადავიდეს UDP 4500-ზე NAT-ის აღმოჩენის შემდეგ, რაც აკვირვებს მათ, ვინც 500 და სხვა არაფერი დაუშვა. დაუშვით ორივე პორტი ორივე მიმართულებით გზაზე, და გახსოვდეთ, რომ მდგომარეობიანი firewall ნაკადს მხოლოდ მანამ ინარჩუნებს, სანამ ტრაფიკს ხედავს.

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

ეტაპი 3: მაპინგი იწურება და გვირაბი კვდება

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

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

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

ოპერატორის დონის NAT-ის უკან ჰოსტინგი სხვა პრობლემაა

თუ გსურთ სახლში L2TP/IPsec სერვერის ჰოსტინგი და გარედან მასზე მიღწევა, მოთხოვნაა მოუთხოვნელი შემომავალი ხელმისაწვდომობა, და ამას NAT traversal არ იძლევა. ოპერატორის დონის NAT თქვენი როუტერის წინ ნიშნავს, რომ არ არსებობს პორტი, რომლის გადამისამართებითაც ხელმისაწვდომი გახდებით, რადგან საჯარო მისამართი საერთოა და მაპინგი მხოლოდ გამავალია.

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

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