SoftEther SecureNAT: DHCP და NAT ორი ცალკე გადაწყვეტილებაა

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

ორი სერვისი ერთი მონიშვნის უჯრის უკან

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

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

გადაწყვეტილება 1: ვინ აძლევს მისამართს

თუ ვირტუალური DHCP ჩართულია, კლიენტებმა უნდა მიიღონ იჯარა თქვენ მიერ კონფიგურირებულ აუზში, კარიბჭედ ვირტუალური ჰოსტის ინტერფეისი და გადამწყვეტად თქვენ მიერ მოწოდებული. შეამოწმეთ იჯარა და არა კლიენტის სტატუსის ტექსტი, რადგან «დაკავშირებული» გვირაბს აღწერს და არა მისამართის მინიჭებას:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

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

გადაწყვეტილება 2: ვინ გადასცემს ვირტუალური კარიბჭის მიღმა

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

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

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

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

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

ჰოსტის საკუთარი გზა მესამე რამ არის

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

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

მისამართების ოჯახები საკუთარ შემოწმებას იმსახურებენ. მუშა IPv4 DHCP მაგალითი არ ამტკიცებს, რომ თქვენს აწყობაში არსებობს IPv6-ის ყოველი შესაძლებლობა, ამიტომ წაიკითხეთ იმ ვერსიის სახელმძღვანელო, რომელსაც რეალურად უშვებთ, სანამ ორმაგი დასტის ქცევას დაპირდებით. სახელმძღვანელოს SecureNAT-ის განყოფილება მოიცავს ვირტუალური NAT და DHCP ფუნქციებს მიმდინარე გამოცემისთვის.

შეამოწმეთ ყოველი გადაწყვეტილება მისივე ტესტით

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

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

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