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 хост дээр өөр амьдралын мөчлөгийн зан төлөвтэй өөр платформоос хост нэрийн хүснэгтийн синтаксийг хуулахын оронд сайтын эзэмшил болон сэргээх төлөвлөгөөг хадгал.

Зөвшөөрөгдсөн, хор хөнөөлгүй туршилтаар хяналттай өөрчлөлтийн өмнө болон дараа клиентийн сонгосон хаягийг идэвхтэй зөвшөөрөгдсөн багцтай харьцуул. Амжилтгүй хайлт, хүчингүй болсон бичлэгийг устгах, дэмжигдсэн бол өөр хаягийн гэр бүлийг хамар. Зорилтот туннель сэргэх ёстой, харин холбоогүй шууд урсгал бодлогын дор үлдэх ёстой. Амжилттай эхний холболт нь анхны орчуулга санамсаргүйгээр зөв байсныг л батална.