გეოგრაფიული DNS და ანიკასტი: მიღებული VPN შესასვლელის შემოწმება

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

შეამოწმეთ, ვის ადგილს აცნობს გადამწყვეტი სინამდვილეში

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

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

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

შეამოწმეთ, რა გადაწყვიტა ანიკასტის მარშრუტიზაციამ

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

დაადასტურეთ მომსახურების ადგილი სერვისის მხრიდან ან პასუხიდან, რომელიც მას ასახელებს, და არა მხოლოდ DNS პასუხიდან. traceroute -n 198.51.100.20 აჩვენებს გავლილ ბილიკს და მაინც არ ასახელებს ჰოსტს მის ბოლოს, ამიტომ წაიკითხეთ ის როგორც ბილიკი და არა როგორც პასუხი.

შეამოწმეთ, რომ სესია გადაურჩება კვანძის შეცვლას

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

დააკვირდით გადაადგილებას და ნუ ივარაუდებთ. sudo tcpdump -ni any -c 20 esp აჩვენებს გარე პაკეტებს ბილიკის ცვლისას და პარტნიორის მისამართის უეცარი ცვლილება სწორედ ეს გადაადგილებაა. ცხადად განსაზღვრეთ განზრახული ქცევა თქვენი იმპლემენტაციისთვის, შემდეგ შეამოწმეთ იგი ბილიკის ცვლილების იძულებით. თუ დიზაინი სესიის რეპლიკაციას გულისხმობს, დაასახელეთ მექანიზმი და დაასახელეთ მარცხი, რომელსაც ის არ ფარავს.

შეამოწმეთ, რომ იდენტურობა ჯერ კიდევ ემთხვევა

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

შეამოწმეთ ეს კლიენტიდან, რომელმაც არაჩვეულებრივ კვანძს მიაღწია, რადგან სწორედ ესაა შემთხვევა, როცა კვანძისეული სერტიფიკატი ხილული ხდება. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ბეჭდავს ჯაჭვსა და სახელებს და სწორედ ამას ადარებს კლიენტი. შემდეგ გადაწყვიტეთ, უნდა შევიწროვდეს პროფილი თუ შეიცვალოს სერტიფიკატის მოდელი.

შეამოწმეთ ჩანაწერი და არა მხოლოდ პირველი პასუხი

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

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

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