რატომ აგზავნის LAN-ის ჰოსტი ARP-ს OpenVPN კლიენტის მისამართზე

ხელმისაწვდომობის პრობლემები LAN-ის ჰოსტსა და VPN კლიენტს შორის ხშირად თავად მისამართების გეგმას უბრუნდება. მიეცით ამ ჰოსტს ინტერფეისი 10.0.100.0/22-ზე და ის ყველა მისამართს 10.0.100.0-დან 10.0.103.255-მდე პირდაპირ დაკავშირებულად ჩათვლის, მათ შორის 10.0.101.0/24-ზე ჩუმად განთავსებულ კლიენტების აუზს. პასუხი არასოდეს მიდის მარშრუტიზატორზე, რადგან ჰოსტის თვალსაზრისით არც ერთი მარშრუტიზატორი არ მონაწილეობს. პაკეტი მიმართულია მეზობლისკენ და მოითხოვება მავთულზე.

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

/22, რომელიც ყლაპავს /24-ს

წაიკითხეთ პრეფიქსი დიაპაზონად და არა სტრიქონად. /22 პრეფიქსი შეიცავს 1024 მისამართს და 10.0.100.0/22 ვრცელდება 10.0.100.0-დან 10.0.103.255-მდე, ამიტომ 10.0.101.0/24-ზე მყოფი აუზი მთლიანად მის შიგნითაა. შეცდომა გადარჩება განხილვას, რადგან აუზის პირველი ოქტეტები განსხვავებულად გამოიყურება LAN-ის პირველი ოქტეტებისგან და მხოლოდ მესამე ოქტეტი ამჟღავნებს ჩადგმას. ჩამოწერეთ ორივე დიაპაზონი რიცხვებით, სანამ მათ ცალკეულებად გამოაცხადებთ.

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

პირდაპირი კავშირი ნიშნავს ARP-ს და არა მარშრუტიზაციას

როცა /22 ინტერფეისის მქონე ჰოსტი აგზავნის 10.0.101.25-ზე, ბირთვი ადარებს დანიშნულებას ინტერფეისის პრეფიქსს და პოულობს დამთხვევას. პაკეტი მარშრუტიზებული პაკეტის ნაცვლად მეზობლის ძიებად იქცევა, ხოლო Ethernet-ზე მეზობლის ძიება ამ მისამართისთვის ARP მოთხოვნაა. თუ მისამართი ეკუთვნის მარშრუტიზებული კარიბჭის უკან მყოფ VPN კლიენტს, LAN-ში არც ერთი ჰოსტი არ ფლობს მას, ამიტომ მოთხოვნა უპასუხოდ რჩება და პაკეტები იკარგება. გვირაბი არ არის დამნაშავე და კლიენტი ტრაფიკს არასოდეს ხედავს.

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

TUN, TAP და რას ატარებს თითოეული

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

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

დააპროექტეთ აუზი, რომელიც ვერ გადაიფარება

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

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

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