უნდა გამოიყენოთ SNAT VPN ქვექსელში პორტის გადამისამართებაზე?

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

რატომ იღებს პასუხი სხვა გზას

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

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

წყაროს წესი, საკმარისად ვიწრო ნდობისთვის

როუტერი აქციეთ იმ წყაროდ, რომელზეც შორეული ჰოსტი პასუხობს. ამ განლაგებაში WAN მისამართია 203.0.113.24, LAN არის 192.168.88.0/24, როუტერის გვირაბის მისამართია 172.20.5.1, და სერვისი პასუხობს 172.20.5.40:8443-ზე. ქვემოთ მოცემული წესი ემთხვევა პაკეტს დანიშნულების თარგმანის შემდეგ, ამიტომ ასახელებს თარგმნილ მისამართს და არა საჯაროს. მასში არაფერი არ არის დამოკიდებული კლიენტის მისამართზე, და სწორედ ეს არის აზრი.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

როდის არის საერთო ნიღაბი პატიოსანი არჩევანი

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

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

შეამოწმეთ მთვლელები გამოქვეყნებამდე

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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