DNS AWS Client VPN-ში: გამოიყენეთ VPC-ის resolver, და არა subnet

Endpoint მდებარეობს 10.0.8.0/24-ში, ამიტომ resolver უნდა იყოს 10.0.8.2. ეს არის ყველაზე ხშირად მოსმენილი მსჯელობა და ის ორჯერ მცდარია. Route 53 Resolver პასუხობს VPC-ის ძირითად IPv4 დიაპაზონზე პლუს ორი, რაც 10.0.0.0/16 VPC-ისთვის არის 10.0.0.2, მიუხედავად იმისა, თუ რომელ subnet-ს იყენებს endpoint. მეორე შეცდომა უფრო ჩუმია: სწორი მისამართის endpoint-ში ჩასმა არ ნიშნავს, რომ client-ის ოპერაციული სისტემა მას როდესმე რამეს ჰკითხავს. ორივე შეცდომა ერთსა და იმავე სიმპტომს იძლევა: სახელების გარჩევა ზოგ client-ზე მუშაობს, ზოგზე კი ვარდება.

მითი იწყება subnet-ის ასოციაციით

ასოციაცია ეხება იმას, თუ სად ცხოვრობენ client-ის კავშირების ელასტიური ქსელური ინტერფეისები და არა იმას, რომელი resolver მისამართი არსებობს. endpoint-ის subnet-ები client-ს აძლევს მისამართს VPC-ის შიგნით და თითოეულ მათგანს არ მიჰქონდა საკუთარი resolver.

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

გამოთვალეთ მისამართი VPC-ის ძირითადი დიაპაზონიდან

აიღეთ VPC-ის ძირითადი IPv4 CIDR და ქსელურ მისამართს დაუმატეთ ორი. 10.0.0.0/16 იძლევა 10.0.0.2-ს, 172.31.0.0/16 იძლევა 172.31.0.2-ს, ხოლო მეორადი დიაპაზონის მქონე VPC resolver-ს ძირითადზე ტოვებს. ამ VPC-ის შიგნით 10.0.8.0/24 subnet მას არ აადგილებს. ჩაწერეთ მისამართი VPC ID-ის გვერდით, სანამ endpoint-ს შეეხებით, რადგან რიცხვი VPC-ის თვისებაა და არა კავშირის.

VPC პასუხობს ასევე link-local მისამართზე 169.254.169.253. ეს მისამართი ხელმისაწვდომია VPC-ის შიგნიდან, მაგრამ არ არის ზოგადი მარშრუტიზებული დანიშნულება გვირაბის მეორე მხარეს მყოფი ლეპტოპისთვის.

ასე რომ, არსებობს ორი ნამდვილი resolver მისამართი და არც ერთი მათგანი არ არის subnet პლუს ორი.

რას აკეთებს endpoint-ის პარამეტრი და რას არა

Client VPN endpoint-ს აქვს DNS სერვერის ველები და სადაც კონსოლი გთავაზობთ VPC resolver-ის ვარიანტს, ის ივსება იმავე იდეით. მათი დაყენება ცვლის იმას, თუ რას გადასცემს სერვისი client-ებს კავშირის დამყარებისას. ეს არ ცვლის იმას, თუ რას აკეთებს არაკონტროლირებადი OpenVPN client ამ მნიშვნელობით, რადგან client-მა ის მაინც უნდა გამოიყენოს ოპერაციულ სისტემაზე. სწორედ ამ ნაპრალიდან მოდის «მუშაობს ჩემს Mac-ზე, მაგრამ არა Linux მანქანაზე».

Linux-ში resolver-ის ინტეგრაცია კავშირის მენეჯერს ეკუთვნის და არა მომხმარებელს. /etc/resolv.conf-ის ხელით რედაქტირება ამტკიცებს, რომ მისამართი მუშაობს ერთი სესიისთვის და შემდეგ ქრება ხელახლა დაკავშირებისას — ამიტომ ბევრი გამოსწორებული შემთხვევა მეორე დილას ბრუნდება.

შეამოწმეთ აქტიური resolver client-ზე დაკავშირების შემდეგ და არა endpoint-ის კონფიგურაციის გვერდი.

split tunneling-მა შეიძლება სწორი resolver ჩაშალოს

split tunneling-ის დროს გამოიყენება მხოლოდ გვირაბში გაშვებული მარშრუტები. თუ resolver-ის მისამართი არ არის დაფარული მარშრუტით, მოთხოვნა გადის ლოკალურ ინტერფეისში და პასუხობს თქვენი სახლის როუტერი. endpoint-ში მისამართი ისევ სწორია და ძებნა ისევ ვარდება. დაამატეთ მარშრუტი resolver-ისთვის და შემდეგ კვლავ შეამოწმეთ.

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

ნუ გახსნით security group-ებს Amazon DNS მისამართისთვის

როცა ძებნა დროში იწურება, ინსტინქტი გვკარნახობს დავამატოთ წესი, რომელიც UDP 53-ს უშვებს resolver-ის მისამართზე. AWS ადასტურებს დოკუმენტაციაში, რომ security group-ები და ქსელური ACL-ები Amazon DNS ტრაფიკს არ ფილტრავს ისე, როგორც ფილტრავს ტრაფიკს საკუთარი DNS ინსტანსისკენ. ამ წესების გახსნა VPC resolver-ისთვის არაფერს ცვლის და საზღვარს უაზროდ აფართოებს. რეზოლვერი, რომელსაც თავად ამუშავებთ, სხვა შემთხვევაა და ნამდვილად საჭიროებს საკუთარ წესებს.

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

შეამოწმეთ გზა, შემდეგ გაზომეთ სხვა რამ

გადაწყვიტეთ საჯარო სახელი, გადაწყვიტეთ VPC-თან დაკავშირებულ კერძო ჰოსტინგის ზონაში რეგისტრირებული კერძო სახელი და მათ შორის წაიკითხეთ client-ის აქტიური resolver. ეს თანმიმდევრობა გამოყოფს «resolver-ის მისამართი არასწორია»-ს «ზონა არ არის დაკავშირებული»-სა და «client-მა პარამეტრი უგულებელყო»-სგან. თითოეულს განსხვავებული გამოსწორება აქვს და არც ერთი არ არის გამტარუნარიანობის პრობლემა.

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