VPN კლიენტი LAN მისამართით LAN-ზე არ არის

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

მითი: ერთი და იგივე პრეფიქსი ნიშნავს ერთსა და იმავე სეგმენტს

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

როცა სერვერი აგზავნის 10.50.0.200-ზე, ის ადარებს დანიშნულებას საკუთარ ნიღაბს, წყვეტს, რომ მისამართი on-link-ია, და ლოკალურ სეგმენტს ეკითხება იმ ტექნიკურ მისამართს, რომელიც მას ეკუთვნის. ეს მოთხოვნა Ethernet ინტერფეისიდან გადის, და VPN კლიენტი იქ არ არის, რომ გაიგოს.

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

რას აკეთებს რეალურად ლოკალური ჰოსტი მისამართით

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

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

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

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

როგორ უზრუნველყოფს proxy ARP შემდეგ ნაბიჯს

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

MikroTik-ის RouterOS ARP დოკუმენტაცია აღწერს ამ გამოყენებას dial-in კლიენტებისთვის, რომლებიც სესხულობენ დაკავშირებული LAN-ის მისამართთა სივრცეს. მექანიზმი მეზობლების გადაწყვეტის შეკეთებაა, და ის მუშაობს, რადგან კარიბჭე ნამდვილად ორივე გზაზეა.

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

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

რას არ გაძლევთ proxy ARP

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

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

და ის არ ხსნის LAN-ის მფლობელთან კოორდინაციის აუცილებლობას. proxy ARP ჩანაწერი, რომელიც მისამართების გეგმის მფლობელს აკვირვებს, მშვიდ კვირას მომლოდინე მხარდაჭერის შემთხვევაა.

შედარება ცალკე მარშრუტიზებულ პულთან

ალტერნატივაა VPN კლიენტებს მივცეთ საკუთარი პრეფიქსი და LAN ჰოსტებს ნება დავურთოთ იქ მარშრუტიზაცია. მაშინ სერვერი off-link პასუხებს უგზავნის თავის კარიბჭეს, კარიბჭე პრეფიქსს VPN-ის ბოლო წერტილამდე მარშრუტიზებს, და LAN სეგმენტზე მეზობლების გადაწყვეტა საერთოდ არ არის საჭირო. ეს ნაკლები მოძრავი ნაწილია, ვიდრე ნასესხები მისამართი პლუს proxy პასუხი.

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

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