რატომ მარცხდება სახელების ძიება მარშრუტიზებულ OpenVPN გვირაბში

ჰოსტი ping-ს მისამართით პასუხობს და ყოველ ძიებაში სახელით მარცხდება. გვირაბი აწეულია და მარშრუტი არსებობს, ამიტომ ბუნებრივი დასკვნაა, რომ VPN არასწორად არის კონფიგურირებული. უფრო სასარგებლო დასკვნაა, რომ ძიება არასდროს ყოფილა მარშრუტიზებადი: მარშრუტიზებული გვირაბი unicast IP-ს ატარებს, ხოლო მოთხოვნა broadcast იყო და ეძებდა სეგმენტს, რომელიც მეორე მხარეს არ არსებობს. როგორც კი შრეების შეუთანხმებლობა თვალსაჩინო ხდება, გადაწყვეტები თავისთავად ლაგდება ღირებულების მიხედვით.

მითი: გვირაბი გატეხილია, რადგან სახელები მარცხდება

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

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

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

რას ატარებს TUN და რას არა

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

აღმოჩენის ტრაფიკი ამ მოდელში საერთოდ არ ჯდება. Windows-ის ძველი სახელის მოთხოვნები, SSDP განცხადებები და mDNS მოთხოვნები იგზავნება სეგმენტის ყველასთან და არა ერთ დანიშნულებასთან. მარშრუტიზებულ კავშირს არ ჰყავს «ყველა», ვისთანაც გააგზავნის. თითოეული ეს მექანიზმი საერთო გარემოს მოითხოვს.

ამიტომ გვირაბი შეიძლება ჯანმრთელი იყოს, სანამ აღმოჩენა სრულად მარცხდება. სწორედ ამ წინადადებას უნდა მივჭიდოთ, როცა ვიღაც იტყობინება, რომ VPN გათიშულია.

ხიდი მუშაობს ზღვრის მოშორებით

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

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

პატარა ლაბორატორიისთვის ეს სამართლიანი გაცვლაა. გაფანტული სამუშაო ძალისთვის — იშვიათად.

DNS-ისა და WINS-ის გაშვება უფრო ვიწრო შესწორებაა

მიეცით კლიენტს კითხვის კონკრეტული ადგილი. dhcp-option DNS და dhcp-option DOMAIN შიდა სახელებს უთითებენ სერვერზე, რომელმაც ზონა იცის, და NetBIOS-ზე დაყრდნობილ Windows კლიენტს იგივე გზით შეუძლია WINS სერვერის მიღება. გვირაბი მარშრუტიზებული რჩება და სეგმენტი თავის ადგილზე რჩება.

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

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

გაარკვიეთ, რომელი შრე გაფუჭდა

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

Multicast იმავე კედლის მიღმაა. 224.0.0.251-ის მსგავსი ჯგუფი ნაგულისხმევად არ გადაეცემა მარშრუტიზებულ გვირაბში, და ჯგუფისთვის მარშრუტი საკმარისი არ არის multicast-ის გამგები გზის ან LAN-ში ამრეკლის გარეშე.