Име на 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 беше обновен“, оставя следващия инженер да гадае кой от двата жизнени цикъла действително е протекъл.