რატომ არ არის ერთი LAN ერთი და იმავე ქვექსელის მქონე ორი საიტი

ორი ოფისი ორივე იყენებს 192.168.77.0/24-ს და ვიღაც გვირაბს გვთავაზობს, რომ ისინი ერთი ქსელი გახდნენ. ეს ფრაზა მარტივად ჟღერს და სამ განსხვავებულ დიზაინს მალავს: ორი დამოუკიდებელი LAN, რომლებიც ერთმანეთს ეჯახება, ერთი განზრახ WAN-ზე გაწელილი Ethernet სეგმენტი და proxy-ARP მოწყობა, რომელიც შორეულ მისამართებზე პასუხობს. რომელი გაქვთ, განსაზღვრავს რას აკეთებს ჰოსტი პაკეტთან და პასუხი ჩანს მანამ, სანამ VPN კარიბჭე ჩაერთვება.

ჰოსტი როუტერზე ადრე წყვეტს

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

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

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

ARP ლოკალური ბმულის კითხვაა

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

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

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

გაწელილი სეგმენტი კადრებს ატარებს და არა მარშრუტებს

Ethernet-ის მატარებელი გვირაბი, რომელიც ხიდებზეა მიმაგრებული, ორივე საიტს ერთი ბმულის დონის დომენის ნაწილად აქცევს. ARP მაუწყებლობა მეორე მხარეს აღწევს და თითოეული ხიდი სწავლობს, სად რომელი MAC მისამართია. Linux-ის ხიდის დოკუმენტაცია აღწერს ამ MAC-ზე დაფუძნებულ გადაცემის საზღვარს.

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

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

Proxy ARP მესამე დიზაინია

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

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

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

აირჩიეთ მოთხოვნიდან, შემდეგ გადაამოწმეთ

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

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

ip route get 192.168.77.20
ip neigh show 192.168.77.20

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