Где ошибка в правилах iptables (NAT)?

Question

[Олег]

iptables -A INPUT -p udp --dport 2306:2402 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p udp --dport 2306:2402 -m state --state NEW -j ACCEPT
iptables -A FORWARD -i eth0 -p udp -d 33.33.33.33 --dport 2306:2402 -j ACCEPT
iptables -t nat -A PREROUTING -p udp -d 222.222.222.222  --dport 2306:2402 -j DNAT --to-destination 33.33.33.33
iptables -t nat -A POSTROUTING -p udp -d 33.33.33.33 --dport 2306:2402 -j MASQUERADE

Клиент с IP: 11.11.11.11 идет на -> 222.222.222.222
Тот его редиректит на 33.33.33.33 а с него уже уходит в локалку -> 192.168.1.1

ДАК ВОТ ВОПРОС...
При такой схеме, ВСЕ подключения клиентов на 192.168.1.1 якобы идут с адреса 222.222.222.222 (т.е. IPTABLES подменяет адрес клиента на свой).
Если убрать 222.222.222.222 из цепочки, то адреса приходят верные.

Как заставить работать NAT на IPTABLES так, чтобы по приходу пакетов, я видел оригинальный адрес отправителя?

Answer 1

[Олег]

Да... помозговал. Это похоже нереальная задача

Comments

[Олег]

hint000, Если я убираю маскарад, я вообще не получаю соединения клиента с сервером.
IP Клиентов всегда разные. И да. В данном случае, я сложно представляю каким правилом роута я решу эту задачу.

[Олег]

hint000, Бардака там ни какого нет. Допускаю что без картинок (схемы) разобраться сложно. Сейчас все поясню

[Олег]

Поясняю.
Client сидя дома выходит в инет со статическим адресом (пусть будет как GW) 11.11.11.11
Программа клиента пытается установить соединение с маршрутизатором (R1) 222.222.222.222, тот в текущей конфигурации, получая пакеты, транслирует их на маршрутизатор (R2), который в свою очередь транслирует пакеты в локальную сеть на сервер 192.168.0.100.
И сейчас все работает. Но как понятно из схемы и двух NATов, сервер (192.168.0.100) видит всех клиентов c IP маршрутизатора R1, что иногда бывает не удобно для той же блокировки по IP.

Если этот промежуточный узел R1 из схемы убрать, IP клиентов отображаются реальные.

Вот и не понятно каким образом можно заменить МАСКАРАД или СНАТ на R1, на правило маршрутизации, чтобы вся схема функционировала. При этом на клиентах ни каких маршрутов не прописывать.

[hint000]

И самое главное чуть не пропустил. Шлюз обязан быть в той же самой сети. Если на сервере шлюзом указан 33.33.33.33, то и сервер должен быть в той же сети, например 33.33.33.44/24. Ваша схема просто образец для собеседований - "найдите на схеме 10 ошибок".

[Олег]

hint000, Причина в 2х роутерах проста. Нужно скрыть от клиентов IP конечного роутера (33.33.33.33).
R1 - это VDS сидящий на просторах интернета. Работающий на пересылку всех пакетов от клиентов до R2.
В добавок R1 имеет ряд платных фишек (АнтиДДОС и т.п.).

Соответственно R2 (33.33.33.33) и сервера за ним стоят в коммутационной стойки внутри компании.

Ед. решение, которое я вижу прямо сейчас - это поднять VPN тунель (точка - точка) между R1 и R2. Но опять же я из за NAT на R1, вангую, что IP адреса клиентов я не увижу.

Как разжевать еще понятнее чем на скрине, я не представляю. IP адреса в вопросе и в схеме могут отличаться. Вы просили пояснить, я для примера накидал схему коммутации. Не думаю что локальные подсети 1.1 и 0.100 влияют на ответ по маршрутам между R1 и R2

[Олег]

hint000, "Где находится 33.33.33.1 - на R1?" 33.33.33.1 - это шлюз через который R2 выходит в сеть интернет (шлюз провайдера).

[hint000]

Олег, Просто надо было сразу упомянуть, что R1 - это VDS, было бы намного понятнее.

Ед. решение, которое я вижу прямо сейчас - это поднять VPN тунель (точка - точка) между R1 и R2.

И это правильно.

Но опять же я из за NAT на R1, вангую, что IP адреса клиентов я не увижу.

Есть несколько вариантов решения.
1. на R1 только DNAT без SNAT; VPN-адрес R1 является шлюзом по-умолчанию для R2;
2. на R1 только DNAT без SNAT; VPN пробрасывается между сервером и R1; R1 является шлюзом по-умолчанию для сервера;
3. на R1 только DNAT без SNAT; на R1 настраивается source-based routing (policy-based routing); самый сложный вариант, но и самый универсальный.

[Олег]

hint000, Вот я с этого и начал. Что простой маршрутизацией вопрос не решить. Видимо придется городить ВПН. Лишь бы только она не сильно нагружала задержку (ping).

Спасибо за советы.

Answer 2

[alfss]

Не использовать NAT.

Comments

[Олег]

Не вариант....
У меня есть сегмент, где 2 роутера (аппаратных) идут друг за другом. И пакеты пролетают с корректными IP. Следовательно, тут надо просто настроить