Име VPN крајње тачке наспрам имена приватне услуге: два власника
Јавна 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 је ажуриран“ оставља следећег инжењера да нагађа који је од два животна циклуса заиста прошао.