VPN საბოლოო წერტილების ნებართვის სია: ის DNS განახლება, რომელიც დაგავიწყდათ

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

წესში ჰოსტის სახელი ცოცხალი გამოწერა არ არის

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

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

ქეშის TTL თქვენი firewall-ის ტაიმერი არ არის

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

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

dig +short vpn.example.com
resolvectl query vpn.example.com

დააპროექტეთ განახლება და ჩავარდნა ერთ პოლიტიკად

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

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

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

დაამტკიცეთ საბოლოო წერტილის ცვლილება, არა პირველი კავშირი

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

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