NAT VPN სერვერზე თუ როუტერზე? ორივე შეიძლება მუშაობდეს

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

მითი: კლიენტის მარშრუტი ქმნის გასასვლელს

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

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

ჯერ დახაზეთ პასუხის გზა

ჩაწერეთ გზა რეალური მისამართებით, სანამ რომელიმე პარამეტრს შეეხებით, და მონიშნეთ მასზე თარგმნის ორი შესაძლო წერტილი. ეს ლაბორატორია იყენებს 10.70.0.0/24 VPN აუზს ერთი კლიენტით 10.70.0.37-ზე, სერვერის LAN მისამართით 172.16.40.10, როუტერით 172.16.40.1-ზე და საჯარო გასასვლელით 203.0.113.40-ზე.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

ვარიანტი A: თარგმნა VPN სერვერზე

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

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

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

ვარიანტი B: აუზის როუტერზე გადატანა

მეორე კონფიგურაციაში სერვერი კლიენტის ნამდვილ წყაროს მისამართს გადასცემს, და როუტერი თარგმნის მას. ეს კლიენტების აუზს კიდეზე ხილულს ტოვებს, რაც ეხმარება, თუ როუტერი არის ადგილი, სადაც ტრაფიკის პოლიტიკა, ჟურნალირება ან შემოწმება ცხოვრობს. ეს ასევე ნიშნავს, რომ როუტერს სჭირდება დაბრუნების მარშრუტი 10.70.0.0/24-ისთვის, რომელიც 172.16.40.10-ზე მიუთითებს, პლუს ინტერნეტ პოლიტიკა, რომელიც ნამდვილად მოიცავს ამ პრეფიქსს; LAN ქვექსელისთვის დაწერილი წესი ჩუმად არ ვრცელდება აუზზე.

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

გახადეთ DNS, IPv6 და მიღება ცხადი

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

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

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