SoftEther-ის ლოკალური ხიდი თუ SecureNAT: რომელი ჩავრთოთ
ლოკალური ხიდი hub-ს ნამდვილ Ethernet სეგმენტზე აყენებს, ხოლო SecureNAT საკუთარ მისამართებს იგონებს. აირჩიეთ ერთი, შემდეგ შეამოწმეთ კარიბჭე და რეზოლვერი.
გახსენით SoftEther Manager, და hub-ის შესახებ პირველი ნამდვილი გადაწყვეტილება არა მოსანიშნი უჯრაა, არამედ ტოპოლოგიის კითხვა. ლოკალური ხიდი ამ hub-ს ფიზიკურ ადაპტერს უერთებს და არსებულ სეგმენტს აძლევს მისამართების მიცემის საშუალებას, ხოლო SecureNAT hub-ს საკუთარ ვირტუალურ როუტერს, NAT-ს და DHCP-ს აძლევს. არჩევანი მათ შორის ცვლის, საიდან მოდის მისამართები და რომელი მოწყობილობა პასუხობს მათთვის. ორივეს ჩართვა და იმის იმედი, რომ ერთი გაიმარჯვებს, ის გზაა, რომლითაც მომუშავე ლაბორატორია დახმარების თემად იქცევა.
დაიწყეთ იმ hub-ით, რომელსაც ნამდვილად არედაქტირებთ
Manager აჩვენებს სერვერებისა და hub-ების ხეს, და ადვილია ნაგულისხმევი hub-ის კონფიგურაცია, მაშინ როცა კლიენტები სხვა სახელის მქონე hub-ს უკავშირდებიან. დააწკაპუნეთ hub-ზე, წაიკითხეთ მისი სახელი და დაადასტურეთ, რომ ქვემოთ ჩამოთვლილი სესიები სწორედ ის კლიენტები არიან, რომლებსაც ემსახურებით. ეს ერთი შემოწმება ხელს უშლის იმ არეულობის დიდ ნაწილს, რომელიც შემდეგ პროტოკოლს მიეწერება.
შემდეგ გადაწყვიტეთ, რა სჭირდება კლიენტს შორეული მხრიდან. საერთო Ethernet-ქცევა მაუწყებლობითა და LAN სერვისებით ხიდისკენ მიუთითებს, მცირე მისამართების დიაპაზონზე მარშრუტიზებული კერძო წვდომა SecureNAT-ისკენ, ხოლო ინტერნეტიდან გასასვლელი მარშრუტიზაციის გადაწყვეტილებაა, რომელიც ორივე განლაგებამ შეიძლება ცუდად ატაროს.
ჩაწერეთ პასუხი სანამ რამეს დააწკაპუნებთ, რადგან ეს ორი პარამეტრი ურთიერთშემცვლელი არ არის და გაუქმებას მეტი დრო სჭირდება, ვიდრე გადაწყვეტილებას. ორი წუთი წერისა ზოგავს ერთ საათს ხელახლა დაკავშირებაში.
რას აკეთებს ლოკალური ხიდი მისამართებთან
ლოკალური ხიდი hub-ს ფიზიკურ ადაპტერს აკავშირებს, ამიტომ hub ხდება იმ Ethernet სეგმენტის ნაწილი. კლიენტები მისამართებს იღებენ იმისგან, რაც უკვე ემსახურება სეგმენტს, და მათი კარიბჭე სეგმენტის როუტერია. კლიენტის თვალსაზრისით, ის ოფისის LAN-ს შეუერთდა, ამასთან დაკავშირებული მთელი ხელმისაწვდომობითა და მთელი ექსპოზიციით.
ეს ასევე ნიშნავს, რომ ხიდს სჭირდება ნამდვილი ადაპტერი სათანადო დრაივერის მხარდაჭერით, და ადმინისტრატორს უნდა ჰქონდეს იმ სეგმენტის გაფართოების უფლება. VPN-ში შესვლა ადასტურებს ავთენტიფიკაციას, არა წარმოების VLAN-ზე ჰოსტის განთავსების უფლებას. შეამოწმეთ, რომ დრაივერის სახელი შეესაბამება თქვენს მიერ განზრახულ ადაპტერს, რადგან არასწორი პორტის ხიდად ქცევა სეგმენტს სწრაფად თიშავს. თუ ადაპტერების სია ცარიელია ან ხიდი წარუმატებლობას იტყობინება, მიზეზი ჩვეულებრივ დრაივერს ან უფლებებს უკავშირდება და არა კრიპტოგრაფიას.
წაიკითხეთ ხიდების ცხრილი ბრძანების სტრიქონიდან, როცა გრაფიკული ხე ორაზროვანია. გამოსავალი ასახელებს ადაპტერს, რასაც ხე ყოველთვის არ აკეთებს.
vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionListცარიელი ხიდების სია დაკავშირებული სესიებით სასარგებლო სურათია: კლიენტები ვირტუალური hub-ის შიგნით არიან და ჯერ არაფერი აფართოებს მას სეგმენტზე.
რას ამატებს SecureNAT და რას მალავს
SecureNAT hub-ს აძლევს ვირტუალურ როუტერს, NAT ფუნქციას და DHCP სერვისს, ყველაფერს SoftEther პროცესის შიგნით. კლიენტები მისამართებს ვირტუალური DHCP დიაპაზონიდან იღებენ, ვირტუალური როუტერი ნაგულისხმევ კარიბჭეს პასუხობს, და გარეთ გასაყვანი ტრაფიკი ითარგმნება. ფიზიკური ადაპტერი მონაწილეობს არა, ამიტომ მუშაობს ჰოსტზე ერთი ქსელური ბარათით და კომუტატორის კონფიგურაციის გარეშე.
ფასი ის არის, რომ ვირტუალური მისამართები hub-ს ეკუთვნის და სხვა არაფერს. ოფისის LAN-ზე მდგარი მანქანა დახმარების გარეშე ვერ მარშრუტიზებს კლიენტის SecureNAT მისამართზე, და ყველაფერი, რაც წყაროს მისამართებს ლოგავს, ხედავს SoftEther ჰოსტის თარგმნილ მისამართს. თუ თქვენი წვდომის წესები ან აუდიტის კვალი კლიენტის ნამდვილ მისამართზეა დამოკიდებული, ეს დიზაინის ცვლილებაა და არა დეტალი. ეს ასევე წყვეტს, დაინახავს თუ არა წყაროს მისამართის წესი კლიენტს საერთოდ.
ის ასევე DHCP სერვერია. მისი გაშვება სეგმენტზე, სადაც უკვე არის ერთი, ან იმ სეგმენტის პარალელურად ხიდად ქცევა, ქმნის ორ პასუხისმგებელს და არაპროგნოზირებად იჯარებს. სახელმძღვანელო ორ ფუნქციას ცალკე არჩევანად განიხილავს ზუსტად ამ მიზეზით.
შეამოწმეთ, რას ემსახურება hub ახლა, სანამ სხვა რამეს ჩართავთ. ყოველი ბრძანება ამობეჭდავს მიმდინარე მდგომარეობას და არა განზრახულს.
vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGetერთის ჩართვა მეორის გატეხვის გარეშე
აირჩიეთ განლაგება, ჩართეთ ის და მეორე გამორთული დატოვეთ. hub, რომელზეც ხიდიც და SecureNAT-იც აქტიურია, hub-ია ერთი და იმავე კითხვის ორი შესაძლო პასუხით, და კლიენტი დაიჯერებს იმას, რაც პირველი მოვა. ერთიდან მეორეზე გადასვლისას გამორთეთ ძველი ფუნქცია და ხელახლა დააკავშირეთ კლიენტი, ნაცვლად იმისა, რომ ჩათვალოთ, რომ ახალი პარამეტრი არსებულ სესიაზე მოქმედებს.
დაალაგეთ ცვლილება ისე, რომ კლიენტების აუზი LAN-ის დიაპაზონს არ გადაფაროს. გადაფარვადი ქვექსელები ტუნელის მეორე ყველაზე გავრცელებული მიზეზია, რომელიც უკავშირდება და შემდეგ ვერსად აღწევს, და ისინი უხილავია, სანამ ორ მისამართთა გეგმას გვერდიგვერდ არ შეადარებთ.
შემდეგ ხელახლა დაუკავშირდით კლიენტიდან და წაიკითხეთ, რა მიიღო, რადგან hub-ის ხედვა სესიაზე არ არის კლიენტის ხედვა საკუთარ ქსელზე. ხელახლა დაკავშირება ახალი იჯარის იძულების ერთადერთი საიმედო გზაა.
შეამოწმეთ კარიბჭე და რეზოლვერი კლიენტზე
წარმატებული ავთენტიფიკაცია გეუბნებათ, რომ მონაცემები მუშაობს და hub-მა სესია მიიღო. ის არაფერს ამბობს იმაზე, აღწევს თუ არა კლიენტი სადმე, რადგან ეს დამოკიდებულია მიღებულ მისამართზე, ნიღაბზე, კარიბჭეზე და DNS სერვერზე. წაიკითხეთ ეს ოთხი მნიშვნელობა კლიენტზე, სანამ სერვერის პარამეტრს კვლავ შეეხებით.
Windows-ზე ადაპტერის დეტალები აჩვენებს იჯარას და რეზოლვერს, ხოლო მარშრუტების ცხრილი აჩვენებს, ტუნელი ნამდვილად ნაგულისხმევი გზაა თუ არა.
ipconfig /all
route print -4
nslookup intranet.corp.internalLinux კლიენტზე იგივე ინფორმაცია მოდის მისამართების, მარშრუტებისა და რეზოლვერის ფაილებიდან. ნაგულისხმევი მარშრუტი ის მნიშვნელობაა, რომელიც წყვეტს, ტრაფიკი საერთოდ გადის თუ არა ტუნელიდან. თუ კარიბჭე ოფისის როუტერზე მიუთითებს, მაშინ როცა ტუნელი ტრაფიკის ტარებას ელის, ტოპოლოგია სახელით არის ხიდად ქცეული და პრაქტიკაში გატეხილი. ჯერ მისამართების წყარო გაასწორეთ, შემდეგ აპლიკაცია ხელახლა გამოსცადეთ და მხოლოდ ამის შემდეგ განიხილეთ მეორე რეჟიმის შეცვლა.