Імя канцавога пункта VPN і імя прыватнай службы: два ўласнікі

Два імёны могуць апісваць адну і тую ж галіну і адказваць на цалкам розныя пытанні. 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 абноўлены», пакідае наступнага інжынера здагадвацца, які з двух жыццёвых цыклаў сапраўды прайшоў.