AWS Client VPN ენდპოინტის DNS: რატომ ვერ მუშაობს გადაწყვეტილი IP-ის დამაგრება
შეცვალეთ AWS Client VPN ენდპოინტის სახელი თქვენს მიერ გადაწყვეტილი მისამართით და გვირაბი მოგვიანებით შეწყვეტს მუშაობას. შეინახეთ ექსპორტირებული სახელი და მისი შემთხვევითი პრეფიქსი.
გასულ კვირას dig +short-მა მოგცათ ერთი მისამართი თქვენი AWS Client VPN პროფილის ენდპოინტის სახელისთვის და გვირაბი დაუკავშირდა. ამ კვირას იგივე პროფილი თქვენს ლეპტოპზე 'Connecting' მდგომარეობაში რჩება, სანამ კოლეგის ხელუხლებელი ასლი კვლავ მუშაობს. არაფერი დაბლოკილა და სერთიფიკატი არ გაუვიდა. ვიღაცამ ენდპოინტის ჰოსტის სახელი შეცვალა იმ გადაწყვეტილი მისამართით და სერვისი იქ აღარ პასუხობს. ექსპორტირებული სახელი ის ნაწილია, რომელიც ამ ცვლილების გადატანისთვისაა აგებული.
თქვენს პროფილში არსებული სახელი შეიძლება არ იყოს ის სახელი, რომელზეც მოთხოვნა მიდის
Client VPN-იდან ექსპორტირებულ პროფილებს ჩვეულებრივ აქვს remote-random-hostname. ამ პარამეტრის ჩართვისას კლიენტი ქმნის ერთჯერად ეტიკეტს, წერტილით უერთებს მას ენდპოინტის სახელს და წყვეტს შეერთებულ სახელს. ენდპოინტის ზონაში wildcard ჩანაწერი პასუხობს ნებისმიერ ეტიკეტს, ამიტომ გამოგონილი პრეფიქსიც წყდება და ამიტომ ეს ხერხი უხილავი რჩება, როცა მოთხოვნის ხელით გამეორებას ცდილობთ.
ასე რომ, როცა ენდპოინტის სახელს ტერმინალში აკრავთ და პასუხს იღებთ, თქვენ გადაწყვიტეთ სხვა სახელი, ვიდრე ის, რომელსაც კლიენტი დაკავშირებისას იყენებს. ეს შეუსაბამობა პროფილში გამოსასწორებელი ნაკლი არ არის. ეტიკეტი განზრახ ხელახლა იქმნება: პარამეტრი კეშებს ძველი პასუხის შენახვის საშუალებას არ აძლევს და ის არასოდეს იდენტიფიცირებს თქვენს მანქანას ან სესიას.
შემხვედრია თავსებადობის შემთხვევა, როცა კლიენტი პარამეტრს სრულიად უგულებელყოფს. AWS აფიქსირებს გადაწყვეტას: შეინახეთ ნამდვილი ენდპოინტის სახელი და წინ დაამატეთ შემთხვევითი სტრიქონი და წერტილი, განიხილეთ ის როგორც სახელდების ნიმუში და არა ჩასასმელი მნიშვნელობა. ძველ კლიენტზე ამის გამოყენება გონივრულია; პრეფიქსიანი სტრიქონის ენდპოინტად ხისტი კოდირება არა.
რატომ ვერ დარჩება შენახული პასუხი სწორი
Client VPN-ის ენდპოინტის მისამართებს AWS მართავს და ისინი დროთა განმავლობაში იცვლება, რასაც საუკეთესო პრაქტიკის დოკუმენტი პირდაპირ ამბობს. დაფიქსირებული პასუხი ერთი გადაწყვეტის მომენტური სურათია. მისი ხისტად კოდირება პროფილს აქცევს პროფილად, რომელიც ექსპლუატაციიდან გამოყვანილ ჰოსტზეა მიმართული, როგორც კი სერვისი გადაადგილდება, და წარუმატებლობა იშვიათად ჰგავს DNS-ს: იღებთ კავშირის დროის ამოწურვას ან გაჩერებულ handshake-ს, ამიტომ ხალხი მარშრუტიზაციას და სერთიფიკატებს დასდევს.
იგივე პასუხი /etc/hosts-ში იმავე ვადას მემკვიდრეობით იღებს დამატებითი პრობლემით. hosts ჩანაწერი გადაურჩება გადატვირთვებს, ხელახალ ექსპორტს და 'კლიენტის ხელახლა დაყენების' შესწორებებს, ამიტომ წარუმატებლობა ბრუნდება ყოველ ჯერზე, როცა მისამართი გადაადგილდება. მინახავს ერთი კვირების განმავლობაში უვნებლად მწოლი, შემდეგ კი გამორთო ყველა მანქანა, რომელიც მას ატარებდა, მაშინ როცა ახალი ინსტალაციები ნორმალურად უკავშირდებოდნენ. ეს გაყოფა, ერთი ჯგუფი მარცხდება და მეორე იმავე ანგარიშზე რიგზეა, ყველაზე იაფი მინიშნებაა, რასაც მიიღებთ.
სწორად შემოსაზღვრეთ რანდომიზაციაც. ის ხდება თითოეულ დაკავშირების მცდელობაზე. დამყარებული გვირაბი ხელახლა არ წყვეტს თავის ენდპოინტს, სესიის შუაში სერვერს არ ცვლის და ცალკეული აპლიკაციის მოთხოვნები თითოეული ახალ VPN ჰოსტს არ ირჩევს. მხოლოდ შემდეგი მცდელობა წყვეტს ხელახლა, ამიტომ მთელი შუადღე მომუშავე სესია ხვალინდელ დილაზე არაფერს ამბობს.
რას ამოწმებს სერვისი, როცა გვირაბი ადის
Client VPN მოითხოვს, რომ მისამართი, რომელზეც დაკავშირებული ხართ, ემთხვეოდეს ენდპოინტის DNS სახელისთვის გადაწყვეტილ მისამართს. ეს ერთი მოთხოვნა ხსნის რამდენიმე დაუკავშირებელ შეცდომას: სხვაგან მიმართული მორგებული DNS ჩანაწერი, მორგებული frontend, რომელიც ენდპოინტის ნამდვილ მისამართზე გადაამისამართებს, და ნედლ მისამართზე გადაწერილი პროფილი. AWS მორგებული ჩანაწერისა და გადაცემის კომბინაციას აფიქსირებს როგორც შეცდომას AWS-ის ახალ კლიენტებთან. შემოწმება ვიწროა; ეს არ არის განაჩენი, რომ ყველა სხვა სახელი აკრძალულია.
ეს ასევე არ არის ზოგადი წესი VPN პროტოკოლებზე. რიცხვითი remote სრულიად ნამდვილია ჩვეულებრივ OpenVPN განლაგებაში და ბევრი ასე მუშაობს. შეზღუდვა მართული წყობიდან მოდის, არა მის ქვეშ არსებული პროტოკოლიდან.
რაც სერთიფიკატის შემოწმების შესუსტებას არასწორ რეფლექსად აქცევს. თუ მისამართის შეცვლის შემდეგ პროფილი ვერ მუშაობს, სერვერის შემოწმების გამორთვა შეცდომას გადაადგილებს იმის ნაცვლად, რომ გადაწყვეტა ან მისამართის დამთხვევის მოთხოვნა გამოასწოროს, და ტოვებს კლიენტს, რომელიც ყველაფერს ენდობა. შეინახეთ ექსპორტირებული CA, სერვერის შემოწმება და ურთიერთ ავთენტიფიკაციის პარამეტრები ზუსტად ისე, როგორც მოვიდნენ.
ნებადართული სიები, გასასვლელი და კერძო DNS სამი ცალკე პრობლემაა
Firewall წესი, რომელმაც უნდა დაუშვას დანიშნულება ლეპტოპის დაკავშირებამდე, გარე მსმენელს ეხება. მიეცით ქსელის მფლობელს ენდპოინტის სახელი, ტრანსპორტი და კონფიგურირებული პორტი, შემდეგ ჰკითხეთ, შეუძლია თუ არა მათ კონტროლს სერვისის DNS ქცევის მიყოლა. ერთ დაფიქსირებულ მისამართს რომ უჭირავს წესი, დაუწერელი ვადის მომენტური სურათია. თუ კონტროლი მხოლოდ უცვლელ დანიშნულებებს იღებს, ეს უფსკრული გაშვებამდე მოაგვარეთ და არა ჩუმად ჩაახისტოთ პასუხი.
პარტნიორს, რომელსაც გვირაბის აწევის შემდეგ გაკეთებული მოთხოვნებისთვის ფიქსირებული წყაროს მისამართი სჭირდება, სხვა მოთხოვნა აქვს: გასასვლელი. რასაც ვებსაიტი ხედავს, დამოკიდებულია აპლიკაციის მარშრუტზე და გაყოფილი გვირაბის პოლიტიკაზე და არა იმ მისამართზე, რომელზეც კლიენტი დაუკავშირდა. გაყოფილი გვირაბის ტრაფიკმა შეიძლება AWS-ს საერთოდ არ შეეხოს.
გვირაბის შიგნით კერძო DNS მესამე ფენაა. კლიენტებზე გაცემული გადამწყვეტი დაკავშირების შემდეგ შიდა სახელებს პასუხობს; მას არ შეუძლია საჯარო ენდპოინტის გადაწყვეტა გვირაბის არსებობამდე. ენდპოინტის გადაწყვეტის და შიდა აპლიკაციის გადაწყვეტის წარუმატებლობა სხვადასხვა ეტაპზე ხდება და მათი შერევა არასწორ ჟურნალში გიგზავნით.
მისამართების ოჯახი იმავე სიაშია. IPv4 პასუხი არაფერს ამბობს IPv6 ან ორმაგი დასტის ენდპოინტის დაშვებულ გზაზე, ამიტომ ერთ ოჯახში გადაღებული სურათი მეორისთვის მტკიცებულება არ არის.
შეამოწმეთ კავშირი რაიმეს დამაგრების გარეშე
დაიწყეთ პროფილით, როგორც ექსპორტირდა, და წაიკითხეთ, რას ითხოვს ის სინამდვილეში:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'შემდეგ შეადარეთ სამი რამ: პროფილში არსებული ენდპოინტის სახელი, მისამართი, რომელსაც კლიენტი ახალი მცდელობისთვის იუწყება, და რაში იშლება სახელი ახლა. გადაწყვეტადი სახელი მხოლოდ იმას ამტკიცებს, რომ ჩანაწერი პასუხობს; ტრანსპორტი და ავთენტიფიკაცია ცალკეა და ენდპოინტს ping-ზე პასუხი არ ევალება. კლიენტის საკუთარი ჟურნალი შუა ერთეულის ერთადერთი წყაროა, ამიტომ დააფიქსირეთ ის მცდელობის დროს და არა შემდეგ.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
დღეს მპასუხობი მისამართი დღევანდელი მტკიცებულებაა; სახელი ის არის, რასაც სერვისი ძალაში ინახავს. ჩაწერეთ დაკვირვება, გაუგზავნეთ ენდპოინტის მფლობელს და დატოვეთ პროფილი სახელზე მიმართული.
ორი ჩვევა უნდა მიატოვოთ: სერთიფიკატის შემოწმების გამორთვა გაჩერებული handshake-ის გასავლელად და ეტიკეტების დაწყობა ენდპოინტის სახელის წინ იმ იმედით, რომ ერთი მაინც მიეწებება. ეტიკეტი wildcard ჩანაწერით იშლება ან პრობლემა სხვაგანაა. თუ სწორად კონფიგურირებული პროფილი მაინც ვერ მუშაობს, გაგზავნეთ ზუსტი მოთხოვნა და დაკავშირების მოვლენა და არა უფრო გრძელი ჰოსტის სახელი.
სანამ დახურავთ: პროფილი კვლავ ატარებს ექსპორტირებულ ენდპოინტის სახელს, არც ერთი hosts ფაილი არ ამაგრებს მისამართს, კლიენტის ჟურნალში remote ემთხვევა მიმდინარე გადაწყვეტას და firewall წესი ასახელებს ენდპოინტს და არა მისამართს. ეს არის ის მდგომარეობაც, რომელიც შემდეგ ადამიანს უნდა გადასცეთ.