Вопрос или проблема
В настоящее время я пытаюсь заставить мой Apache Reverse Proxy маскировать все, кроме SSH, к одному конкретному серверу во внутренней сети. Причина этого заключается в том, что я хочу, чтобы сервер, доступный по SSH, видел оригинальные IP-адреса тех, кто пытается подключиться к нему, а не IP прокси.
Прокси также дополнительно маршрутизирует несколько внутренних веб-сайтов, чтобы сделать их доступными из интернета.
Внешний IP прокси в этом примере: 11.11.11.11
Внутренний IP прокси в этом примере: 191.168.1.32
Внутренний IP сервера, доступного по SSH, в этом примере: 191.168.1.116
SSH работает на порту 22.
У меня есть следующие правила:
iptables -t nat -A PREROUTING -p tcp --dport 22 -i $EXT -j DNAT --to-destination 192.168.1.116:22 (чтобы направлять весь SSH-трафик, поступающий на прокси, на сервер, доступный по SSH)
iptables -A FORWARD -p tcp -d 192.168.1.116 --dport 22 -j ACCEPT (чтобы перенаправлять SSH-трафик)
iptables -t nat -A POSTROUTING -o eth0 ! -d 192.168.1.116 -j MASQUERADE (чтобы маскировать все, кроме SSH-трафика)
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.116 -p tcp --dport 22 -j SNAT --to 11.11.11.11 (чтобы позволить SSH-ответам снова выйти в интернет?)
Я пробовал с последним правилом (SNAT) и без него. В обоих случаях SSH-трафик не поступает на сервер, доступный по SSH.
Если я добавляю:
iptables -t nat -A POSTROUTING -o eth0 -d 192.168.1.116 -p tcp --dport 22 -j SNAT --to 192.168.1.32
трафик снова поступает, но очевидно с IP прокси, а не оригинального IP подключающегося компьютера.
Есть ли способ настроить это так, чтобы внутренний сервер, доступный по SSH, видел оригинальный IP, но трафик всё ещё правильно маршрутизировался через прокси?
Заранее спасибо за любую помощь!
ИЗМЕНЕНИЕ:
Я также попробовал без правил:
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.116 -p tcp --dport 22 -j SNAT --to 11.11.11.11
и
iptables -t nat -A POSTROUTING -o eth0 -d 192.168.1.116 -p tcp --dport 22 -j SNAT --to 192.168.1.32
но вместо этого установил шлюз на сервере, доступном по SSH, как 192.168.1.32: Всё равно не работает.
Если я добавляю правило “MASQUERADE all” после правила “MASQUERADE except to destination 192.168.1.116”, я вижу по счетчикам пакетов только те пакеты, которые идут к 192.168.1.116… они полностью коррелируют со счетчиком пакетов правила DNAT и с заблокированными попытками SSH на сервере, доступном по SSH, которые просто случайно приходят от ботов (я так думаю):
Каждый раз, когда счетчик DNAT увеличивается на 1, счетчик “MASQUERADE all” увеличивается на 1, и в журнале SSH на сервере, доступном по SSH, отображается 1 неудачная попытка входа. Таким образом, правило “MASQUERADE except to destination 192.168.1.116” похоже работает.
Что я не понимаю: Почему журнал SSH ничего не показывает, когда правило “MASQUERADE all” отсутствует? Не должны ли SSH-пакеты от ботов хотя бы поступить на сервер, доступный по SSH, благодаря правилу DNAT? Они просто не должны были бы найти обратный путь? Но если правило “MASQUERADE all” отсутствует, в журнале SSH активность равна НУЛЮ… почему?
Ответ или решение
Проблема, с которой вы столкнулись, заключается в перенаправлении трафика SSH через Apache Reverse Proxy так, чтобы исходный IP адрес подключающегося пользователя был видим целевому серверу, а не IP прокси. Это задача, которая требует внимательной настройки сетевых правил, чтобы обеспечить корректную маршрутизацию и избежать ненужного изменения IP адресов через NAT (Network Address Translation).
Теория
NAT обычно используется для маскировки исходных IP адресов пользователей при прохождении через маршрутизатор или прокси-сервер. В контексте трансляции адресов мы имеем два основополагающих подхода: источниковая трансляция адресов (SNAT) и конечная трансляция адресов (DNAT). SNAT изменяет исходный IP адрес пакета, а DNAT изменяет адрес назначения. Однако в вашей задаче, если необходимо сохранить исходный IP адрес доступа для соединений SSH, нужно контролировать, чтобы NAT не вмешивался в SSH трафик.
Пример
Рассмотрим пример исправного функционирования. Для успешной передачи исходного IP адреса через прокси, необходимо правильно организовать иерархию правил маршрутизации пакетов. Ваши попытки решения задачи включали следующее:
- Перенаправление входящего SSH-трафика на целевой сервер:
iptables -t nat -A PREROUTING -p tcp --dport 22 -i $EXT -j DNAT --to-destination 192.168.1.116:22 - Разрешение транзита SSH-трафика:
iptables -A FORWARD -p tcp -d 192.168.1.116 --dport 22 -j ACCEPT - Исключение маскарадинга для трафика, направленного на сервер SSH:
iptables -t nat -A POSTROUTING -o eth0 ! -d 192.168.1.116 -j MASQUERADE
Ваши попытки включали также использование SNAT для изменения исходного IP-адреса ответных пакетов, однако это привело к маскированию прокси, что противоречит задачам.
Вы пришли к нужным выводам в вашей последней формулировке: исключение трафика к 192.168.1.116 из MASQUERADE решает часть задачи. Однако, важно убедиться, что трафик действительно возвращается.
Решение
Правильная настройка маршрутизации предполагает следующее:
-
Наблюдение за маршрутом возврата: Убедитесь, что SSH-сервер (192.168.1.116) направляет исходящий трафик обратно через прокси (192.168.1.32). Это может быть сделано путем настройки шлюза по умолчанию на сервере SSH или маршрутизации только для трафика, исходящего от него.
-
Проверка правил FORWARD: Правило иптаблес FORWARD должно не только разрешать трафик к серверу SSH, но и обеспечивать его возвращение от сервера через прокси.
-
Отказ от лишних правил SNAT: Избавьтесь от правил SNAT, которые меняют исходные IP адреса на стороне прокси. Это изначально было неправильным подходом для достижения поставленной вами задачи.
-
Мониторинг сетевого трафика: Используйте такие инструменты, как tcpdump или Wireshark, чтобы удостовериться, что пакеты отправляются и возвращаются правильно, сохраняя исходный IP адрес. Это поможет выявить точное место, где может происходить потеря информации о исходном IP.
-
Логирование пакетов: Временно включите extensive logging на ваших нативных IPTables правилах для отслеживания пакетов и выявления узких мест или неправильных маршрутов.
Заключение
Таким образом, решение задачи достижения видимости исходного IP на сервере SSH через прокси заключается в детальной настройке цепочек iptables. Важная часть — избегать маскардинга для целевого трафика к серверу SSH и обеспечивать корректный маршрут для ответных пакетов обратно через прокси. Также уделите внимание тестированию и мониторингу сетевых взаимодействий для принятия обоснованных коллегиальных решений.