VPN მისამართი LAN-ის DHCP იჯარის წინააღმდეგ: ვინ ანიჭებს გვირაბის IP-ს?

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

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

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

წაიკითხეთ გვირაბის მისამართი კლიენტის მხრიდან

Windows განსხვავებას აჩვენებს, თუ მთელ ბლოკს წაიკითხავთ და არა პირველ სტრიქონს. ipconfig /all ბეჭდავს ადაპტერის აღწერას, ფიზიკურ მისამართს და DHCP სტრიქონს. PPP ან IKEv2 აკრეფის ადაპტერი ჩვეულებრივ იტყობინება DHCP-ს გამორთულად, რადგან კავშირმა მისამართი აკრეფის დროს მოილაპარაკა და არ იქირავა LAN სერვერისგან. ჩართული DHCP-ის მქონე გვირაბის ადაპტერი უჩვეულოა და ცალკე გამოკვლევას იმსახურებს.

Linux იმავე ინფორმაციას ორ ხელსაწყოს შორის ყოფს. ip -4 addr show dev tun0 გაძლევთ მისამართსა და პრეფიქსის სიგრძეს. nmcli -f IP4 connection show work ავლენს, მოვიდა თუ არა მნიშვნელობა კავშირის პროფილიდან, ბმულზე მომხდარი DHCP გაცვლიდან თუ დაძალებული კონფიგურაციიდან. WireGuard ყველაზე ნათელი შემთხვევაა, რადგან wg-quick ინტერფეისის გამოჩენისას იყენებს კონფიგურაციის ფაილის Address სტრიქონს და არცერთი წყვილი არაფერს ანიჭებს დაკავშირებისას.

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

რას ატარებს IKEv2 კონფიგურაციის დატვირთვა

IKEv2-ს ამ საქმისთვის გამოყოფილი მექანიზმი აქვს. RFC 7296, 3.15.1 განყოფილებაში აღწერილი კონფიგურაციის დატვირთვა ატარებს ისეთ ატრიბუტებს, როგორიცაა INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS და მათი IPv6 ანალოგები. კლიენტი აგზავნის ნულოვანი სიგრძის მნიშვნელობის ატრიბუტს, როცა უპირატესობა არ აქვს, და პასუხისმგებელი აბრუნებს იმ მნიშვნელობას, რომლის გამოყენებაც სურს. ეს გაცვლა IKE_AUTH-ის შიგნით მიმდინარეობს, უკვე დაშიფრული, ამიტომ არცერთი DHCP გამოცხადება გვირაბს არასდროს კვეთს.

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

ქსელის ნიღბის ატრიბუტი პრაქტიკაში არასავალდებულოა. ბევრი განლაგება მხოლოდ მისამართს აბრუნებს და კლიენტს ჰოსტის მარშრუტის დაყენების საშუალებას აძლევს, ამიტომ ერთი და იგივე აუზი ერთ კლიენტზე შეიძლება /32-ად გამოიყურებოდეს, მეორეზე კი /24-ად.

სად ეჯახება LAN-ის DHCP არე და VPN აუზი

პრობლემა მაშინ იწყება, როცა ორივე გამყოფი ერთსა და იმავე დიაპაზონზე მიუთითებს. 10.20.30.0/24-ისთვის DHCP სერვერმა არაფერი იცის 10.20.30.128/25-ისთვის კონფიგურირებული VPN აუზის შესახებ, ამიტომ ვერაფერი უშლის ხელს 10.20.30.140-ის პრინტერზე გაქირავებაში, სანამ კარიბჭე იმავე მისამართს შორეულ კლიენტს აძლევს. შეჯახება დღეების განმავლობაში ჩუმად რჩება და შემდეგ პერიოდული დუბლიკატის სახით ვლინდება.

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

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

შეამოწმეთ, რომელ პროცესს ეკუთვნის მისამართი

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

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

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

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

დაკავშირებული სტატიები