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

С одобрен, безвреден тест сравнете адреса, който клиентът избира, с активния разрешен набор преди и след контролирана промяна. Покрийте неуспешно търсене, изтриване на запис, който вече не е валиден, и, където се поддържа, различно семейство адреси. Предвиденият тунел трябва да се възстанови, докато несвързаният директен трафик остава в рамките на политиката. Успешната първа връзка доказва само, че първоначалното преобразуване случайно е било правилно.