Дозволен список на VPN крајни точки: DNS освежувањето што го заборавивте

Внесувањето на vpn.example.com во исклучок на огнениот ѕид изгледа како претплата на DNS. Обично се случува превод при вчитување, по што правилото држи адреси и ништо не ги освежува. Сега две компоненти ја делат работата: решавачот што одговара и огнениот ѕид што складира. Повеќето прекини на крајни точки започнуваат таму каде што тоа предавање никогаш не било проектирано.

Име на домаќин во правило не е жива претплата

Некои алатки решаваат име кога се вчитува конфигурацијата; други држат име на домаќин и го решаваат повторно по свој распоред; трети прифаќаат само адреси. Видливата конфигурација ретко кажува кој случај е. Примерите во документацијата обично претпоставуваат случај на вчитување, затоа разликата ги изненадува луѓето при миграција. Прочитајте го однесувањето на имплементацијата пред да претпоставите дека промената на адресата ќе биде забележана, бидејќи застарен дозволен список изгледа точно како оној што работи додека крајната точка не се премести.

Правило што го именува правилниот домаќин сепак може да дозволи погрешна адреса. Таа празнина е митот, не правописна грешка.

TTL на кешот не е тајмерот на вашиот огнен ѕид

DNS записите носат време на живеење, а решавачите ги кешираат одговорите за тој период. DNS спецификација го дефинира тоа кеширање однесување, но управува со DNS податоци, не со одделното складиште на адреси на огнениот ѕид. Краток TTL не создава задача за освежување таму каде што нема. Кеширањето се случува и на повеќе од еден слој, па одговорот што го гледа терминалот може да не е тој што го видел огнениот ѕид.

Поставете три прашања на вистинскиот производ: кога решава, каде го складира резултатот и што иницира ажурирање. Ако одговорот е само при подигање, долготрајна сесија може да ја надживее адресата на која била примена.

dig +short vpn.example.com
resolvectl query vpn.example.com

Дизајнирајте освежување и неуспех како една политика

Одржуван исклучок бара експлицитни одговори: што иницира освежување пред клиентот да избере нова адреса, како се менува дозволеното множество без отворање широк привремен прозорец и кога се отстрануваат застарени записи. Запишете ги тие одговори до правилото.

Изберете го однесувањето при неуспех намерно. Задржувањето на старата адреса може да зачува сесија и да остави застарена дозвола; чистењето на множеството може да го спречи опоравувањето. Ниту едно не треба да биде случаен резултат на неуспешно пребарување. Запишете го избраното однесување во runbook за следниот оператор да не импровизира под притисок.

Држете го тесен и bootstrap DNS. Безусловен исклучок за јавен решавач е директен DNS пат за сето она што совпаѓа, не само за името на крајната точка.

Докажете ја промената на крајната точка, не првото поврзување

Користете го поддржаниот менаџер на клиентот ако веќе ги координира решавањето и блокирањето. На PF домаќин управуван од локацијата, задржете ја сопственоста и планот за опоравување на локацијата наместо да копирате синтакса на табела со имиња на домаќини од друга платформа со различно однесување на животниот циклус.

Со одобрен, безопасен тест споредете ја адресата што ја избира клиентот со активното дозволено множество пред и по контролирана промена. Опфатете неуспешно пребарување, бришење запис што повеќе не е валиден и, каде што е поддржано, друга фамилија адреси. Предвидениот тунел треба да се опорави додека неповрзаниот директен сообраќај останува под политиката. Успешното прво поврзување докажува само дека почетниот превод случајно бил точен.