LINUX.ORG.RU
Форум — Admin  

Проброс порта iptables в одной сети.

 


0

1

Добрый день. Я понимаю уже 1000 постов про это написаны, но ни как не могу осилить простуйшую проблему. Подскажите пожалуйста где ошибка?

Задача ,была длинная, я упростил до примера:

Пробросить порт 2233 на другой хост на порт 22 в одной подсети.

1. Выступает шлюзом 192.168.1.78. На нём разрешаю всем, в данном примере, на IP 192.168.1.203:22 через 2233. 

iptables -t nat -A PREROUTING -p tcp --dport 2233 -j DNAT --to-destination 192.168.1.203:22
Вижу своё правило: 
iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:2233 to:192.168.1.203:22 

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

проверяю с этого же хоста, где применил правило: 

 telnet localhost 2233
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused

Проверяю с еще одного ПК в этой же подсети: 

telnet 192.168.1.78 2233 
Trying 192.168.1.78...
telnet: connect to address 192.168.1.78: Connection timed out
 ssh user@192.168.1.78 -p 2233 
ssh: connect to host 192.168.1.78 port 2233: Connection refused

Правил ограничивающих нет. Я включил разрешения на всякий (не помогло) 

iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp 
ACCEPT     tcp  --  0.0.0.0/0            192.168.1.203      tcp dpt:22 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0        
sestatus
SELinux status:                 disabled

У меня есть подобные правила на Боевом шлюзе - всё работает. В внешки в сеть пробрасывает. А внутри подсети - немогу.

Буду рад любой подсказке. Спасибо за ваше внимание.


← Помогите настроить редиректы nginx
vgreduce для unknown PV, при наличии двух одноименных VG →

Чует моё сердце, что подменять надо не только адрес назначения (DNAT), но и адрес источника (SNAT). То есть должны быть два правила.

Infra_HDC ★★★★★
()

проверяю с этого же хоста, где применил правило:

Таблицу PREROUTING локальные процессы не проходят. https://www.frozentux.net/iptables-tutorial/images/tables_traverse.jpg

Проверяю с еще одного ПК в этой же подсети:

Как тут написали выше, еще snat нужен.
Возьмем для примера что клиент это 192.168.1.200
С него прилетает пакет на 192.168.1.78
src 192.168.1.200 dst 192.168.1.78

DNAT меняет адрес назначения на 192.168.1.203
src 192.168.1.200 dst 192.168.1.203

192.168.1.203 - получив пакет, отправляет ответ согласно таблицы роутинга
src 192.168.1.203 dst 192.168.1.200

Но ведь 192.168.1.200 такого не ожидает, он отправлял на 192.168.1.78

ЗЫ И еще не забыть
echo 1 > /proc/sys/net/ipv4/ip_forward

anc ★★★★★
()
Ответ на: комментарий от anc

Спасибо за ответы. Сегодня шашлычок. Завтра всё проверю, и отпишусь подробно.

ishk0
() автор топика
Ответ на: комментарий от anc

Вы были правы. Дело в SNAT. Вот подробно почитать про этот вопрос:

https://www.opennet.ru/docs/RUS/iptables/#DNATTARGET

Если линк протухнет, то вот вырезка: 



А теперь посмотрим, что произойдет, если запрос посылается с узла, расположенного в той же локальной сети. Для простоты изложения примем адрес клиента в локальной сети равным $LAN_BOX.

Пакет покидает $LAN_BOX.

Поступает на брандмауэр.

Производится подстановка адреса назначения, однако адрес отправителя не подменяется, т.е. исходный адрес остается в пакете без изменения.

Пакет покидает брандмауэр и отправляется на HTTP сервер.

HTTP сервер, готовясь к отправке ответа, обнаруживает, что клиент находится в локальной сети (поскольку пакет запроса содержал оригинальный IP адрес, который теперь превратился в адрес назначения) и поэтому отправляет пакет непосредственно на $LAN_BOX.

Пакет поступает на $LAN_BOX. Клиент "путается", поскольку ответ пришел не с того узла, на который отправлялся запрос. Поэтому клиент "сбрасывает" пакет ответа и продолжает ждать "настоящий" ответ.

Проблема решается довольно просто с помощью SNAT. Ниже приводится правило, которое выполняет эту функцию. Это правило вынуждает HTTP сервер передавать ответы на наш брандмауэр, которые затем будут переданы клиенту.

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP

Спасибо Infra_HDC и anc, за верное направление. Вопрос решён.

ishk0
() автор топика
Ответ на: комментарий от ishk0

Если линк протухнет

Скорее инет сдохнет. Это линк на iptables tutorial (кстати старенький :) ). На него линков очень много. :)

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Помогите настроить редиректы nginx
Admin
vgreduce для unknown PV, при наличии двух одноименных VG →