VPN კონტეინერის ქსელის გაზიარება: რა ემართება DNS-ს

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

ნაბიჯი 1: შეამოწმეთ აპიდან, არა ჰოსტიდან

გაუშვით ძიება პრობლემის მქონე კონტეინერის შიგნით, არა ჰოსტზე და არა ბრაუზერში. docker exec app-container getent hosts db.internal პასუხობს ერთადერთ მნიშვნელოვან კითხვას: რას აბრუნებს ამ პროცესის რეზოლვერი.

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

ნაბიჯი 2: წაიკითხეთ runtime-ის მხარდაჭერილი მოდელი

Docker-ის ქსელის დოკუმენტაცია აღნიშნავს შეზღუდვებს DNS დროშებზე კონტეინერებისთვის, რომლებიც სხვა კონტეინერის ქსელურ რეჟიმს იზიარებენ. Compose-ში network_mode: service:vpn აპს აკავშირებს VPN კონტეინერის სახელთა სივრცესთან, და თითოეული სერვისისთვის dns პარამეტრები არ იქცევიან ისე, როგორც ჩვეულებრივი სერვისის შემთხვევაში. მიღებული გარჩევა არის ის, რაც გაზიარებულ სახელთა სივრცეს აქვს.

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

Loopback მისამართი ყოველთვის ეხება შესაბამის ქსელურ კონტექსტს. გაზიარებული სახელთა სივრცის შიგნით, 127.0.0.1 არ არის ჰოსტის რეზოლვერი.

ნაბიჯი 3: მიჰყევით მოთხოვნას მის მიმღებამდე

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

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

ნაბიჯი 4: გამოასწორეთ ორი ხარვეზის კლასი სხვადასხვაგვარად

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

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

ნაბიჯი 5: ხელახალი შექმნის შემდეგ კვლავ შეამოწმეთ

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

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