ip netns exec და DNS: რატომ ვარდება სახელები სახელთა სივრცის შიგნით

ბრძანება აღწევს 10.8.0.5-მდე VPN-ის სახელთა სივრცის შიგნით ყოველგვარი ჩივილის გარეშე, და იგივე ბრძანება ვარდება იმ მომენტში, როცა ის ჰოსტის სახელს იყენებს. სახელთა სივრცეს აქვს საკუთარი ინტერფეისები, მარშრუტები და სოკეტები; მას არ აქვს საკუთარი გადამწყვეტის ფაილი. თუ რაღაც არ დადებს იქ ერთს, შიგნით მყოფი პროცესი კითხულობს ჰოსტის /etc/resolv.conf-ს და ეკითხება სერვერს, რომელიც შეიძლება მიუწვდომელი იყოს ამ ქსელური დასტიდან.

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

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

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

ip netns add-ით შექმნილი სახელთა სივრცისთვის მხოლოდ-წაკითხვის შემოწმება მოკლეა:

ip netns exec vpn cat /etc/resolv.conf

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

რას მონტირებს სინამდვილეში exec-ის დამხმარე

ხელსაწყო ip-netns აღწერს თითოეული სახელთა სივრცის კონფიგურაციას /etc/netns/NAME/-ის ქვეშ. როცა ის პროცესს უშვებს, დამხმარე ქმნის მონტირების სახელთა სივრცეს და ამ ფაილებს მათ ჩვეულებრივ ბილიკებზე მონტირებს, ასე რომ პროცესი ხედავს სახელთა სივრცისთვის სპეციფიკურ ასლს. ეს ამ კონკრეტული გამშვების კომფორტია. ქსელურ სახელთა სივრცეში სხვა გზით შესვლა, მაგალითად unshare-ით ან კონტეინერის runtime-ით, ამას ავტომატურად არ იმეორებს.

აქ ხაფანგი loopback-ის გადამწყვეტია: 127.0.0.53 ნიშნავს თავად სახელთა სივრცის loopback-ს და არა ჰოსტის სტაბს. სტაბი, რომელიც მხოლოდ ჰოსტის სახელთა სივრცეში უსმენს, ახალში სერვისად არ იქცევა.

აირჩიეთ გადამწყვეტი, რომელსაც სახელთა სივრცე მიაღწევს

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

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

ჩაწერეთ ფაილი სწორ ადგილას

შექმენით სახელთა სივრცისთვის სპეციფიკური ფაილი /etc/netns/NAME/resolv.conf-ის ქვეშ და მიეცით გამშვებს მისი წარდგენის საშუალება. შეინახეთ ის მინიმალური: ერთი ან ორი მისაწვდომი სერვერი და საძიებო დომენები, რომლებიც დავალებას სჭირდება. ნუ შეასწორებთ ჰოსტის გენერირებულ გადამწყვეტის ფაილს ერთი პროცესების ჯგუფისთვის განკუთვნილი ხედის გასწორებისთვის, რადგან ეს ცვლის მანქანის ყველა აპლიკაციას. თუ ჰოსტი იყენებს გადამწყვეტის მმართველს, დააკონფიგურირეთ სახელთა სივრცის ბილიკი ამ მმართველის მეშვეობით და არა მასთან ბრძოლით.

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

ხელახლა გამოსცადეთ მთელი გზა

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

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