იგივე ქვექსელი ორივე ბოლოში: გადაიტანეთ შორეული LAN თავისუფალ დიაპაზონში

სახლი და ოფისი ორივე 192.168.1.0/24-ს იყენებს, ამიტომ 192.168.1.1-ზე მოთხოვნას ორი შესაძლო პასუხი აქვს და კლიენტი ერთს ირჩევს კითხვის გარეშე. მომუშავე ოფისის ქსელის ხელახალი ნუმერაცია იშვიათად პოპულარულია, და როუტერის მისამართები ხშირად ჩაშენებულია პრინტერებში, კამერებსა და დოკუმენტაციაში. კლიენტის მხარეს მისამართების ასახვას შეუძლია სამაგიეროდ შორეული ქსელი თავისუფალი დიაპაზონის ქვეშ წარმოადგინოს, და ჰოსტის ნაწილი შეიძლება იგივე დარჩეს, რათა 192.168.1.20 გამოჩნდეს როგორც 10.203.41.20. ხარვეზი ის არის, რომ მას მხოლოდ ზოგიერთი კლიენტი ახორციელებს, და ის არაფერს აკეთებს დაბრუნების გზისთვის.

ერთი და იგივე ჰოსტის ორი ხედი

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

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

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

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

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

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

ასახვა დაბრუნების გზას არ ქმნის

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

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

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

სახელები და payload-ები თარგმანს გადაურჩება

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

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

სამი შემოწმება ვალდებულების აღებამდე

პირველი, დაადასტურეთ კლიენტის იმპლემენტაცია. Community OpenVPN მხარს უჭერს ამ ოფციას; OpenVPN 3-ის კოდის ბაზა მას მხარდაუჭერელი ფუნქციების სიაში ასახელებს, ამიტომ Connect სტილის კლიენტზე გაგზავნილმა პროფილმა შეიძლება უბრალოდ უგულებელყოს ის. მიღებული და არასდროს გამოყენებული დირექტივა შეცდომაზე უარესია, რადგან გვირაბი ჯანსაღად გამოიყურება.

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

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