Хоёр нэр нэг салбарыг тодорхойлж, огт өөр асуултад хариулж болно. vpn.branch.example алслагдсан түншдээ VPN төгсгөлийн цэгийг хаанаас олохыг хэлдэг бөгөөд ямар ч туннель үүсэхээс өмнө шийдэгдсэн байх ёстой. inventory.branch.example эрх бүхий хэрэглэгчид хувийн аппликейшн хаана байрлаж байгааг хэлдэг бөгөөд туннель боссны дараа л ач холбогдолтой. Нэгийг нь арчлах нь нөгөөд нь юу ч хийхгүй.

Аль нэгийг нь ч засахаас өмнө хоёр бичлэгийг нэрлэ

Хоёуланг нь эзэмшигчдийнх нь хамт бич. Төгсгөлийн цэгийн хувьд нийтийн хаягийг хэн шинэчилдэг, VPN клиент хариултаа хэрхэн шинэчилдэг талаар тэмдэглэ. Үйлчилгээний хувьд хувийн хаягийн эзэн хэн бэ, аль бүс бичлэгийг хадгалдаг, ямар шийдвэрлэгчид түүнд хариулах ёстойг тэмдэглэ.

Энэ богино жагсаалт энэ салбарын хамгийн түгээмэл буруу оношийг сэргийлдэг: бүхэлдээ дотроо амьдардаг бичлэгийг засахын тулд ажиллаж байгаа салбарын туннелийг дахин эхлүүлэх. Туннель бол үйлчилгээний нэрний тээвэр, тэр нь түүний эрх мэдэл биш.

Өөрчлөлт санал болгоход хоёр бичлэгийн алийг нь хөндөж байгааг асуу. Хэн ч хариулж чадахгүй бол өөрчлөлт төлөвлөхөд бэлэн биш.

Ямар ч туннель үүсэхээс өмнө төгсгөлийн цэг шийдэгдсэн байх ёстой

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

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

Динамик DNS-д бас бичлэгийн шинэчлэл давж чадахгүй хязгаарууд бий. Бичлэгийг шинэчлэх нь галын хананы порт нээхгүй, NAT зураглал үүсгэхгүй, түншийн хэн болохыг батлахгүй. Хаалттай порттой нийтлэгдсэн хаяг зөв шийдвэрлэдэг боловч юу ч холбогдож чадахгүй клиентийг өгдөг.

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

Үйлчилгээний нэр аппликейшн хаана байрлаж байгааг тодорхойлдог

Одоо туннель эрүүл хэвээр байна, гэхдээ бараа бүртгэлийн сервер 172.26.14.20-оос 172.26.14.35 руу шилжлээ гэж бодъё. Нийтийн төгсгөлийн цэгийн бичлэг өөрчлөгдөхгүй, харин хувийн үйлчилгээний бичлэг өөрчлөгдөх ёстой. Тэр үйлчилгээнд зориулсан хаяг эсвэл статик хуваарилалт ашиглах нь үүнийг ховор болгодог; эрх бүхий шинэчлэлтийн зам үүнийг зориуд хийсэн тохиолдлуудыг зохицуулна.

Энд хоёр шинэчлэлтийн механизм холилдож байна. RFC 2136 бүсэд DNS бичлэг нэмэх, устгах протоколыг тодорхойлдог бол арилжааны динамик DNS нийлүүлэгч өөр зорилгоор огт өөр HTTP API санал болгож болно. Нэгийг ашиглах нь нөгөө нь таны орчинд байна гэсэн үг биш. Үүний эсрэг шинэчлэгч бичихээс өмнө таны бүс яг ямар механизмыг хүлээж авдаг болохыг шалга.

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

Хоёр замыг тусад нь шалга

Төгсгөлийн цэгийг туннелийн гаднаас, үйлчилгээг дотроос нь шалгаад үр дүнг хоёр бие даасан баримт болгон хадгал:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

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

Холбоотой нийтлэлүүд