iptables: разрешить клиентам VPN доступ только к одному хосту

Нужное правило находится в FORWARD, а не в INPUT. Разрешите одно назначение для пула VPN, отклоните остальное, затем докажите это счётчиками и командой отката.

Две заявки в поддержку, которые выглядят несвязанными, в итоге имеют одну причину. В первой администратор хочет, чтобы сервер принимал подключения только из туннеля; во второй пользователи VPN должны попадать на один внутренний хост и никуда больше. Обе политики относятся к FORWARD, и обе обычно пытаются реализовать в INPUT. Результат выглядит как межсетевой экран, а ведёт себя как заглушка.

Какая цепочка отвечает на ваш вопрос

Пакеты, которые клиент VPN отправляет хосту в локальной сети или дальше в интернет, ядро пересылает, и они оцениваются в FORWARD. INPUT и OUTPUT видят только трафик, который завершается на самом сервере или исходит от него. Поэтому отклонение всего, что не приходит на tun0, защищает собственные слушатели сервера и заодно оборвёт вашу сессию SSH, если сначала не разрешить установленные потоки. Это никак не меняет того, куда клиентам разрешено ходить.

Сначала назовите вопрос: кто может достичь сервера или куда могут идти клиенты. Большинству сетей нужны оба ответа, в разных цепочках.

Сначала состояние, затем разрешение, затем отказ

Список разрешений работает только если конкретное разрешение стоит выше общего отказа и если обратный трафик разрешён выше обоих. Вставляйте правила на явные позиции, затем выведите цепочку с помощью iptables -S FORWARD, чтобы порядок был виден, а не предполагался.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Две детали решают, переживёт ли это столкновение с реальным трафиком. Без правила состояния ответы на только что разрешённые соединения сами оцениваются против отказа и отбрасываются. Правило LOG без ограничения может заполнить небольшой раздел при первом же сканировании, поэтому добавьте -m limit --limit 10/min, прежде чем продолжать журналирование. REJECT немедленно возвращает ошибку, что удобнее при настройке списка; DROP отбрасывает молча, поэтому каждая ошибка выглядит как истёкший тайм-аут. Выберите один осознанно и запишите выбор в журнал изменений.

Пересылка и NAT уже должны работать

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Где находится маскарадинг, зависит от того, откуда выходят клиенты. Если они уходят через туннель в удалённую сеть, правило NAT ставится на этот интерфейс, а не на WAN. Затем смотрите на счётчики: если счётчик POSTROUTING никогда не двигается, а число разрешений в FORWARD растёт, обратный путь сломан, а фильтр в порядке. Такое чтение экономит полдня на переписывание правил, которые никогда не были проблемой.

Блок почты относится к соседней цепочке

Блокировка порта 25 в INPUT останавливает только почту, адресованную серверу VPN. Скомпрометированный клиент, отправляющий почту через туннель, пересылается, поэтому блок должен стоять в FORWARD рядом с 465 и 587. Если одно приложение легально пересылает почту, поставьте его назначение и порт выше этого правила.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

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

Перечитайте всё обратно, затем докажите с клиента

Читайте набор правил так, как его сообщает ядро, а не так, как его написал ваш скрипт. Начните с iptables -S FORWARD, затем таблица NAT с помощью iptables -t nat -L POSTROUTING -n -v, затем запись conntrack для проверяемого потока. Держите под рукой команду отката или запланированную очистку, пока идёт работа. Каждый вызов требует -w, иначе два администратора столкнутся на блокировке xtables. Ничто из этого не является необязательным в окне изменений.

Завершите проверкой с клиента внутри пула и с клиента снаружи. Правило, которое работает только с той машины, где вы его набрали, — не политика.

Похожие статьи