Пользователь MikroTik VPN получает слишком много: ограничьте одним хостом и одним портом

Туннель поднимается, вход выполняется успешно, и каждый хост в сети отвечает. Это не сломанный VPN; это VPN без модели разрешений. RouterOS аутентифицирует учётную запись, а затем маршрутизирует её пакеты как любые другие, поэтому предел должен обеспечить межсетевой экран. Добавить этот предел, не сломав вход, — вся работа.

Аутентификация заканчивается там, где начинается разрешение

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

Проверьте, к какому пути относится запрос, прежде чем что-либо писать. Трафик к хостам за маршрутизатором проходит через forward, а трафик к самому маршрутизатору, включая winbox и SSH, проходит через input. Область, охватывающая только forward, оставляет устройство открытым для того же клиента.

Обе цепочки требуют решения, даже если решение — оставить input закрытым. Этот выбор относится к заявке на доступ, а не к более поздней мысли.

Привяжите сеанс к именованному списку

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

Сначала создайте профиль, затем явно привяжите к нему secret. Secret, который по-прежнему указывает на профиль по умолчанию, воспроизводит исходную проблему.

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

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

Запишите разрешённую службу в один список

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

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

Ограничьте протокол и порт, а не только хост. Accept для хоста без ограничения порта открывает каждую службу, которую этот хост запускает, что шире, чем предполагает большинство заявок на доступ. Порт — часть разрешения, а не деталь, добавляемая позже.

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

Разместите переход выше любого широкого accept

Правило перехода отправляет перенаправленный трафик из ограниченного списка в частную цепочку, где вся политика умещается в трёх строках. Первое правило принимает разрешённое назначение и порт, а последнее отбрасывает всё остальное. Переход должен стоять выше любого широкого accept в forward, потому что более ранний accept означает, что переход никогда не выполняется. Держите accept для established и related перед переходом, чтобы обратный трафик продолжал идти.

Проверьте, что ни одно правило fasttrack не может провести этот трафик мимо ограниченной цепочки. Fasttrack обходит остальную часть пути фильтра, а ограниченный сеанс, прошедший fasttrack, вообще не ограничен.

Повторите решение для цепочки input, если службы самого маршрутизатора должны быть недоступны. Область, которая блокирует перенаправленный трафик и оставляет winbox открытым, выполнена только наполовину.

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

Проверьте счётчиками и членством в списке

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

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

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

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients