რატომ სჭირდება L2TP/IPsec-ს UDP 1701 IPsec-ის გარდა

ფაირვოლები, რომლებიც უშვებენ IKE-ს და ESP-ს, მაგრამ არა UDP 1701-ს, ამტვრევენ L2TP კავშირებს ისე, რომ ეს საიდენტიფიკაციო მონაცემების პრობლემას ჰგავს. მიზეზი ისაა, რომ L2TP მეორე პროტოკოლია, რომელიც პირველის შიგნით მოძრაობს. IPsec ატარებს და ამოწმებს გაცვლას, ხოლო L2TP საკუთარ გვირაბს UDP 1701-ზე უშვებს, რომელიც ლოკალურ სტეკს მაინც უნდა მიაწოდოს. იმის ცოდნა, სად ჩნდება თითოეული სათაური, ხსნის, რომელ მოწყობილობას რომელი წესი სჭირდება.

ორი პროტოკოლი, ორი პორტების ნაკრები

L2TP/IPsec კავშირი იყენებს IKE-ს UDP 500-ზე, NAT-ის გავლას UDP 4500-ზე იქ, სადაც თარგმანია, და ESP-ს, როგორც IP პროტოკოლს 50, იქ, სადაც არაა. თავად L2TP გვირაბური პროტოკოლია UDP 1701-ზე და მუშაობს მას შემდეგ, რაც IPsec პარტნიორს ამოწმებს. ორი ნახევარი სხვადასხვაგვარად ფარდება, და მათ შესახებ მოხსენებული ჟურნალის ხაზები სხვადასხვა კომპონენტიდან მოდის. მხოლოდ პირველ ნახევარს დამფარავი წესების ნაკრები ქმნის კავშირს, რომელიც მოლაპარაკებას აწარმოებს და შემდეგ გვირაბის ეტაპზე კვდება.

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

გარსი ხსნის პორტს

ქსელში L2TP/IPsec კავშირი ჩვეულებრივ გვიჩვენებს IKE-ს 500-ზე და შეფუთულ ESP-ს 4500-ზე. UDP 1701 სათაური დაცული დატვირთვის შიგნით ზის, ამიტომ გარე ინტერფეისზე გაკეთებული გადაღება მას არ აჩვენებს. ლოკალურ ჰოსტს მაინც უნდა მიუტანოს ეს დატაგრამა L2TP დემონს, და მიწოდება დეკაფსულაციის შემდეგ ხდება. ამიტომ 1701 წესი თავად ბოლო წერტილის ფაირვოლს ეკუთვნის, მაშინაც კი, როცა არც ერთი შუალედური მოწყობილობა არასოდეს ხედავს პორტს.

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

შეამოწმეთ გზა რიგითობით

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

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

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

რას ვერ აჩვენებს პორტის სკანირება

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

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