Правила входящего трафика SSH и VPN: чем на самом деле управляет список разрешённых

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

Проследите одну попытку SSH до крюка входящего трафика

Клиент отправляет SYN на адрес хоста по порту 22, и ядро решает, предназначен ли этот пакет локальной службе. Если да, выполняется входящий путь и набор правил принимает пакет или отбрасывает его. Тишина означает, что SYN погиб раньше, чем слушатель его увидел, а быстрый отказ означает, что что-то ответило сбросом. Это разные вердикты разных правил, и оба — законные исходы.

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

Пересылка — отдельное решение

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

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

Drop и reject — это действия, а не политики

Политика базовой цепочки принимает или отбрасывает, и это весь список выбора, как указывает справочник по nftables. Отклонение существует как действие правила с выбранным ответом, поэтому запись его как политики терпит неудачу и на nftables, и на iptables. На практике drop не даёт клиенту никакой информации, тогда как reject даёт ему ошибку, с которой можно работать.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Читайте этот набросок как форму решения, а не как файл для вставки, поскольку диапазоны адресов — примеры. Явный reject на порту SSH заставляет неавторизованного клиента сбойнуть за секунду вместо ожидания тайм-аута, что сокращает вашу собственную отладку. Тишина отпугивает случайное сканирование и не сообщает авторизованному пользователю ровным счётом ничего. Выбирайте для каждой службы и записывайте почему, иначе следующий человек всё вернёт.

Сохраните тот управляющий трафик, который действительно нужен

Блокировка всего ICMP — популярное значение по умолчанию, которое ломает обнаружение MTU пути, а симптом — соединение, которое устанавливается и затем застревает на больших пакетах. Обнаружение соседей в IPv6 зависит от собственных типов ICMPv6, и их отбрасывание ломает канал раньше, чем будет прочитано любое правило TCP. И то и другое относится к списку разрешённых как именованные зависимости, а не как сплошные разрешения. Политика, которая молча ломает обнаружение, хуже той, что допускает немного диагностического трафика.

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

Докажите восстановление, прежде чем отказываться от старого пути

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

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