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

რატომ გამოიყურება ნიღაბი არასწორად გვირაბის კავშირზე

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

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

ორი ტოპოლოგია, მისამართის ორი ფორმა

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

TopologyClient address shapePeerRoute to expect
Point-to-point block per clientTwo neighbouring addresses inside a small blockThe far address of that blockA single host route on the tunnel device
Shared poolOne address carrying the pool maskThe server's tunnel addressA single host route on the tunnel device

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

როცა აუზი და ოფისის ქსელი ერთსა და იმავე ბიტებს ითხოვენ

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

მხოლოდ მსგავსი პრეფიქსები სხვა შემთხვევაა და ოქტეტების თვალით შედარება პრეფიქსების შედარება არ არის. ჩაწერეთ ორივე და დათვალეთ ნიღბიანი ბიტები: 192.168.4.0/24 წინააღმდეგ 192.168.6.0/24 ემთხვევა 22-ე ბიტამდე და 23-ე ბიტზე იყოფა, რადგან მესამე ოქტეტი იკითხება როგორც 00000100 წინააღმდეგ 00000110, ამიტომ ეს ორი ქსელი ნამდვილად ცალკეა. მოათავსეთ 10.8.0.0/24 სხვა 10.8.0.0/24 გვერდით და ყველა 24 ნიღბიანი ბიტი ემთხვევა, რაც ნიშნავს, რომ ერთი მარშრუტი ვერ გამოხატავს ორივე ადგილს. ნიღბის სიგრძე წყვეტს, სად გაჩერდეს შედარება, და მეორედ დაყენებული ქსელი არის ის, რომელიც აგებს.

რასაც მარშრუტიზებული კავშირი ვერ მიაწვდის

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

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

ინტერფეისის კითხვა პროფილის რედაქტირებამდე

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

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

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

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