VPN როუტერზე თუ პორტის გადამისამართება: რომელი იმარჯვებს?

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

ერთი პორტი, ორი მოპოვებული მფლობელი

როუტერის შიგნით მომუშავე VPN სერვერს სჭირდება შემომავალი ნებართვა, რომელიც მის საკუთარ სოკეტამდე მიდის. იმავე პორტის დანიშნულების NAT ჩანაწერი სრულიად სხვაგან მიდის: LAN მისამართსა და გადამისამართების გადაწყვეტილებაზე. ეს სხვადასხვა ბოლო წერტილებია სხვადასხვა ჟურნალებითა და სხვადასხვა მარცხის რეჟიმით. ჩვეულებრივი ნიშანია, რომ ერთი მისამართების ოჯახი მუშაობს, მეორე კი არა, რადგან დარჩენილი ჩანაწერი ერთი ოჯახისთვის დაიწერა და არასოდეს გადახედილა.

ჩაწერეთ მოთხოვნა რედაქტირებამდე: ოჯახი, გარე მისამართი, ტრანსპორტი, პორტი და თარგმნილი სამიზნე.

თარგმანი ადგილობრივ შემოწმებამდე მუშაობს

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

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

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

თუ LAN ჰოსტი არის განზრახული ბოლო წერტილი, გადამისამართება სწორია და როუტერს იმავე პორტზე ასევე არ უნდა მოუსმინოს.

შეინარჩუნეთ ერთი რუკება და წაშალეთ მეორე

ჩამოთვალეთ NAT ჩანაწერები ამ პორტისა და ოჯახისთვის და აირჩიეთ გადარჩენილი:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

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

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

დაადასტურეთ მფლობელი გარედან

შეამოწმეთ თითოეული ოჯახი ცალკე, რადგან როუტერზე დამთავრებული IPv6 კავშირი არაფერს ამბობს იმ IPv4 კავშირზე, რომელსაც ძველი წესი გადამისამართებს. წაიკითხეთ მიმღები სერვისის ჟურნალი, რომ ნახოთ რომელმა ბოლო წერტილმა უპასუხა, და კლიენტის წარმატების შეტყობინება სუსტ მტკიცებულებად ჩათვალეთ. შინაარსიანი ტესტისთვის ახალი ნაკადია საჭირო. გაგზავნეთ ზონდი გარე ჰოსტიდან nc -zvu 203.0.113.7 1194-ით და წაიკითხეთ გამარჯვებულის ჟურნალი journalctl -u openvpn@server -n 20-ით. როუტერის მსმენელი თავად აღრიცხავს კავშირს, ხოლო LAN ჰოსტი მას საკუთარ სერვისში აღრიცხავს.

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

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