Исключение UFW для VPN при смене адреса конечной точки

Клиент пытается переподключиться, и из машины ничего не уходит, хотя тот же профиль работал на прошлой неделе. Имя хоста конечной точки теперь разрешается в другой адрес, а исходящее исключение всё ещё называет старый. Этого единственного устаревшего разрешения достаточно, чтобы превратить работающий kill switch в полный простой, и оно невидимо в любом индикаторе состояния, который показывает рабочий стол. Исправление — небольшой рабочий процесс, а не правка одной строки.

Туннель переподключается, и ничего не уходит

Исходящее правило, называющее адрес назначения, — это снимок, а ответы DNS таковыми не являются. Когда провайдер меняет адрес, пакет, который клиент отправляет к новому пиру, ничему не соответствует и отбрасывается запретом по умолчанию. Затем клиент сообщает об истечении времени ожидания, что выглядит как проблема сервера, а не межсетевого экрана.

Закрепление адреса, который вернёт публичный запрос, заставит сегодня работать, а завтра сломается. Это разовая правка, а не политика обслуживания.

Опишите исключение, которое вы действительно имеете в виду

Начните с того, что запишите четыре значения, нужные правилу: одобренное имя конечной точки или набор адресов, транспорт, порт назначения и интерфейс, через который пакет уходит. Все четыре входят в разрешение, и любое из них может быть неверным, пока правило всё ещё выглядит правдоподобно. Правило, верное в трёх из них, отказывает точно так же, как правило, неверное во всех четырёх. Запишите их до ввода команды, потому что правило хорошо ровно настолько, насколько хорошо описание за ним.

Команда ниже показывает форму для одной конечной точки IPv4 UDP на проводном аплинке. Замените оба значения теми, которые вы проверили по развёртыванию.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

Это разрешение не даёт права на произвольные назначения на том же порту, не создаёт слушателя и не покрывает TCP. Страница руководства UFW описывает, как адрес, интерфейс и протокол сужают правило, и именно это сужение и есть суть.

Обновите это как один рабочий процесс

Относитесь к исключению как к ресурсу с владельцем и переходом, а не как к команде, которую кто-то вспомнит выполнить. Сначала получите кандидата из собственного резолвера и инвентаря конечных точек развёртывания и осознанно определите, как это имя разрешается до появления туннеля. Затем проверьте кандидата на соответствие предполагаемому протоколу, порту и семейству адресов, прежде чем касаться набора правил.

Сначала установите новое узкое разрешение и подтвердите, что оно загрузилось, потому что просьба к клиенту использовать адрес, который межсетевой экран всё ещё блокирует, даёт сбой, выглядящий как отказ сервера. Не трогайте несвязанные правила во время изменения.

Наблюдайте переход клиента через поддерживаемый путь переподключения и подтвердите, какой удалённый адрес он выбрал. Обновление одного лишь DNS не перемещает существующий сокет, а параметр сохранения конечной точки может удерживать клиента на старом пире ещё долго после смены записи.

Наконец, намеренно выведите устаревшее разрешение из эксплуатации, допуская одобренное окно перекрытия, пока старая сессия ещё активна. Слишком раннее удаление старой записи даёт короткий простой; оставление её навсегда оставляет разрешение, которое никто не может объяснить.

Намеренно выведите старое разрешение из эксплуатации

Удаление — это место, где сосредоточена большая часть риска, потому что старое правило сейчас единственное, что работает. Если установка кандидата не удалась, не продолжайте и не удаляйте запись, которая всё ещё несёт трафик. Если сам вывод из эксплуатации не удался, запишите устаревшее разрешение как устаревшее, вместо того чтобы объявить политику актуальной.

Повторите весь обзор, когда аплинк меняется с Ethernet на Wi-Fi, когда меняется транспорт или когда служба вращается по нескольким адресам. Правило, привязанное к интерфейсу, должно перестать совпадать после смены сети, и это поведение правильно, хотя и выглядит как регрессия.

Затем докажите контракт безвредным трафиком. Одобренная конечная точка должна быть доступна при настройке, защищённое приложение должно работать после подключения, а несвязанный прямой трафик должен оставаться заблокированным во время простоя. Включите оба семейства адресов и одну намеренно неудачную попытку обновления, потому что соединение, которое удаётся после одной правки закреплённого адреса, не доказывает ни одного из этих случаев.