Настройки iptables для транзита на другой сервер?

Question

[Сергей]

Доброго времени суток.
Есть две тачки с debian и WS. На WS стоит IIS с кучей сайтов, все они сейчас смотрят в интернет, нужно спрятать их за тачку с debian.
Debian тачка имеет два сетевых интерфейса:
eth0 22.22.22.22 - интернет
eth1 192.168.1.100 - локалка
WS:
eth0 33.33.33.33
eth1 192.168.1.200
Локалка общая, тачки друг друга пингуют по локалке.

Я делаю так:

iptables -F
iptables -t nat -F
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -i eth0 -p icmp -j ACCEPT
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 9090 -j ACCEPT # хочу через этот порт пустить трафик

#Пакеты с нужного адреса заворачиваем на компьютер
iptables -t nat -A PREROUTING -s 22.22.22.22 --sport 8172 -i eth0 -j DNAT --to-destination 196.168.1.200 --dport 9090
#Разрешаем эти пакеты
iptables -t filter -A FORWARD -s 22.22.22.22 -d 192.168.1.200 -j ACCEPT
#Получаем интернет в локалке
#iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 22.22.22.22
#Прописываем путь пакета с debian до WS
iptables -t nat -A POSTROUTING -d 192.168.1.200 --sport 9090 -s 192.168.1.0/24 -j SNAT --to-source  192.168.1.100 --dport 9090
#Меняем адрес источника на поддельный
iptables -t nat -A POSTROUTING -s 22.22.22.22 -j SNAT --to-source 192.168.1.150
#Добавляем новый адрес роутеру XX - любое незанятое в локалке число
ip addr add 192.168.1.150/24 dev eth1
#где .150 - не занятый локальный адрес

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

Но что-то идёт не так.
Если что текст перепечатывал, чтоб ещё раз продумать, могут быть очепятки, но при выполнении скрипта ошибок не выдаёт.

Comments

[krosh]

Когда Вы прячете WS внутрь локальной сети, внешний интерфейс 33.33.33.33 остается активным?
Какой маршрут по умолчанию на WS?
Какой смысл подменять адрес на 192.168.1.150?
Покажите полностью цепочку FORWARD.

[Виктор Бельский]

Вы тут что-то совсем непонятное написали. Если вы хотите чтобы сайты были доступны по адресу 22.22.22.22, то зачем форвардите только порт 9090, да еще указываете порт источника 8172. Зачем вам какой-то адрес 192.168.1.150? Или у сервера с Debian просто нет адреса на интерфейсе eth1?

[Сергей]

krosh, 1. да
2. network 00.00.00.00 netmask 00.00.00.00 gateway 33.33.33.1
3. Чтоб пакет с WS вернулся на сервак с Debian, а не напрямую в интернет ушёл.
4. Форвард вся.

Виктор Бельский, 8172 - опечатка, там 9090, извиняюсь.
Я хочу чтобы две тачки связывались через назначенный порт, если для множества портов, то порты я так понимаю указывать не нужно?
Адрес есть, .150 дополнительный, чтобы пакет вернулся с WS на debian, а не напрямую ушёл к пользователю.

Добавлю, что на debian сервере стоит nginx, который исполняет роль реверс прокси, но с настройками iptables по умолчанию, не работает, возвращает ошибку.

[krosh]

Сергей, и еще с WS проверьте, чтобы был пинг и трейс до 192.168.1.100. Если нет, то нужно добавить статический маршрут.

[Сергей]

krosh, Трейс и пинг с WS работает, с debian только ping идёт.
А по какой схеме идёт пакет:
internet > server debian (iptables > nginx) > ws?
Или nginx внутри правил iptables проходит, т.е. prerouting > input > nginx > output > postrouting?
Не знаете?

[krosh]

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

Путь прохождения пакета зависит от конечной цели: локальный процесс (nginx) или удаленный хост (iptables-NAT). Но цепочки PREROUTING и POSTROUTING пакет проходит в лбом случае. Только разница в том что, когда пакет идет к ngix, то преобразования в этих цепочках не нужны, и мы их не используем, а когда пакет маршрутизируется дальше в сеть - вносим изменения.

Разница между nginx и iptables-NAT еще и в том, что первый работает как прокси, пакет не пересылает, а сам генерирует новый с запросом уже к WS. Второй - пакет остается, только меняются адреса в заголовке.

Используя nginx пишем правила для цепочек: INPUT. iptables-NAT - PREROUTING, POSTROUTING и FORWARD.

Если Вам нужно организовать доступ только веб-сервера (хоть и на нестандартном порту), то лучше все же изучить proxy_pass nginx'a. Тут есть бонус, можно в заголовке передавать реальный адрес источника, так что в логах вы будете видеть не просто ип-адрес роутера, а именно клиента, сделавшего запрос.

Кстати, надеюсь
cat /proc/sys/net/ipv4/ip_forward
показывает 1?

И проверьте файерволл на WS, чтобы он разрешал debian запросы на 9090.

Answer 1

[krosh]

Что-то у Вас каша с правилами. Чтобы порт пробросить в локальную сеть нужно три правила в цепочках: PREROUTING, POSTROUTING и FORWARD.

Попробуйте почистить все и использовать такие:

#Пакеты с нужного адреса заворачиваем на компьютер
iptables -t nat -A PREROUTING -d 22.22.22.22 --dport 9090 -i eth0 -j DNAT --to-destination 196.168.1.200:9090

#Получаем интернет в локалке - это не обязательно, если инет через другой шлюз
#iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 22.22.22.22

#Меняем адрес источника на локальный
iptables -t nat -A POSTROUTING -d 196.168.1.200 -p tcp -m tcp --dport 9090 -j SNAT --to-source 196.168.1.100

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -m comment --comment "ALLOW Установленные соединения" -j ACCEPT
iptables -A FORWARD -p tcp -m tcp --dport 9090 -m comment --comment "ALLOW LAN all 9090" -j ACCEPT

Цепочка INPUT не влияет на проходящий трафик, можете правило для 9090 от туда удалять.

Если у Debian есть .100, то не вижу смысла ему еще выдавать какой-то.

Comments

[Сергей]

krosh, В общем через 443 порт всё работает, нужный сайт на iis спрятался за nginx (правда не пингуется теперь). Пришлось психануть и разрешить цепочке форвард 80,443 порты, потом выясню методом тыка какой оставить..
На WS в фаерволле поставил ещё один порт с разрешением на всё что можно, nginx перенастроил на этот порт и почему-то всё равно не хочет.. буду играть с настройками.

Кстати раз цепочка форвард влияет, то получается nginx идёт после правил iptables.
И ещё, спасибо, что откликнулись.

[krosh]

Сергей, если пришлось добавлять правила в цепочку FORWARD, то Вы пользуетесь пробросом портов, а не nginx. Проверьте настройки.

Вот схема про порядок прохождения трафика: https://commons.wikimedia.org/wiki/File:Netfilter-...

Nginx - локальный процесс и он не может "идти в обход". Весь сетевой трафик в linux проходит путь описанный на схеме.

[Сергей]

krosh, Да, я уже разобрался, что да как.

Answer 2

[Сергей]

Кому интересно конечный конфиг у меня такой:

# Пакеты с нужного адреса заворачиваем на компьютер
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 9090 -d $ip-deb -i eth0 \
-j DNAT --to-destination $local-ip-ws:9090

# Меняем адрес источника на локальный, не использую т.к. я так понял это надо для общения компьютеров внутри сети через внешний сервер, а оно мне не надо.
#/sbin/iptables -t nat -A POSTROUTING -d $local-ip-ws -p tcp \
#-m tcp  -j SNAT --to-source $local-ip-deb

# Разрешаем соединение для новых, прошедших проверку, пакетов
/sbin/iptables -A FORWARD -p tcp -m conntrack --ctstate NEW \
-m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
/sbin/iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Разрешаем прохождение пакетов для порта через FORWARD
/sbin/iptables -A FORWARD -p tcp -m tcp --dport 9090 -j ACCEPT

nginx почему-то не хотел работать, если прописывать просто listen 80; или listen 443 ssl;
зато заработало listen ip-deb:80; и listen ip-deb:443 ssl;