Доступ из VPN в VLAN: сначала матрица, потом правила
Роли с одной стороны, сервисы с другой. Пять проверок превращают расплывчатый проект доступа из VPN в VLAN в таблицу, которую владелец межсетевого экрана может внедрить.
Начните с матрицы, а не с синтаксиса межсетевого экрана. Таблицу, где роли с одной стороны, а сервисы с другой, может просмотреть владелец приложения, обсудить владелец безопасности и внедрить тот, кто держит шлюз. Этот разбор дешевле отладки правил, о которых никто не договорился.
Час написания экономит потом неделю археологии правил. Проект говорит о том, кто до какого сервиса доходит, и именно эта часть переживает перенумерацию.
Шаг 1: назовите роли до сетей
Начните с людей, а не с коммутатора. Запишите каждую группу, которая подключается удалённо, и одно предложение о том, чем эта группа занимается, например сотрудники склада, читающие уровни запасов, или подрядчик, поддерживающий одну интеграцию. Если две группы получили бы одинаковый доступ, для этой цели они одна роль.
Остановитесь здесь, если роль существует только из-за организационной схемы. Роль без собственной потребности в сервисе превращается в строку одинаковых ячеек, а одинаковые строки подталкивают кого-то позже выдать всю подсеть ради удобства. Делите по тому, что делают люди, а не по тому, кто подписывает их расходы. Шесть ролей обычно слишком много для небольшого офиса, а три часто верно.
Шаг 2: превратите каждую ячейку в утверждение о сервисе
Ячейка с надписью «Приложения» не проверяема. Ячейка с надписью «HTTPS к хосту ERP на 443, из пула сотрудников» проверяема. Замените каждое имя сети на назначение, протокол и порт, затем добавьте зависимость, без которой сервис не работает, например внутренний резолвер или поставщика удостоверений.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Столбец направления ловит самые дорогие ошибки. Разрешение сотрудникам открывать приложение не означает разрешения серверам приложений открывать соединения обратно к ноутбукам сотрудников, и правило с состоянием, разрешающее первое направление, часто читается как разрешение второго.
Шаг 3: решите, где идентичность становится политикой
Кто-то должен превратить аутентифицированную сессию в роль, которую шлюз может обеспечить. Поддерживаемые варианты включают групповую политику от бэкенда аутентификации, доверенные атрибуты сессии или отдельные пулы адресов для каждой роли. Все три работают; метка, которую присылает клиент, нет. Выберите механизм, который документирует ваш шлюз, а не тот, который описывает сообщение на форуме.
Назначение адреса, который лишь выглядит принадлежащим VLAN, — тот же неответ в другом костюме. Руководство Netgate по правилам межсетевого экрана OpenVPN делает разделение ясным: разрешить туннелю подняться — иное решение, чем разрешить трафику пройти через него.
Запишите, какой механизм вы выбрали и где он настроен. Когда роль меняется, эта заметка — разница между одной правкой и поиском по трём интерфейсам. Она также говорит аудитору, куда смотреть в первую очередь.
Шаг 4: следите за адресом источника, который видит назначение
Политика перенаправления должна соответствовать реальному источнику на границе. Если шлюз транслирует VPN-клиентов в свой собственный адрес, каждый нижестоящий межсетевой экран видит один источник и теряет возможность решать по роли. Если он сохраняет адрес клиента, обратный путь должен существовать для этого пула.
Проверьте оба направления до того, как писать окончательные правила, затем запишите наблюдаемый источник рядом с каждой ячейкой. Запустите ту же проверку из двух разных ролей и сравните результат. Если обе показывают адрес шлюза, различие ролей уже потеряно. Матрица, которая предполагает сохранённые адреса, пока шлюз выполняет трансляцию источника, падает на первом нижестоящем ACL.
Шаг 5: проверьте каждую ячейку перед выпуском
Превратите каждую разрешённую ячейку в одну представительную операцию, а каждую запрещённую ячейку в отрицательный случай. Запустите оба с клиента в реальной роли, а не из консоли шлюза, потому что консоль обходит путь, который вы проверяете.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Отрицательный случай, который подключается, — это находка, а не случайность, и его место в матрице как неудавшейся ячейки, пока правило не исправлено. Держите тестовые команды рядом с таблицей, чтобы следующий рецензент запустил их снова, а не выстраивал рассуждение заново.
Готовая таблица живёт дольше шлюза, для которого написана. Правила меняются вместе с прошивкой и поставщиком, а строка о том, что подрядчик доходит до одного проекта, остаётся верной, пока эта работа не изменится.