თქვენი VPN-პული არ არის LAN-ის DHCP დიაპაზონი: რატომ იშლება

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

ორი გამანაწილებელი, ერთი მისამართების სივრცე

LAN-ის DHCP სერვერმა იცის, რომელი მისამართები იქირავა და რომელ MAC მისამართზე, და ARP-ით იცავს მათ. VPN სერვერს საკუთარი პული აქვს და ამ იჯარების შესახებ არაფერი იცის. არც ერთი არ ცდება; უბრალოდ არასდროს გააცნეს ერთმანეთი.

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

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

რატომ არ ანაწილებს როუტერი VPN მისამართებს

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

ამიტომ VPN სერვერი თავად ანიჭებს მისამართს: პული სერვერის კონფიგურაციაში, მისამართი თითო პარტნიორზე WireGuard-ის კონფიგურაციაში, ან მისამართი, რომელსაც ავთენტიფიკაციის ფენა უბიძგებს IKEv2-ის განლაგებაში. ეს მექანიზმები დამოუკიდებელია LAN-ის იჯარების მონაცემთა ბაზისგან, და სწორედ ამიტომ სჭირდებათ საკუთარი დიაპაზონი.

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

გადაფარვა კონფლიქტად ვლინდება, არა როგორც ნელი ქსელი

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

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

დაბრუნების გზა ცალკე პრობლემაა

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

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

ეს ბრძანებები აჩვენებს გადაგზავნის გადაწყვეტილებას კარიბჭეზე და მეზობლის ჩანაწერებს, რომლებიც დუბლიკატს ავლენს:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

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

ხიდური დიზაინები არსებობს, მაგრამ ისინი უნდა აირჩიოთ

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

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

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