У меня есть сетевой сценарий, в котором происходит двойная NAT-переадресация.
Public Firewall и Internal Firewall выполняют NAT-переадресацию. Я контролирую только внутренний брандмауэр.
Клиент: X.X.X.X
Общественный брандмауэр: 10.10.10.1
Внутренний брандмауэр: 192.168.1.10
SSH сервер: 192.168.1.20
Общественный брандмауэр: Перенаправляет все порты на Внутренний брандмауэр
Внутренний брандмауэр: Настроен на перенаправление порта 22 на SSH сервер
Моя проблема в том, что когда Клиент подключается к порту 22 через Публичный брандмауэр, я вижу ip Внутреннего брандмауэра (192.168.1. 10) на SSH сервере вместо IP клиента
Вот как настроены iptables на внутреннем брандмауэре:
iptables -A PREROUTING -t nat -p tcp -d 192.168.1.10 --dport 22 -j DNAT --to-destination 192.168.1.20:22
iptables -A POSTROUTING -t nat -p tcp -d 192.168.1.20 --dport 22 -j SNAT --to-source 192.168.1.10
Есть ли способ сохранить IP клиента, когда он достигает SSH сервера ?
Вы должны быть в состоянии сохранить IP клиента, если вы удалите SNAT на внутреннем брандмауэре, и если все системы имеют соответствующие маршруты для достижения IP адресата в пакетах, которые они отправляют.
Это, скорее всего, означает, что SSH Server должен использовать внутренний брандмауэр в качестве шлюза по умолчанию. Возможно, вам нужно сделать SNAT в обратном направлении, чтобы IP источника SSH сервера был изменен на IP источника внутреннего брандмауэра, когда трафик идет обратно к клиенту. Это зависит от публичного брандмауэра.
Если трафик таинственным образом исчезает на SSH-сервере, попробуйте регистрировать марсианские пакеты (net.ipv4.conf.all.log_martians
) и/или временно отключить фильтр обратного пути (net.ipv4.conf.all.rp_filter
). Начните работать с простых вещей и добавьте сложности, такие как RPF, позже.
При устранении неполадок делайте захват пакетов на определенных интерфейсах (tcpdump -i netX
), а не на всех интерфейсах (tcpdump -i any
), чтобы вы могли видеть, куда именно приходит и откуда уходит трафик.
Если вы не можете установить внутренний брандмауэр в качестве шлюза по умолчанию, вы также можете сделать это с помощью маршрутизации политики на SSH-сервере, но маршрутизация политики довольно ужасна. Не рекомендуется.
Недостаточно информации об остальной части сети, чтобы дать определенный ответ, но да, то, что вы хотите, технически возможно.