VPN-зона в OpenWrt, перенаправление и маскировка: что нужно?

Три изменения смешиваются каждый раз, когда VPN встречается с OpenWrt: открытие порта, разрешение перенаправления и включение маскировки. Они отвечают на разные вопросы, и обычно только одно из них является реальным требованием. Чтение каждого элемента управления по роли трафика, которым он управляет, превращает догадку в решение и подсказывает, какого симптома ждать, если изменение неверно. Начните с названия роли, которая отказала, а не с флажка, который вы помните.

Назовите роль трафика, прежде чем трогать элемент управления

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

Полезная карта — по роли трафика, потому что именно это можно наблюдать, когда что-то не работает. У каждой роли ниже есть один элемент управления, который её определяет, и один симптом, который на неё указывает:

Слушателю на роутере нужно одно узкое правило входа

Сервер OpenVPN на роутере принимает трафик, адресованный роутеру, поэтому его внешнее соединение зависит от политики входа зоны, которая его несёт. Разрешите настроенный транспорт и порт, а всё остальное в этой зоне оставьте отклонённым. Одно правило для порта — гораздо меньшее изменение, чем разрешение для всей зоны, и именно его вы сможете объяснить и через год.

Две вещи делают это правило безопасным для сохранения: оно называет порт, который служба действительно использует, и стоит рядом с определением зоны, чтобы следующий человек видел, зачем оно существует. Строки ниже — это форма, а порт заменяет то, что настроено на сервере. Меняйте этот порт в обоих местах при переносе службы, потому что правило, оставшееся на старом, незаметно до аудита.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

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

fw4 check
service firewall reload

Запрос клиента проходит через перенаправление, а не через вход

После аутентификации запрос клиента туннеля к службе LAN создаёт перенаправленный поток, поэтому элементом управления, который это решает, является отношение перенаправления между зоной туннеля и зоной LAN. Назначьте интерфейс туннеля нужной зоне, затем объявите направление, источники и службу. Именно назначение зоны придаёт смысл правилу перенаправления, и оба имеют смысл только вместе. Отношение перенаправления, где зона туннеля названа источником, а зона LAN — назначением, читается как одно осознанное решение, тогда как два разрешения для всей зоны читаются как случайность.

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

Маскировка — это решение о маршрутизации, а не разрешение

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

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

Докажите решение разрешённым и отклонённым запросом

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

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

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

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