პირადი DNS მუშაობს VPC-ში, მაგრამ არა VPN-ის გავლით
პირადი სახელი, რომელიც წყდება EC2-ის შიგნით, მაგრამ არა VPN-ის გავლით, resolver-ის გზის პრობლემაა. წაიკითხეთ მარცხის ფორმა, სანამ ზონის ჩანაწერს შეცვლით.
პირადი სახელი წყდება EC2 ინსტანციიდან, მაგრამ არა VPN-ით დაკავშირებული ლეპტოპიდან, და ზონა კონსოლში სწორად გამოიყურება. პირველი იმპულსია ჩანაწერის რედაქტირება, რაც თითქმის არასდროს არის პრობლემა. ჩანაწერი ვიღაცას პასუხობს; უბრალოდ თქვენს ლეპტოპს არ პასუხობს. განსხვავება ორ აბონენტს შორის არის რომელ resolver-ს ეკითხებიან და აქვს თუ არა ამ resolver-ს მხარდაჭერილი გზა VPC-ის DNS ხედში.
ვიწყებ იმის დამტკიცებით, რომ ჩანაწერი არსებობს, დარჩენილ დროს კი მოთხოვნის გზაზე ვხარჯავ. ეს განსხვავებული სისტემებია და სხვადასხვაგვარად ფუჭდება.
წაიკითხეთ მარცხის ფორმა, სანამ რამეს შეცვლით
სამი შედეგი სამ სხვადასხვა რამეს ნიშნავს და ერთი მოთხოვნა განასხვავებს მათ: გაუშვით dig სახელისთვის იმ resolver-ის წინააღმდეგ, რომელსაც კლიენტი რეალურად იყენებს.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
დროის ამოწურვა ქსელის შესახებ განცხადებაა. NXDOMAIN არის განცხადება DNS ხედის შესახებ. საჯარო პასუხი განცხადებაა პოლიტიკის შესახებ. ზონის ჩანაწერის რედაქტირება დროის ამოწურვის დროს საქმის ერთადერთ სასარგებლო მტკიცებულებას აგდებს.
რატომ VPC-ის პლუს ორი მისამართი არ არის დისტანციური resolver
CIDR პლუს ორი მისამართი VPC-ის შიგნით არსებული რესურსებისთვის ლოკალური სერვისია. AWS ადასტურებს, რომ ლოკალური ქსელებიდან ან სხვა VPC-ის DNS სერვერებიდან მოთხოვნების პირდაპირ ამ მისამართზე გადაგზავნა არ არის მხარდაჭერილი და შეიძლება არასტაბილური შედეგები მისცეს.
ეს არ ნიშნავს, რომ ექსპერიმენტი არასდროს არ გამოიყურება მუშა. ეს ნიშნავს, რომ ქცევა არ არის კონტრაქტი, რომელიც დამხმარე სკრიპტში ჩასვამთ. მხარდაჭერილი მიმართულებაა შემომავალი Resolver endpoint: წყვილი მისამართი თქვენი VPC-ის შიგნით, ხელმისაწვდომი თქვენი კონტროლირებადი ქსელიდან, რომელიც იღებს AWS-ის გარედან მომავალ მოთხოვნებს.
ააგეთ გზა იმ თანმიმდევრობით, რომლითაც ის სუფთად ფუჭდება
უნდა არსებობდეს სამი გადახტომა და თითოეულს აქვს თავისი ფუჭების გზა.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesგადამცემს სჭირდება მარშრუტი endpoint-ის მისამართებამდე VPN-ის გავლით, და დაბრუნების გზაც უნდა მუშაობდეს. 53 პორტზე ჩვეულებრივი DNS-ისთვის endpoint პასუხობს UDP-ით და TCP-ით, ამიტომ ორივე პროტოკოლი უნდა იყოს დაშვებული და ორივემ უნდა გაუძლოს გზაზე არსებულ ნებისმიერ მდგომარეობრივ შემოწმებას.
შემდეგ ცალკე შეამოწმეთ DNS ხედი. პირადი ჰოსტინგის ზონა ჩანს მხოლოდ იმ VPC-ებზე, რომლებთანაც არის დაკავშირებული, ან განზრახ გაზიარების შეთანხმებით. ხელმისაწვდომი endpoint თავისთავად არ ხდის ყველა პირად ზონას ამონახსნელს მისი ამოხსნის კონტექსტში.
გამავალი endpoint ემსახურება საპირისპირო მიმართულებას და არ უპასუხებს თქვენი ლეპტოპიდან მომავალ მოთხოვნას.
შეამოწმეთ ორივე მხრიდან
ჰკითხეთ კლიენტიდან გადამცემს, შემდეგ გადამცემიდან endpoint-ს. თუ კლიენტი ფუჭდება, სანამ გადამცემი წარმატებულია, უფსკრული ამ ორს შორისაა.
თუ ორივე ფუჭდება, შეხედეთ endpoint-ის უსაფრთხოების პოლიტიკას და წყაროს მისამართს, რომელსაც ის რეალურად ხედავს. NAT-ის უკან მყოფი გადამცემი წარმოადგენს NAT მისამართს ლეპტოპის VPN მისამართის ნაცვლად, და მხოლოდ ეს განსხვავება საკმარისია მოთხოვნის ჩამოსაგდებლად. თუ ორივე წარმატებულია, მაგრამ აპლიკაცია მაინც ფუჭდება, შესაძლოა აპლიკაცია იყენებდეს სხვა resolver-ს, ვიდრე თქვენ გამოსცადეთ.
საჯარო და პირადი სახელთა სივრცეები განზრახ ცალ-ცალკე შეინახეთ. Split DNS არის პოლიტიკა, რომელსაც თქვენ აწყობთ, და არა ერთი ძიების შემთხვევით მონაცემების დაბრუნების გვერდითი ეფექტი.
რასაც არ გავაკეთებდი
არ დავამატებდი NAT წესს, რომელმაც ერთი ძიება ამუშავა, და ამას დიზაინს არ დავარქმევდი.
არ მივმართავდი ყველა დისტანციურ კლიენტს პლუს ორი მისამართზე მხოლოდ იმიტომ, რომ ერთმა ტესტმა ერთხელ ჩანაწერი დააბრუნა. და არ გავაფართოებდი endpoint-ის უსაფრთხოების პოლიტიკას მთელ VPN აუზზე, როცა ერთ გადამცემს სჭირდება წვდომა. თუ ორგანიზაცია უკვე ამუშავებს დამტკიცებულ გადამცემს VPC-ის შიგნით, ჯერ წაიკითხეთ ის დიზაინი, რადგან მეორე endpoint, რომელსაც დაამატებთ, არის ის, რომელსაც არავინ არ აღწერს.