Име на 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 беше ажуриран» го остава следниот инженер да погодува кој од двата животни циклуси навистина се извршил.