რატომ არ აღწევს თქვენი /etc/hosts ჩანაწერი VPN-ის DNS-მდე

თქვენ დაამატეთ სახელი /etc/hosts-ში, დაუკავშირდით VPN-ს და ელოდებით, რომ ჩანაწერი ყველასთვის გამოჩნდებოდა. ეს არ ხდება და გაკვირვებას ჩვეულებრივ მეორე სიმპტომიც ახლავს: სახელი თქვენს მანქანაზე წყდება, კოლეგისაზე კი ვერ წყდება, რაც გატეხილ VPN DNS სერვისს ჰგავს და სინამდვილეში hosts ფაილი ზუსტად იმას აკეთებს, რისთვისაც შეიქმნა. hosts ფაილი ლოკალური სახელების ამოხსნის კონფიგურაციაა და არა ზონის განახლება, და ჩვეულებრივ VPN კავშირში ვერაფერი ატვირთავს მას.

hosts ლოკალური გადაფარვაა და არა ზონის განახლება

ფაილი არის დაბმების სია, რომელსაც სახელების სერვისის ბიბლიოთეკები მიმართავენ DNS სერვერზე კითხვამდე ან მის ნაცვლად. 10.40.0.20 build.corp.example-ის მსგავსი ხაზი ცვლის იმას, რასაც ამ ერთ მანქანაზე აპლიკაციები დაასკვნიან. ის არ ქმნის ჩანაწერს, არ გადის გვირაბში და DNS სერვერმა, რომელზეც გვირაბი მიუთითებს, საერთოდ არ იცის მისი არსებობა.

ამიტომ წარუმატებლობა ასიმეტრიულია. თქვენი კლიენტი პასუხს ფაილიდან იღებს. სხვა კლიენტი VPN-ის DNS სერვერს კითხულობს, რომელიც არაფერს აბრუნებს, და აპლიკაცია აცხადებს, რომ სახელი არ არსებობს. ორივე მანქანა სწორად იქცევა; მხოლოდ ერთს აქვს გადაფარვა, რომელიც მეორეს არასოდეს უნახავს.

ორი ბრძანება, ორი განსხვავებული კომპონენტი

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

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

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

თანმიმდევრობა კონფიგურირებადია და ღირს მისი შემოწმება, სანამ რაიმეს დაასკვნით კონკრეტულ დისტრიბუციაზე. შეხედეთ hosts: ხაზს /etc/nsswitch.conf-ში; hosts: files dns ჯერ ფაილებს მიმართავს. ნუ გადააკოპირებთ ამ მაგალითს მუშა კონფიგურაციაზე მხოლოდ თანმიმდევრობის შესაცვლელად, რადგან რეალური სისტემები ხშირად ჩამოთვლიან დამატებით წყაროებსა და პირობით სერვისის ჩანაწერებს, რომლებიც მაგალითში არ არის.

systemd-resolved ტესტს ბუნდოვანს ხდის

systemd-resolved-ის მქონე სისტემაზე ლოკალური stub ასევე ემსახურება სახელებს hosts მონაცემთა ბაზიდან. ამიტომ 127.0.0.53-ზე მოთხოვნა დისტანციური სერვერის დამოუკიდებელი ტესტი არ არის, თუმცა ის DNS მოთხოვნას ჰგავს და ისე იქცევა. შეგიძლიათ დაადასტუროთ, რა იცის resolver-მა და რომელ სერვერებს ჰკითხავდა, ასე:

resolvectl query build.corp.example
resolvectl status

status-ის გამოსავალი ასახელებს DNS სერვერებს თითოეული კავშირისთვის და ასე ადგენთ, მიიღო თუ არა VPN კავშირმა საერთოდ resolver. ეს კითხვა hosts ჩანაწერისგან დამოუკიდებელია და სწორედ ის ღირს დასმად, როცა კერძო სახელი ერთის ნაცვლად ყველა მომხმარებელზე ვერ წყდება.

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

რა ყოფს სახელს VPN-ის გასწვრივ სინამდვილეში

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

hosts ფაილების გავრცელება ლეგიტიმური ალტერნატივაა და ეს საბოლოო წერტილების მართვაა და არა სახელების სერვისი. თუ აირჩევთ მას, ფაილი უნდა განალაგოს, ვერსიებად დაყოს და წაშალოს იმან, ვინც ფლოტს მართავს, და დიზაინში სწორედ ასე უნდა იყოს აღწერილი. „VPN ამას აგვარებს“ ამ პროცესის აღწერა არ არის.

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

ამოხსნილი სახელი მარშრუტი არ არის

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

ამიტომ, როცა ანგარიში ამბობს „სახელი წყდება, მაგრამ სერვისი მიუწვდომელია“, შეადარეთ სისტემის ძიება VPN-ის DNS სერვერზე გამოკვეთილ მოთხოვნას, შემდეგ შეამოწმეთ მიღებული მისამართი იმასთან, რომელსაც სერვისი რეალურად იყენებს. systemd-resolved-ის ცნობარი აღწერს ლოკალურ წყაროებს, რომლებსაც ის მიმართავს, და ეს არის რუკა, რომელიც ამ შედარებისთვის გჭირდებათ.

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