Допустим, мы находимся в локальной сети и от внешнего мира отделены шлюзом под управлением Linux.
В этой же локальной сети находятся сервера, которые должны предоставлять услуги внешнему миру. Например, web-сервер, ftp, почтовый сервер или все вместе одновременно.

Понятно, что доступ извне должен осуществляться через внешний адрес шлюза. И в зависимости от типа входящего соединения (которое определяется портом, например 80 - веб сервер, 21 - FTP), шлюз должен перенаправлять его на соответствующий сервер локальной сети.

Это и есть проброс портов.
Рассмотрим, как реализовать его средствами iptables.

Вначале договоримся о сокращениях и умолчаниях:

$EXT_IP - внешний, реальный IP-адрес шлюза
$INT_IP - внутренний IP-адрес шлюза, в локальной сети
$LAN_IP - внутренний IP-адрес сервера, предоставляющего службы внешнему миру
$SRV_PORT - порт службы. Для веб-сервера равен 80, для SMTP - 25 и т.д.
eth0 - внешний интерфейс шлюза. Именно ему присвоен сетевой адрес $EXT_IP
eth1 - внутренний интерфейс шлюза, с адресом $INT_IP

А для облегчения понимания, в таких блоках будем рассматривать конкретную ситуацию:
1.2.3.4 - внешний адрес шлюза
192.168.0.1 - внутренний адрес шлюза
В локальной сети работает веб-сервер (порт 80) для сайта webname.dom
192.168.0.22 - внутренний адрес веб-сервера

Проброс портов

Итак, пакет пришёл на шлюз. Мы должны перенаправить его на нужный сервер локальной сети перед принятием решения о маршрутизации, то есть - в цепочке PREROUTING таблицы nat.

iptables -t nat -A PREROUTING --dst $EXT_IP -p tcp --dport $SRV_PORT -j DNAT --to-destination $LAN_IP

iptables -t nat -A PREROUTING --dst 1.2.3.4 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.22

Читай: если входящий пакет пришёл извне на шлюз (1.2.3.4), но предназначен веб-серверу (порт 80), то адрес назначения подменяется на локальный адрес 192.168.0.22. И впоследствии маршрутизатор передаст пакет в локальную сеть.

Дальше принимается решение о маршрутизации. В результате пакет пойдёт по цепочке FORWARD таблицы filter, поэтому в неё надо добавить разрешающее правило. Оно может выглядеть, например, так:

iptables -I FORWARD 1 -i eth0 -o eth1 -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j ACCEPT

iptables -I FORWARD 1 -i eth0 -o eth1 -d 192.168.0.22 -p tcp -m tcp --dport 80 -j ACCEPT

Пропустить пакет, который пришёл на внешний интерфейс, уходит с внутреннего интерфейса и предназначен веб-серверу (192.168.0.22:80) локальной сети.

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

Допустим, 192.168.0.333 - ip-адрес клиента внутри локальной сети.

  1. сотрудник вводит в адресную строку браузера адрес webname.dom
  2. компьютер обращается к DNS и разрешает имя webname.dom в адрес 1.2.3.4
  3. маршрутизатор понимает, что это внешний адрес и отправляет пакет на шлюз
  4. шлюз, в соответствии с нашим правилом, подменяет в пакете адрес 1.2.3.4 на 192.168.0.22, после чего отправляет пакет серверу
  5. веб-сервер видит, что клиент находится в этой же локальной сети (обратный адрес пакета - 192.168.0.333) и пытается передать данные напрямую клиенту, в обход шлюза
  6. клиент игнорирует ответ, потому что он приходит не с 1.2.3.4, а с 192.168.0.22
  7. клиент и сервер ждут, ведут себя как «две целки на морозе», связи и обмена данными нет

Есть два способа избежать подобной ситуации.

Первый - чётко разграничивать обращения к серверу изнутри и извне.

Создать в локальном DNS-сервере A-запись для webname.dom, указывающую на 192.168.0.22.

Второй - с помощью того же iptables заменить обратный адрес пакета.
Правило должно быть добавлено после принятия решения о маршрутизации и перед непосредственной отсылкой пакета. То есть - в цепочке POSTROUTING таблицы nat.

iptables -t nat -A POSTROUTING --dst $LAN_IP -p tcp --dport $SRV_PORT -j SNAT --to-source $INT_IP

iptables -t nat -A POSTROUTING --dst 192.168.0.22 -p tcp --dport 80 -j SNAT --to-source 192.168.0.1

Если пакет предназначен веб-серверу, то обратный адрес клиента заменяется на внутренний адрес шлюза.
Этим мы гарантируем, что ответный пакет тоже пойдёт через шлюз.

Надо дополнительно отметить, что это правило важно только для внутренних клиентов. Ответ внешним клиентам пойдёт через шлюз в любом случае.

Но, пока что, для нормальной работы этого недостаточно. Предположим, что в качестве клиента выступает сам шлюз.
В соответствии с нашими предыдущими правилами он будет гонять трафик от себя к себе же и представлять исходящие пакеты транзитными. Так и с ума сойти недолго. Исправляем это:

iptables -t nat -A OUTPUT --dst $EXT_IP -p tcp --dport $SRV_PORT -j DNAT --to-destination $LAN_IP

iptables -t nat -A OUTPUT --dst 1.2.3.4 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.22

Вот теперь - всё. Получившийся результат можно оформить в виде скрипта, чтобы не делать каждый раз всё вручную.

Кстати.
Если подключение к сети интернет осуществляется, например, через pppoe, то внешним интерфейсом будет pppN, он и должен быть вписан в правила iptables. Потому что в этом случае интерфейс eth0 будет использоваться только для установки связи с pppoe-сервером.

script.sh

#!/bin/bash
EXT_IP="xxx.xxx.xxx.xxx" # Он всё равно чаще всего один и тот же.
INT_IP="xxx.xxx.xxx.xxx" # См. выше.
EXT_IF=eth0 # Внешний и внутренний интерфейсы.
INT_IF=eth1 # Для шлюза они вряд ли изменятся, поэтому можно прописать вручную.
LAN_IP=$1   # Локальный адрес сервера передаём скрипту первым параметром,
SRV_PORT=$2 # а тип сервера, в смысле какой порт (или набор портов) открывать - вторым

# Здесь желательно сделать проверку ввода данных, потому что операции достаточно серьёзные.

iptables -t nat -A PREROUTING --dst $EXT_IP -p tcp --dport $SRV_PORT -j DNAT --to-destination $LAN_IP
iptables -t nat -A POSTROUTING --dst $LAN_IP -p tcp --dport $SRV_PORT -j SNAT --to-source $INT_IP
iptables -t nat -A OUTPUT --dst $EXT_IP -p tcp --dport $SRV_PORT -j DNAT --to-destination $LAN_IP
iptables -I FORWARD 1 -i $EXT_IF -o $INT_IF -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j ACCEPT

Теперь, чтобы обеспечить доступ извне к локальному FTP по адресу 192.168.0.56, достаточно набрать в консоли от имени суперпользователя:

./script.sh 192.168.0.56 20,21

Экономия времени и сил налицо.

Перенаправление портов

Перенаправление портов нужно в том случае, если мы хотим «замаскировать» внутреннюю службу, обеспечив к ней доступ извне не по стандартному, а совсем по другому порту. Конечно, можно заставить сам веб-сервер слушать нестандартный порт, но если он используется рядовыми сотрудниками внутри локальной сети, то мы элементарно столкнёмся с человеческим фактором. Сотрудникам будет очень тяжело объяснить, что теперь для доступа к корпоративному сайту надо после его имени вводить набор цифр через двоеточие.

Именно из-за человеческого фактора перенаправление портов используется, в основном, специалистами, для удалённого администрирования.

Пусть $FAKE_PORT - обманный порт на внешнем интерфейсе шлюза, подключившись к которому мы должны попасть на адрес $LAN_IP и порт $SRV_PORT.

Набор правил для iptables будет отличаться несущественно, поэтому приведу сразу пример итогового скрипта для ленивых.

#!/bin/bash
EXT_IP="xxx.xxx.xxx.xxx" # Он всё равно чаще всего один и тот же.
INT_IP="xxx.xxx.xxx.xxx" # См. выше.
EXT_IF=eth0 # Внешний и внутренний интерфейсы.
INT_IF=eth1 # Для шлюза они вряд ли изменятся, поэтому можно прописать вручную.
FAKE_PORT=$1  # Вначале передаём скрипту "неправильный" порт на внешнем интерфейсе,
LAN_IP=$2     # затем - локальный адрес сервера
SRV_PORT=$3   # и в конце - реальный порт для подключения к серверу

# Здесь опять надо сделать проверку ввода данных, потому что операции всё ещё серьёзные.

iptables -t nat -A PREROUTING -d $EXT_IP -p tcp -m tcp --dport $FAKE_PORT -j DNAT --to-destination $LAN_IP:$SRV_PORT
iptables -t nat -A POSTROUTING -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j SNAT --to-source $INT_IP
iptables -t nat -A OUTPUT -d $EXT_IP -p tcp -m tcp --dport $SRV_PORT -j DNAT --to-destination $LAN_IP
iptables -I FORWARD 1 -i $EXT_IF -o $INT_IF -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j ACCEPT

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

Изменения в остальных правилах сделаны для наглядности и их сути не меняют.



vilfred
2010.08.16 15:53:29
#cid214

Ответить

спасибо! при помощи статьи был жоско прохачен беспроводный модем cnu680pro

vilfred
2010.08.16 15:59:11
#cid215

Ответить

собсно тут http://www.lor-ng.org/message.php?newsid=8020

2010.08.16 19:39:00
#cid216

Ответить

))

Пожалуйста!

jetmind
2010.11.11 20:35:41
#cid586

Ответить

Спасибо! Чуть ли не единственная адекватная статья по теме :)

Huntervp
2011.01.23 09:59:33
#cid1385

Ответить

Долго мучалсо с пробросом портов пока не нашел эту статью, единственный адекватный ответ, а то все пересылать только куда то умеют, а по делу сказать ни чего умного не могут.

oermolaev
2011.02.08 15:52:29
#cid1543

Ответить

столько ресурсов пришлось перелопатить прежде чем нашёл этот реально работающий материал!!!
СПАСИБО!

WowihaY
2011.02.26 13:17:32
#cid1679

Ответить

Ну хоть что-то заработало! Спасибо за разъяснения, ибо iptables дремучий лес. А так ткнулся в скрипт, и ок!

2011.02.26 18:10:48
#cid1680

Ответить

Ну хоть что-то заработало! Спасибо за разъяснения, ибо iptables дремучий лес.

По первой ссылке в конце - отличный мануал по iptables.

А так ткнулся в скрипт, и ок!

Низзя запускать непроверенные скрипты с посторонних сайтов!!!

Vlad29
2011.03.30 00:10:15
#cid1941

Ответить

понятно и со знанием написано. больше недели не мог ничего вразумительного найти
использовал скрипт с такими параметрами:
EXT_IP="193.193.6.221" # Он всё равно чаще всего один и тот же.
INT_IP="192.168.253.244"

## EXT_IF=eth0 # Внешний и внутренний интерфейсы.
EXT_IF=ppp0 # модем мобильного прова

## INT_IF=eth1 нет у меня второй сетевой на ноуте
INT_IF=eth0
LAN_IP=$1 # Локальный адрес сервера передаём скрипту первым параметром,
SRV_PORT=$2 # а тип сервера, в смысле какой порт (или набор портов) открывать - вторым

# Здесь желательно сделать проверку ...
# и далее по тексту буква в букву
# при условии, что
route add default gw 192.168.253.244 # в лок.Сети
route add default gw 193.193.6.221 # на шлюзе
Destination Gateway Genmask Flags MSS Window irtt Iface
77.193.0.225 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.253.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 193.193.6.221 0.0.0.0 UG 0 0 0 ppp0

# на выходе получаем
Interesting ports on (193.193.6.221):
Not shown: 993 closed ports
PORT STATE SERVICE
20/tcp filtered ftp-data
21/tcp filtered ftp

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere 192.168.253.243 tcp dpt:ftp-data
ACCEPT tcp -- anywhere 192.168.253.243 tcp dpt:ftp
ACCEPT all -- 192.168.253.0/24 anywhere < это FORWARDing, примеч.
ACCEPT all -- anywhere 192.168.253.0/24 < это FORWARDing

соединение из инета с ftp-сервером 193.193.6.221 (лок.ip 192.168.253.243) происходит,
скачивание файлов выполняется.
СПАСИБО !!!

Lovi
2011.04.09 00:18:33
#cid2066

Ответить

Спасибо!!!

Dmitii
2011.05.15 21:03:38
#cid2614

Ответить

Спасибо за статью. Преподнес идеально! Молодец!

Михаил
2011.05.25 07:39:39
#cid2778

Ответить

Спасибо. Всё подошло и работает.

Михаил
2011.05.30 14:01:23
#cid2883

Ответить

Спасибо за статью , всё очень просто и понятно написано !

papont2007
2011.06.01 08:44:48
#cid2904

Ответить

А вот у меня пока облом. И самое главное что в принципе это должно работать а ..... Рою.
Тебе бы в таком духе весь iptables расписать. Очень доходчиво и не обидно для тех кто что то знает но в некоторых местах сомневается. Я понимаю что это будет повторение HOWTO, но почему бы и нет с твоими коментариями.

2011.06.02 04:27:21
#cid2923

Ответить

А вот у меня пока облом. И самое главное что в принципе это должно работать а ..... Рою.

Это как у программистов: 5% потраченного времени занимает написание кода, а оставшиеся 95% — его отладка )

Тебе бы в таком духе весь iptables расписать.

Весь iptables — это слишком круто. Но есть запись по его основам, в черновом варианте, пока недоступна для просмотра. Возможно, буду выкладывать по частям.

Очень доходчиво и не обидно для тех кто что то знает но в некоторых местах сомневается. Я понимаю что это будет повторение HOWTO, но почему бы и нет с твоими коментариями.

Не знаю, лично мне эта запись кажется слишком громоздкой и поэтому сложной для восприятия. Вношу исправления периодически.

Constantin
2011.06.20 14:58:21
#cid3236

Ответить

Спасибо!!!Помогло.Отлично обьяснил.

zerg90
2011.07.04 23:16:01
#cid3532

Ответить

Автору спасибо. сейчас на любой форум как не зайдешь все только пальцы гнут да в мануалы посылают.

Fleeseace
2011.08.04 02:24:47
#cid4338

Ответить

Большое спасибо за помощь в этом вопросе.

Kurs
2011.08.14 23:19:19
#cid4639

Ответить

Огромное СПАСИБО!!!

YuSV
2011.08.18 10:15:00
#cid4750

Ответить

Спасибо, второй день мучаюсь, скрип работает под Дебиан 6.

Sergey95
2011.09.18 09:56:00
#cid5624

Ответить

Сдраствуйте не могли бы вы мне помочь? у меня два прова НО! один работает через DHCP, а второй DHCP ->VPN как всё это настроить с нуля в командной строке?

Sergey95
2011.09.18 10:12:17
#cid5625

Ответить

Да для полной кортины Eth0(DHCP->VPN) Eth1 Локалка Eth2 просто DHCP(сейчас он работает таким образом
#!/bin/sh

# Включаем форвардинг пакетов
echo 1 > /proc/sys/net/ipv4/ip_forward

# Разрешаем трафик на loopback-интерфейсе
iptables -A INPUT -i lo -j ACCEPT

# Разрешаем доступ из внутренней сети наружу
iptables -A FORWARD -i eth1 -o eth2 -j ACCEPT

# Включаем NAT
iptables -t nat -A POSTROUTING -o eth2 -s 10.0.0.0/24 -j MASQUERADE

# Запрещаем доступ снаружи во внутреннюю сеть
iptables -A FORWARD -i eth2 -o eth2 -j REJECT

мои настройки сети(для полной картины
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth2
iface eth2 inet dhcp

#LAN
auto eth1
iface eth1 inet static
address 10.0.0.1
netmask 255.255.255.0

post-up /etc/nat

Eth0 ещё не прописывал т.к. если её поднять то отваливаеться инет по Eth2

2011.09.18 11:19:36
#cid5628

Ответить

Сдраствуйте

Топрый теннь.

у меня два прова НО! один работает через DHCP, а второй DHCP ->VPN как всё это настроить с нуля в командной строке?

У вас два рабочих шланга в интернет. Откуда шлюз знает через который трафик гонять? Вот оно и отваливается.
А чтобы ничего не отваливалось — надо правильно прописать маршрутизацию. Или другим способом извращаться, всё зависит от целей.

Ищите в Яндексе «linux шлюз два провайдера». Это целый ряд задач, с разными решениями. Я в двух словах объяснить, к сожалению, не смогу.

Sergey95
2011.09.18 14:02:52
#cid5634

Ответить

xexe в том то и дело что инструкций про DHCP провов нету!дык вот и прошу помощи

Sergey95
2011.09.18 14:11:42
#cid5635

Ответить

к примеру
$IP_LOCAL="10.0.0.1" - адрес нашего маршрутизатора в локальной сети.(ок у меня 10.0.0.1)
$IP_INET1="1.1.1.2" - адрес нашего маршрутизатора в сети первого провайдера.(мне писать DHCP? если пишу настройку любова прова вручную меня не пускает)
$IP_INET2="2.2.2.2" - адрес нашего марщрутизатора в сети второго провайдера.(аналогично)
$IF_LOCAL="eth1" - имя интерфейса на локальную сеть(ок тут старый добрый LAN)
$IF_INET1="Beeline" - имя интерфейса на первого провайдера.
$IF_INET2="Sumtel" - имя интерфейса на второго провайдера.
$NET_LOCAL="10.0.0.0/16" - локальная сеть.
$NET_INET1="1.1.1.0/24" - адрес сети в которой гейт нашего первого провайдера.( типа 10.48.58.174?)
$NET_INET2="2.2.2.0/24" - адрес сети в которой гейт нашего второго провайдера.
$NET_SUB1="172.16.0.0/24" - подсеть пользователей на первого провайдера( 10.48.0.0?)
$NET_SUB2="172.16.1.0/24" - подсеть пользователей на второго провайдера
$GW1="1.1.1.1" - гейт первого провайдера.(тут чТО? если автоматом)
$GW2="2.2.2.1" - гейт второго провайдера.

2011.09.19 06:19:17
#cid5664

Ответить

xexe в том то и дело что инструкций про DHCP провов нету!дык вот и прошу помощи

Проблема — не в этом. Сейчас попробую объяснить.
Просто представь, что у тебя оба внешних адреса, равно как и все остальные адреса — статические.

Как при этом должен работать шлюз? Как он будет решать, какие пакеты отправлять первому провайдеру, а какие — второму? Это будет разделение по внутренним айпишникам (например, чётные адреса одному, нечётные другому), или по службам (на основе порта назначения), или должно быть просто распределение нагрузки между провайдерами? Или один провайдер используется постоянно, а второй — резервный, который начинает работать только при обрыве доступа к первому?

Почему при подключении второго провайдера сеть пропадает вообще? Да потому, что шлюз не знает, что ему делать со всем этим хозяйством! С одним провайдером всё понятно: получили пакет из локалки, проверили фильтрами и кинули провайдеру. Но с двумя — как делить трафик? Из предоставленной информации это не ясно, а это — самый важный вопрос, который для шлюза надо разрешить.

То, что оба провайдера раздают адреса по DHCP — всего лишь нюанс, который, по сути, не имеет значения.

Разбей большую задачу на маленькие и решай их отдельно друг от друга, по очереди.
И начни с того, что представь свои адреса статическими, потому что после регистрации интерфейса в DHCP так оно и есть.

Sergey95
2011.09.19 09:31:32
#cid5672

Ответить

ок я понял.помочь сможешь?прост дело в моей топологии сети,ну тут всё описывать не буду ес смож помоч ася378906051 (Sergey040195) skype

2011.09.19 13:48:33
#cid5679

Ответить

ок я понял.помочь сможешь?прост дело в моей топологии сети,ну тут всё описывать не буду ес смож помоч ася378906051 (Sergey040195) skype

Друг, без обид.
Ты думаешь, мне больше нечем заняться?

Sergey95
2011.09.19 20:22:01
#cid5687

Ответить

я сказал если сможешь)_)

2011.09.19 21:02:35
#cid5690

Ответить

я сказал если сможешь)_)

Обрати внимание:

Это целый ряд задач, с разными решениями. Я в двух словах объяснить, к сожалению, не смогу.

Цитата из моего первого ответа.

Sergey95
2011.09.19 23:25:21
#cid5695

Ответить

"ряд задач" у меня это балансировка нагрузки на инет для внутрилокалки + раскидывание портов с VPNа на остальные сервы воуля!

iksigrikov
2011.10.16 14:10:05
#cid6630

Ответить

Спасибо за понятные разъяснения =)

Михаил
2011.10.16 20:41:46
#cid6637

Ответить

Огромное спасибо! С ходу все заработало! Все толково и понятно! А вот теперь можно попытаться и родные инструкции почитать

Andrey
2011.11.03 11:53:41
#cid7357

Ответить

А вот интересно, если в локальной сети стоят два веб сервевра. Один на Linux а второй на Windows Asp. Как тогда к ним настроить проброс?
Например, ввел www.local-linux.com - попал на веб сервер Linux, а ввел www.local-windows asp.com попал на windows Asp

2011.11.04 02:15:26
#cid7392

Ответить

А вот интересно, если в локальной сети стоят два веб сервевра. Один на Linux а второй на Windows Asp. Как тогда к ним настроить проброс?
Например, ввел www.local-linux.com - попал на веб сервер Linux, а ввел www.local-windows asp.com попал на windows Asp

Вариант 1: повесить сайты на разные внешние айпишники. И запросы к 80 порту для разных внешних адресов перебрасывать на разные внутренние.

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

Вариант 2: поставить на шлюз веб-сервер. Или что-нибудь другое, что сможет слушать 80 порт, читать HTTP-заголовки и на основе них делать одну из следующих вещей:
- перенаправлять запросы (например, деля их по разным портам — 81 и 82, после чего их можно будет обработать iptables)
- выдавать страницы самостоятельно, опрашивая внутренние веб-сервера.

Первый вариант полюбому лучше.

ermak
2011.11.18 11:18:22
#cid8218

Ответить

Подскажите по этой схеме проброс OPENVPN трафика будет работать верно?
iptables -t nat -A PREROUTING -d $EXT_IP -p tcp -m tcp --dport $FAKE_PORT -j DNAT --to-destination $LAN_IP:$SRV_PORT
iptables -t nat -A POSTROUTING -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j SNAT --to-source $INT_IP
iptables -t nat -A OUTPUT -d $EXT_IP -p tcp -m tcp --dport $SRV_PORT -j DNAT --to-destination $LAN_IP
iptables -I FORWARD 1 -i $EXT_IF -o $INT_IF -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j ACCEPT
Для проброса использую порт OPENVPN 5001. Но OPENVPN не подключается. Грешу на две вещи, на ключ и на iptables. Вопрос задаю, что бы исключить один из вариантов. По логам видно что проброс хотя бы доходит до сервера которые наодится за nat, а уходит ли обратно, не понятно.
По крайней мере по этой же схеме чудесно пробросил ssh за nat

2011.11.18 12:32:40
#cid8222

Ответить

Подскажите по этой схеме проброс OPENVPN трафика будет работать верно?

iptables работает с пакетами, а не с данными в нём.
Я в том смысле, что ему всё равно что это за пакет и кому он предназначен. HTTP, FTP, OPENVPN — без разницы.

Для проброса использую порт OPENVPN 5001.

http://port.it-simple.ru/?search=vpn

Грешу на две вещи, на ключ и на iptables. Вопрос задаю, что бы исключить один из вариантов. По логам видно что проброс хотя бы доходит до сервера которые наодится за nat, а уходит ли обратно, не понятно.
По крайней мере по этой же схеме чудесно пробросил ssh за nat

Надо убедиться, что ответные пакеты тоже проходят нормально через фильтр FORWARD в iptables.
Чтобы проверить, уходят ли пакеты назад — можно использовать tcpdump на шлюзе.

Вобщем, надо проверять каждый шаг движения пакетов, сверяясь с логами.

ermak
2011.11.18 16:18:14
#cid8236

Ответить

OPEN VPN соединился по порту 5001, но почему то сервер выдает такую строку на команду
sudo sockstat | grep 5001
root openvpn 7021 udp4 *:5001 *:* CLOSED
При этом от клиента пинги идут на внутренний ip OPENVPN сервера, на другие компьютеры той же подсети что и OPENVPN сервер пинги не идут.Так же пинги идут в обеих направлениях и от сервера и от клиента на их виртуальные IP,т.е они пингуются взаимно.
Как думаете, проблема в маршрутизации?
Если OPENVPN соединился(так как порт теперь для него открыт),логично - ковырять iptables больше не нужно?

2011.11.18 17:22:56
#cid8237

Ответить

sudo sockstat | grep 5001
root openvpn 7021 udp4 *:5001 *:* CLOSED

iptables -t nat -A PREROUTING -d $EXT_IP -p tcp -m tcp --dport $FAKE_PORT -j DNAT --to-destination $LAN_IP:$SRV_PORT
iptables -I FORWARD 1 -i $EXT_IF -o $INT_IF -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j ACCEPT

При этом от клиента пинги идут на внутренний ip OPENVPN сервера, на другие компьютеры той же подсети что и OPENVPN сервер пинги не идут.Так же пинги идут в обеих направлениях и от сервера и от клиента на их виртуальные IP,т.е они пингуются взаимно.

Пинг — это ICMP пакет, OPENVPN работает у тебя на UDP, а правила iptables написаны для TCP. Это абсолютно разные протоколы.

Как думаете, проблема в маршрутизации?

Не, точно не в маршрутизации.

ermak
2011.11.18 17:26:11
#cid8238

Ответить

Когда комент писал не изменил tcp на udp. В нат у меня прописан udp.
Значит этим же правилом нужно открыть icmp пакеты на этот порт?

2011.11.18 18:05:04
#cid8239

Ответить

Когда комент писал не изменил tcp на udp. В нат у меня прописан udp.
Значит этим же правилом нужно открыть icmp пакеты на этот порт?

Нет, icmp вообще не нужен.

Надо удостовериться, что при подключении извне пакеты приходят на VPN сервер и после этого копать его настройки.
http://bozza.ru/art-129.html

Да, и убедись, что FORWARD в обратную сторону разрешён! А то мало ли.

ermak
2011.11.21 08:45:23
#cid8348

Ответить

Как раз на VPN сервер пакеты из вне идут, могу даже подключаться к его RDP и SSH порту, а вот в сеть пакеты не идут.
А FORWARD разрешил таким правилом iptables -A FORWARD -p UDP --dport 5001 -j ACCEPT
Грызу мозг, а мысли не идут)

nur
2011.11.23 22:49:24
#cid8502

Ответить

у меня скрипт не заработал, может потому что интерфейс один?
и как вообще быть в этом случае?

2011.11.24 15:33:09
#cid8543

Ответить

у меня скрипт не заработал, может потому что интерфейс один?
и как вообще быть в этом случае?

Для начала неплохо бы понять — что ты вообще хочешь сделать?

egojob
2011.11.30 18:38:30
#cid8900

Ответить

Мучился 2 дня с adsl модемом dlink 2500u. Твоя статья помогла. Спасибо

GMasta
2011.12.20 04:03:30
#cid10724

Ответить

Статья хорошая, но с одним не согласен )
POSTROUTING во внутрь - убивает всякую возможность увидеть реального клиента (или злоумышленника) на внутреннем сервере и нужно только если не верно настроен роуте.. Не говоря уже о более сложных задачах например использования почтовых серверов..
Если кто то побывает у вас.. то после уже концов не найдешь.. В логах будет смотреться что нас взломал наш роутер ;)

2011.12.20 19:38:30
#cid10808

Ответить

#cid10724, GMasta

Статья хорошая, но с одним не согласен )
POSTROUTING во внутрь - убивает всякую возможность увидеть реального клиента (или злоумышленника) на внутреннем сервере и нужно только если не верно настроен роуте.. Не говоря уже о более сложных задачах например использования почтовых серверов..

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

Справедливости ради надо сказать, что лично я POSTROUTING тоже никогда не ставлю — не вижу смысла.
Внутренние службы (локалка-локалка) идут мимо роутера. Внешние (инет-локалка) не нуждаются в этой записи. А общие службы надо располагать в DMZ, так правильнее.

Если кто то побывает у вас.. то после уже концов не найдешь.. В логах будет смотреться что нас взломал наш роутер ;)

Дык в логах сервера оно по любому так будет смотреться. Вне зависимости откуда взломали — изнутри или снаружи (если взламывали через проброшенное соединение). Поэтому надо смотреть логи роутера, в которых пакеты типа "из локалки в локалку" тоже должны быть учтены.

Nite
2012.01.12 13:04:21
#cid12773

Ответить

Нельзя ли расписать правила для случая, когда проброс разрешен не всему интернету, а только определенному внешнему ip адресу (фиксированному)?

2012.01.12 14:12:21
#cid12782

Ответить

#cid12773, Nite

Нельзя ли расписать правила для случая, когда проброс разрешен не всему интернету, а только определенному внешнему ip адресу (фиксированному)?

Для фильтрации пакетов в iptables используется таблица filter. Соответственно, меняем правило фильтрации так, чтобы проходили не все соединения из интернета, а только избранные, с определённого айпи.

Было:

iptables -I FORWARD 1 -i eth0 -o eth1 -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j ACCEPT

Станет:

iptables -I FORWARD 1 -i eth0 -o eth1 -s $SINGLE_IP -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j ACCEPT

где $SINGLE_IP — тот самый внешний айпишник, которому разрешено пользоваться пробросом.

Nite
2012.01.13 16:12:23
#cid12899

Ответить

Спасибо :) Полезная инфа.

Ivan
2012.03.23 17:19:19
#cid19469

Ответить

Огромное спасибо!

ATAMAH
2012.08.07 18:03:42
#cid36640

Ответить

А как пробросить трафик из одной сетевой карты в виртуальную, на одном компе?
поясню:

выход в инет идет через ADSL-роутер Sagemcom F@ST 2804, т.е. pppoe - IP-192.168.1.1
который подключен к eth0 - IP-192.168.1.44
Интернет работает, все нормально!
Теперь, на этом же компе поднимается тоннель при помощи OpenVPN,
IP(server) - 192.168.111.1
IP(client) - 192.168.111.2 интерфейс tap0
в локалку организации 192.168.10.0/24, в которой на 192.168.10.234 сидит asterisk (VoIP).
Настроенный SIP клиент (софтфон) соединяется с asterisk и работает на "ура".
Но я отказываюсь от софтфона в пользу аналогового телефона через VoIP шлюз Hanlong Unicorn 3001 .
Как сие чудо настроить на работу с удаленным OpenVPN, VPN-то на компе поднимается и через tap0 интерфейс идет?
Я воткнул вторую сетевую карточку eth1 c IP-192.168.2.1, шлюзу на WAN-интерфейс дал IP-192.168.2.123 и воткнул в эту карточку, причем SIP сервер в настройках у него прописан как 192.168.10.234. Пробую завернуть в tap0:

iptables -t nat -I POSTROUTING 1 -o eth1 -s 192.168.2.1 -j SNAT --to-source 192.168.111.2 и так
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 192.168.111.2

результат один:
#ping 192.168.10.234 -I eth1

PING 192.168.10.234 (192.168.10.234) from 192.168.2.1 eth1: 56(84) bytes of data.
From 192.168.111.2 icmpseq=2 Destination Host Unreachable
From 192.168.111.2 icmpseq=3 Destination Host Unreachable

пожалуста, помогите правильно завернуть, или настроить...

2012.08.07 21:09:18
#cid36657

Ответить

#cid36640, ATAMAH

#ping 192.168.10.234 -I eth1

А зачем пинговать через интерфейс eth1 подсеть, которая находится на другом конце интерфейса tap0, который работает через ppp0, который, в свою очередь, работает поверх eth0?!

Насколько я понимаю, компьютер с двумя карточками будет шлюзом между Hanlong Unicorn 3001 и VPN-ом, поэтому необходимо настроить шлюзование с eth1 на tap0:

-A POSTROUTING -s 192.168.2.0/24 -o tap0 -j SNAT --to-source 192.168.111.2

и разрешить FORWARD пакетов eth1-tap0 в таблице filter.

Ну и включить ip_forward не забываем.

echo 1 > /proc/sys/net/ipv4/ip_forward

Чтобы включалось автоматически — в файл /etc/sysctl.conf добавляем строку "net.ipv4.ip_forward=1".

ATAMAH
2012.08.08 12:07:09
#cid36725

Ответить

весь мозг сломал - не регистрируется :(

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -A FORWARD -d 192.168.2.0/24 -j ACCEPT
# iptables -A FORWARD -d 192.168.10.0/24 -j ACCEPT
# iptables -A FORWARD -d 192.168.1111.0/24 -j ACCEPT
# iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o tap0 -j SNAT --to-source 192.168.111.2

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.2.0/24
ACCEPT all -- anywhere 192.168.10.0/24
ACCEPT all -- anywhere 192.168.111.0/24
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

# iptables -t nat -n -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

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
SNAT all -- 192.168.2.0/24 0.0.0.0/0 to:192.168.111.2

# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
11:49:18.443766 IP 192.168.2.123.sip > 192.168.10.234.sip: SIP, length: 536
11:49:18.481988 IP 192.168.2.123.sip > 192.168.10.234.sip: SIP, length: 4
11:49:19.116862 IP 192.168.2.123.sip > 192.168.10.234.sip: SIP, length: 536
11:49:20.123762 IP 192.168.2.123.sip > 192.168.10.234.sip: SIP, length: 536

# netwatch -e eth1
HOST (PKTS) X R HOST (PKTS) X R
192.168.2.123 53 0 > 192.168.10.234 0 45

== Hanlong Unicorn 3001 ==
Статус подключения
Порт Линия Регистрация DND
FXS On Hook Not Registered No

2012.08.08 16:22:03
#cid36765

Ответить

#cid36725, ATAMAH

весь мозг сломал - не регистрируется :(

Извиняй, я не могу посмотреть на месте что и как, поэтому все мои советы носят сугубо теоретический характер.

# tcpdump -i eth1

На eth1 поступают правильные пакеты, но это и так очевидно.
Тебе нужно проверить, уходят ли они куда нужно, т.е. на tap0 интерфейс.

ATAMAH
2012.08.08 18:25:41
#cid36769

Ответить

АбАлдеть....
после ребута всего и вся, снова дал:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -A FORWARD -d 192.168.2.0/24 -j ACCEPT
# iptables -A FORWARD -d 192.168.10.0/24 -j ACCEPT
# iptables -A FORWARD -d 192.168.1111.0/24 -j ACCEPT
# iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o tap0 -j SNAT --to-source 192.168.111.2

и усе зафурыкало :)
огроменное тебе спасибо!!!!!
куда пиво нести? ;)

ATAMAH
2012.08.09 10:17:23
#cid36829

Ответить

рано радовался :(
работает только в одну сторону, т.е. я могу звонить, а мне нет...
АТС говорит:
-- Registered SIP '123' at 192.168.2.123:5060

получается, когда мне звонят атс шлет звонки на 192.168.2.123, а такой подсети в локалке нету..., как быть?

2012.08.09 15:19:50
#cid36856

Ответить

#cid36829, ATAMAH

рано радовался :(
работает только в одну сторону, т.е. я могу звонить, а мне нет...

Ну дык, правильно )
Шлюз получился односторонним: eth1 (тел.) → tap0 (VPN). А из tap0 в eth1 пакеты идут только в пределах сеанса связи.
Чтобы исправить ситуацию, надо организовать и соединение tap0 → eth1.

Один из способов:
1. Сделать, чтобы АТС посылала входящие звонки на 192.168.111.2:5060
2. Пробросить порт 5060 с 192.168.111.2 на 192.168.2.123.

А за пиво потом договоримся )

ATAMAH
2012.08.09 19:50:34
#cid36887

Ответить

интересная фигня получается на АТС.
при регистрации софтфона, когда все работает:

-- Registered SIP '123' at 192.168.1.44:5060
-- Registered SIP '123' at 192.168.10.250:1024

1.44 - мой eth0
10.250 - шлюз организации, где vpn поднят,

а при регистрации через аналоговый шлюз, когда в одну сторону:

-- Registered SIP '123' at 192.168.2.123:5060

не пойму как и где правила писать :(

2012.08.09 21:42:41
#cid36897

Ответить

#cid36887, ATAMAH

не пойму как и где правила писать :(

Правила не помогут до тех пор, пока АТС будет считать, что SIP зарегистрирован по левому (для неё) адресу.
Есть смысл смотреть настройки аналогового шлюза.
Походу, он для обратного соединения почему-то даёт АТС-ке адрес 192.168.2.123, который находится за NAT-ом на твоей машине и о котором АТС-ка вообще не знает и не должна знать.

Можно попробовать вообще изменить всю схему подключения, а то она какой-то диковатой получилась.
Например, можно соединить tap0 и eth1 мостом.

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

ATAMAH
2012.08.11 19:37:15
#cid37109

Ответить

йё-хо! :)
с мостом получилось как надо!
Спасибо!

ты, всетаки, про пиво подумай ;)

Boba
2012.08.20 00:22:23
#cid38112

Ответить

Спасибо большое !!!
Из 18 статей твоя первая, которая заработала. Очень ценные пояснения. Пиши, пожалуйста еще!

2012.08.20 00:28:44
#cid38113

Ответить

#cid38112, Boba

Спасибо большое !!!

Пожалуйста )

Из 18 статей твоя первая, которая заработала. Очень ценные пояснения. Пиши, пожалуйста еще!

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

2012.08.20 00:32:06
#cid38114

Ответить

#cid37109, ATAMAH

йё-хо! :)
с мостом получилось как надо!
Спасибо!

Пожалуйста )

ты, всетаки, про пиво подумай ;)

Налива-а-ай!!! )

терм
2012.08.28 19:57:45
#cid39033

Ответить

автору респект)

Илья Семенов
2012.09.06 00:47:13
#cid40140

Ответить

Есть два способа избежать подобной ситуации.
Первый - чётко разграничивать обращения к серверу изнутри и извне.
Создать в локальном DNS-сервере A-запись для webname.dom, указывающую на 192.168.0.22.
Второй - с помощью того же iptables заменить обратный адрес пакета.

Боже, до чего люди любят прикручивать системы костылей и подпорок вместо того, чтобы немного подумать головой.

Вся "проблема" решается так:

1) в правиле для DNAT исключить запросы с внутреннего интерфейса:
iptables -t nat -A PREROUTING ! -i eth1 --dst $EXT_IP -p tcp --dport $SRV_PORT -j DNAT --to-destination $LAN_IP

2) в таблицу роутинга на шлюзе добавить:
ip route add $EXT_IP via $LAN_IP

3) на сервере добавить $EXT_IP как алиас к интерфейсу, на котором висит $LAN_IP

Всё! Клиенты изнутри сети теперь могут обращаться непосредственно к $EXT_IP, шлюз пробросит пакеты на нужный сервер, всё будет работать корректно. Более того, если на шлюзе и на клиенты достаточно умные ОС, шлюз может выслать клиенту ICMP redirect, а клиентская ОС может на лету перестроить свою таблицу роутинга и посылать пакеты на сервер в обход шлюза.

2012.09.06 01:09:43
#cid40143

Ответить

#cid40140, Илья Семенов

Вся "проблема" решается так:

За вариант решения — спасибо!
Но чем оно качественно лучше описанных?

По сравнению со стандартным решением (второй способ) — добавляются "лишние" алиас и маршрут.

Илья Семенов
2012.09.06 17:04:36
#cid40232

Ответить

#cid40143,

За вариант решения — спасибо!
Но чем оно качественно лучше описанных?

1) в логах веб-сервера остаются настоящие внутрение IP-адреса клиентов, а при способе с DNAT - всегда внутренний IP-адрес шлюза.
2) если клиент динамически перестраивает роутинг, то трафик не гоняется через шлюз (правда, не всегда это работает)

Но, я, кстати, был не прав. Мой способ работает, когда в наличии есть несколько внешних IP, и нужно целиком пробросить какой-то IP через шлюз на внутренний сервер. Если внешний IP только один, а пробрасывать нужно отдельные порты, то просто через ip route это не решается.

2012.09.06 17:56:29
#cid40235

Ответить

#cid40232, Илья Семенов

в логах веб-сервера остаются настоящие внутрение IP-адреса клиентов, а при способе с DNAT - всегда внутренний IP-адрес шлюза.

То же самое делает первый способ (который, кстати, я и предпочитаю). Трафик чётко разграничен, во внутренних соединениях шлюз не участвует, корректирующей записи в iptables (того самого костыля) нет вообще. Всё предельно надёжно, ничего лишнего.

Но, я, кстати, был не прав. Мой способ работает, когда в наличии есть несколько внешних IP, и нужно целиком пробросить какой-то IP через шлюз на внутренний сервер. Если внешний IP только один, а пробрасывать нужно отдельные порты, то просто через ip route это не решается.

Не, ну как вариант решения какой-то частной проблемы — имеет право на существование. С определённой доработкой.
Но, честно говоря, после такого яркого вступления про костыли и подпорки я ожидал чего-то более революционного. ;)

Илья Семенов
2012.09.06 21:30:15
#cid40263

Ответить

#cid40235,

Всё предельно надёжно, ничего лишнего.

Ничего лишнего?? Каждую зону хранить на DNS-сервере в двух экземплярах и постоянно синхронизировать в этих копиях изменения - это ничего лишнего? А если DNS-сервера некоторых доменов вообще где-то снаружи под внешним управлением??

Я почему оставил комментарий - только вчера выбросил из DNS весь split horizon, надоело поддерживать этот мрак. Одна запись в таблицу роутинга на шлюзе, один алиас при инициализации интерфейса на веб-сервере - всё, все счастливы и довольны.

Илья Семенов
2012.09.06 21:37:40
#cid40266

Ответить

Да, ещё со split horizon есть (была?) проблема с кешированием DNS-записей на ноутах. Приехал на работу - открыл сайт, он отрезолвился во внутренний IP. Закрыл ноут, приехал домой, открыл ноут - продолжить работать с сайтом просто так нельзя. Правда, почему-то я с этой проблемой перестал сталкиваться последнее время: возможно, с какой-то версии OS X при смене точки доступа стала автоматически очищать кеш DNS. Как с этим в других ОС - не знаю.

2012.09.06 22:50:51
#cid40280

Ответить

#cid40263, Илья Семенов

Ничего лишнего?? Каждую зону хранить на DNS-сервере в двух экземплярах и постоянно синхронизировать в этих копиях изменения - это ничего лишнего? А если DNS-сервера некоторых доменов вообще где-то снаружи под внешним управлением??

Как бы, изначально в заметке говорится именно о локальном DNS, который не виден снаружи. И лично я твёрдо убеждён, что такой DNS должен быть в любой сети в обязательном порядке, хотя бы ради кэширования запросов. А если DNS-ов несколько, то синхронизация между ними должна происходить в автоматическом режиме.

Я почему оставил комментарий - только вчера выбросил из DNS весь split horizon, надоело поддерживать этот мрак. Одна запись в таблицу роутинга на шлюзе, один алиас при инициализации интерфейса на веб-сервере - всё, все счастливы и довольны.

Честно говоря, я не понимаю, в чём проблема. Ну не вижу я связи между справочником DNS и проблемами маршрутизации в сети.

#cid40266, Илья Семенов

Да, ещё со split horizon есть (была?) проблема с кешированием DNS-записей на ноутах.

Ну, это — опять всё в кучу...

Как с этим в других ОС - не знаю.

:) Можно почитать тут: Очистка кэшей сетевых адресов

Ямыч
2012.09.09 21:59:59
#cid40607

Ответить

Доброго времени суток!
После прочтения кучи статей и мануалов по iptables в голове каша... а хочется результата уже сейчас, поэтому прошу совета.
Задача: с домашнего компа получить доступ к внутренним ресурсам корпоративной сети (1с, шара) — 192.168.0.0/24
Дано: маршрутизатор (192.168.1.1) на openwrt + домашний комп (192.168.1.2).
На маршрутизаторе поставил и настроил openvpn — корпоративные ресурсы пингуются. А вот с локального компа нет.
Понимаю, что это делается в таблице nat с помощью FORWARD, но четкой картинки к сожалению нет... (

2012.09.10 03:42:53
#cid40634

Ответить

#cid40607, Ямыч

Доброго времени суток!
После прочтения кучи статей и мануалов по iptables в голове каша... а хочется результата уже сейчас, поэтому прошу совета.
Задача: с домашнего компа получить доступ к внутренним ресурсам корпоративной сети (1с, шара) — 192.168.0.0/24
Дано: маршрутизатор (192.168.1.1) на openwrt + домашний комп (192.168.1.2).
На маршрутизаторе поставил и настроил openvpn — корпоративные ресурсы пингуются. А вот с локального компа нет.
Понимаю, что это делается в таблице nat с помощью FORWARD, но четкой картинки к сожалению нет... (

iptables настраивается на корпоративном шлюзе, для входящих соединений. Для исходящих соединений на домашнем роутере его настраивать не надо. Вернее, надо, но это совсем-совсем-совсем другое.

adik
2012.09.23 16:02:40
#cid42105

Ответить

Доброго времени суток. Помогите пожалуйста решить проблемку.
Суть такова, имеется два пк на деби,шлюз и сервер кс соединены через свич,интернет поднят - l2tp - раздается, полет нормальный
Стоит dhcp и dnsmasq, вроде все настроенО)
Нужно вывести сервер в интернет, тоесть открыть порты, сделать проброс там...
Пытался по этой статейке - но чет не получается. сервер не видно

2012.09.23 19:39:48
#cid42116

Ответить

#cid42105, adik

Шлюз соединён с интернетом через определённый интерфейс.

На сервере КС открыт определённый порт, или набор портов.

На шлюзе необходимо пробросить соединения, входящие на определённый интерфейс и на нужные порты. Пробросить до сервера КС.
Эта заметка (внимание!) как раз и рассказывает о том, как это сделать.

l2tp, dhcp, dnsmasq и модель свича — не имеют абсолютно никакого значения.

Имеют значение: 1) название внешнего интерфейса на шлюзе; 2) внешний IP шлюза; 3) внутренний IP сервера; 4) Набор портов, которые надо пробросить.

adik
2012.09.23 23:34:28
#cid42139

Ответить

eth0 - сеть внешняя
eth1 - сеть внутреняя
ppp0 - интернет

Внешние адреса 10.136.xx.xx и 95.31.xx.xx
Шлюз 192.168.0.100
Адрес сервера 192.168.0.105
Порты 27010,27015,27016
Прошу помощи)

2012.09.24 00:29:19
#cid42142

Ответить

#cid42139, adik

iptables -t nat -A PREROUTING --dst 95.31.xx.xx -p tcp --dport 27010 -j DNAT --to-destination 192.168.0.105
iptables -t nat -A PREROUTING --dst 95.31.xx.xx -p tcp --dport 27015:27016 -j DNAT --to-destination 192.168.0.105
iptables -t nat -A PREROUTING --dst 10.136.xx.xx -p tcp --dport 27010 -j DNAT --to-destination 192.168.0.105
iptables -t nat -A PREROUTING --dst 10.136.xx.xx -p tcp --dport 27015:27016 -j DNAT --to-destination 192.168.0.105
iptables -I FORWARD 1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -o eth1 -d 192.168.0.105 -p tcp -m tcp --dport 27010 -j ACCEPT
iptables -I FORWARD 3 -o eth1 -d 192.168.0.105 -p tcp -m tcp --dport 27015:27016 -j ACCEPT

Подразумевается, что остальные правила в iptables изначально настроены корректно. Порты проброшены для подключений из интернета и из внешней локалки.
Первое правило в FORWARD написано для наглядности: показать, что это правило должно быть первым.

adik
2012.09.24 08:31:10
#cid42171

Ответить

вот я делал что то похожее.. но даже с этими правилами сервер не доступен из интернета и внешней сети :( в этом то и проюлемма. сервер доступен тока в локальной сети ( моей )

imen
2012.09.24 09:23:51
#cid42174

Ответить

но даже с этими правилами сервер не доступен из интернета и внешней сети

Стандартный вопрос: что на этот счёт говорит журнал пакетного фильтра (на этапе тестирования категорически показана запись в журнал ВСЕХ отвергаемых, а иногда и некоторых пропускаемых, пакетов)?

adik
2012.09.24 19:24:59
#cid42215

Ответить

#cid42174, imen

Стандартный вопрос: что на этот счёт говорит журнал пакетного фильтра (на этапе тестирования категорически показана запись в журнал ВСЕХ отвергаемых, а иногда и некоторых пропускаемых, пакетов)?

Прошу прощения. но я не так давно начал юзать деби. да и вообще ось линевскую...
Как или где посмотреть?))

2012.09.24 19:58:33
#cid42218

Ответить

#cid42215, adik

Прошу прощения. но я не так давно начал юзать деби. да и вообще ось линевскую...
Как или где посмотреть?))

iptables -I FORWARD 1 -j LOG

Лог лежит по адресу /var/log/syslog. Прочитать можно с помощью утилит dmesg, syslogd и др.
И будь внимателен: лог будет расти ОЧЕНЬ быстро. Включи, потестируй и отключи.

Также не помешает проследить путь внешних пакетов через шлюз утилитой tcpdump (наблюдать каждый интерфейс по отдельности).

Но перед всем этим действом — убедись, что:
1) Приведённых портов достаточно для функционирования сервера КС.
2) Другие правила iptables не конфликтуют с твоим пробросом.

imen
2012.09.25 13:09:27
#cid42273

Ответить

Прошу прощения. но я не так давно начал юзать деби. да и вообще ось линевскую...
Как или где посмотреть?))

Сначала настроить.
Например http://ru.gentoo-wiki.com/wiki/Пакетный_фильтр_Linux (настройка журналирования пакетного фильтра описана в разделе 3.2).
Писать в журнал последовательно по шагам (чтобы определеиться начиная с которого проброс перестаёт работать).
Ну и отказы (кроме разве что стандартного флуда альтернативной ОС) полезно писать в журнал ВСЕГДА.

imen
2012.09.25 13:23:11
#cid42274

Ответить

Лог лежит по адресу /var/log/syslog.

Интересный тезис.
Сервер с ненастроенной подсистемой журналирования суть нонсенс.
Начиная понимать причину популярности FreeBSD...

Прочитать можно с помощью утилит dmesg, syslogd и др.

dmesg - сообщения ядра.
syslogd - собственно демон, пишущий централизованный журнал (но достаточно популярна ситуация, когда приложение пишёт свой журнал самостоятельно, в локальный файл).

Для _чтения_ же (и поиска) журналов есть более подходящие утилиты: more/[z,bz,]less/[z,bz,]grep.

2012.09.25 16:01:07
#cid42290

Ответить

#cid42274, imen

dmesg и syslogd рекомендованы в мане iptables.

А насчёт пути к системному журналу — надо понимать: adik настраивает iptables, но при этом не может отследить путь сетевого пакета. С огромной вероятностью логи у него лежат в /var/log/syslog.

imen
2012.09.26 17:29:12
#cid42375

Ответить

dmesg и syslogd рекомендованы в мане iptables.

net-firewall/iptables-1.4.13
В тексте стрнаицы руководства упоминание syslogd не обнаружено.
По сути: dmesg - утилита для чтения сообщений ядра.
syslogd - стандартный демон. Если кто-то предпочитает иное решение, то автоматически предполагается, что он знает _почему_ это делает и как настраивать выбранный им инструмент.

2012.09.26 17:46:15
#cid42382

Ответить

#cid42375, imen

В тексте стрнаицы руководства упоминание syslogd не обнаружено.

Первая ссылка в конце заметки:
Руководство по iptables (Iptables Tutorial 1.1.19)

«LOG -- действие, которое служит для журналирования отдельных пакетов и событий. В журнал могут заноситься заголовки IP пакетов и другая интересующая вас информация. Информация из журнала может быть затем прочитана с помощью dmesg или syslogd либо с помощью других программ.»

imen
2012.09.27 15:42:37
#cid42482

Ответить

#cid42382,

Первая ссылка в конце заметки:
Руководство по iptables (Iptables Tutorial 1.1.19)

Особенности (и следствие) проблемы перевода.
syslogd упомянут как стандартный (generic) демон.
Если используется что-то отличное - см. замечание выше.

vel
2012.10.03 17:18:04
#cid43051

Ответить

помогите написать правило для зеркалирования трафика на другой порт

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

2012.10.03 18:23:03
#cid43057

Ответить

#cid43051, vel

помогите написать правило для зеркалирования трафика на другой порт

Для зеркалирования трафика — по какому порту?

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

Пример для веб-трафика (порт 80):

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080

При этом на порту 8080 должен сидеть прокси, который обработает пакет и отправит его дальше.
http://www.opennet.ru/docs/RUS/iptables/#REDIRECTTARGET

Питер
2012.10.27 12:49:09
#cid45889

Ответить

добрый день. в линуксе совсем не давно закономерно возникают периодически вопросы на этот раз по iptables: имеется - подключение по wifi,роутер,192.168.1.1 локалка тобишь, далее за ним ряд адресов провайдера (показываю по выводу nmapа) 10.198.230.97
2 7.80 ms 10.198.230.97
3 3.80 ms 10.255.255.45
4 4.20 ms 172.22.78.17
5 6.17 ms 172.22.78.26
6 3.41 ms 178.130.0.22
7 3.04 ms 178.130.0.89 восьмым номером тут не указанным идет внешний адрес прова. Вот кажется полная картина!
возможно ли пробросить себя до внешнего интеренета и если да как это сделать . буду крайне признателен за любую помощь, так как поиск "незнаю чего" ни чего не дает.

msc
2012.11.27 20:37:25
#cid49611

Ответить

Спасибо все работает. только как сделать что бы лановская машина определяла ip клиента
а то определяет адрес шлюза если люди заходят в твою сеть;((((((

2012.11.27 20:56:31
#cid49612

Ответить

#cid49611, msc

Спасибо все работает. только как сделать что бы лановская машина определяла ip клиента
а то определяет адрес шлюза если люди заходят в твою сеть;((((((

Никак, таков механизм NAT.

Чтобы определять ip клиента надо либо сопоставлять логи сервера с логами шлюза, либо менять структуру доступа к серверу.

msc
2012.11.27 21:59:47
#cid49616

Ответить

хорошо как менять? куда капать? что делать?

msc
2012.11.27 22:12:17
#cid49618

Ответить

что скажете по поводу pfsense? он подойдет?

2012.11.27 23:08:03
#cid49624

Ответить

#cid49616, msc

хорошо как менять? куда капать? что делать?

Либо обеспечить доступ к серверу извне, без NAT (выделить айпишник / поставить на шлюз / сделать прокси на шлюзе), либо сопоставлять логи сервера и шлюза.

К чему доступ-то делаем? Что за сервер?

#cid49618, msc

что скажете по поводу pfsense? он подойдет?

Не знаю. Вряд ли.

Гость
2012.12.05 15:28:00
#cid50148

Ответить

Добрый день.

Прочел описание (отлично кстати изложенное), добавил правила скриптом, но ftp доступ открыть (из внешней сети к локальному хранилищу) не удалось.

1.2.3.4 - внешний IP шлюза
192.168.0.1 - локальный IP шлюза
10021 - подставной порт шлюза
192.168.0.203 - IP файлохранилища
20,21 - реальный порт файлохранилища
eth0.533 - внешний интерфейс шлюза
eth3 - внутренний интерфейс шлюза

Привожу вырезки из iptables:
-A PREROUTING -d 1.2.3.4/32 -i eth0.533 -p tcp -m tcp --dport 10021 -j DNAT --to-destination 192.168.0.203:20
-A PREROUTING -d 1.2.3.4/32 -i eth0.533 -p tcp -m tcp --dport 10021 -j DNAT --to-destination 192.168.0.203:21
-A PREROUTING -d 1.2.3.4/32 -p tcp -m tcp --dport 10021 -j DNAT --to-destination 192.168.0.203:20
-A PREROUTING -d 1.2.3.4/32 -p tcp -m tcp --dport 10021 -j DNAT --to-destination 192.168.0.203:21
-A POSTROUTING -d 192.168.0.203/32 -p tcp -m tcp --dport 20 -j SNAT --to-source 192.168.0.1
-A POSTROUTING -d 192.168.0.203/32 -p tcp -m tcp --dport 21 -j SNAT --to-source 192.168.0.1
-A OUTPUT -d 1.2.3.4/32 -p tcp -m tcp --dport 20 -j DNAT --to-destination 192.168.0.203
-A OUTPUT -d 1.2.3.4/32 -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.0.203
*filter
-A INPUT -p icmp -j ACCEPT
-A INPUT -i eth0.533 -p tcp -m tcp --dport 21 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0.533 -p tcp -m tcp --dport 20 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.0.203/32 -i eth0.533 -o eth3 -p tcp -m tcp --dport 21 -j ACCEPT
-A FORWARD -d 192.168.0.203/32 -i eth0.533 -o eth3 -p tcp -m tcp --dport 10021 -j ACCEPT
-A FORWARD -d 192.168.0.203/32 -i eth0.533 -o eth3 -p tcp -m tcp --dport 20 -j ACCEPT

С такими настройками доступ возможен только из локальной сети, во внешнюю сеть, а обратно никак. Подскажите, что можно подправить?

Андрей
2012.12.05 16:50:31
#cid50152

Ответить

Блин, подключение к файлохранилищу из из локальной сети окончательно пропало, заподозрил подвох.., сходил на верх, лично посмотреть, что с ним. Оказалось полчаса как полку с ним уронили... не рассчитали нагрузку. Но ничего, воткнул питание, зафырчало. Обошлось без потерь.

Проверил доступ. Из внешней сети по ftp доступ есть, но только в пассивном режиме:
227 Entering Passive Mode (192,168,0,203,195,80).

Хотя внутри локальной сети, работает и в активном. Настройки те же, что писал выше.

Username
2012.12.05 18:29:49
#cid50162

Ответить

Толково, просто и по делу. Автор молодец, спасибо! Единственное адрес 192.168.0.333 изменить бы в тексте, а то 333 как то глаз режет своей нереальностью =)

2012.12.06 14:10:38
#cid50222

Ответить

#cid50162, Username

Толково, просто и по делу. Автор молодец, спасибо! Единственное адрес 192.168.0.333 изменить бы в тексте, а то 333 как то глаз режет своей нереальностью =)

А-а-а! Камрад! Как я долго тебя ждал!

Три года заметке, сто комментариев. В остальных заметках, где нужны примеры адресов, 333-й тоже фигурирует.
Ты — первый, кто обратил внимание.

Написал специально, ради смеха. Так веселее читать. Менять не буду :)

2012.12.06 14:39:43
#cid50225

Ответить

#cid50152, Андрей

Хотя внутри локальной сети, работает и в активном. Настройки те же, что писал выше.

Надо разбираться в особеностях работы FTP, с вмысле как происходит подключение в активном и пассивном режимах, пошагово. И как каждый шаг согласуется с правилами iptables.

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

Андрей
2012.12.10 17:29:08
#cid50485

Ответить

Как разберусь — вывешу отдельную заметку, а сюда добавлю ссылку.

Спасибо, буду ждать, ибо неделю бьюсь, никак не дается чертяка..

Андрей
2012.12.11 16:58:07
#cid50569

Ответить

Сейчас, при коннекте с внешки работает так:

# ftp -n 1.2.3.4 10021
Connected to 1.2.3.4 (1.2.3.4).
220 (vsFTPd 2.0.7)
ftp> quote USER user
331 Please specify the password.
ftp> quote PASS ххх
230 Login successful.
ftp> ls
227 Entering Passive Mode (192,168,0,203,195,81).

# ftp -A -n 1.2.3.4 10021
Connected to 1.2.3.4 (1.2.3.4).
220 (vsFTPd 2.0.7)
ftp> quote USER user
331 Please specify the password.
ftp> quote PASS ххх
230 Login successful.
ftp> ls
500 Illegal PORT command.
ftp: bind: Address already in use

Shum
2013.02.22 00:52:06
#cid55712

Ответить

Спасибо огромное !!!

xman
2013.03.01 23:12:11
#cid56226

Ответить

Полезная заметка, но есть важное замечание.
Если для локальных клиентов организуется доступ к веб через шлюз (т.е. с применением SNAT), то в правиле для POSTROUTING/filter необходимо указать критерий -s 192.168.0.0/24, тем самым ограничив действие правила только для локальной сети, иначе преобразованию SNAT подвергнутся пакеты от внешних клиентов (из Интернет) и в логе веб-сервера будет регистрироваться адрес шлюза, а не ip клиента из Интернет.

CODer
2013.03.02 23:26:54
#cid56272

Ответить

#cid42142
Помогите пожалуйста разобраться в проблеме:
существует игровой сервер А, в локальной сети №1 доступный по ип 555.555.555.555:5555, необходимо провести доступ к этому серверу по ип 444.444.444.444:5555 из локальной сети №2 через другой сервер Б у которого имеется доступ к обоим локальным сетям, то есть пользователи имеющие локальную сеть №2 заходя на сервер Б подключались на сервер А. Как бы это все правильно написать в правило?:)

2013.03.07 23:14:48
#cid56632

Ответить

#cid56272, CODer

444.444.444.444 — это IP сервера Б, под которым он виден из локальной сети №2?

iptables -t nat -A PREROUTING --dst 444.444.444.444 -p tcp --dport 5555 -j DNAT --to-destination 555.555.555.555

Этого должно быть достаточно.
Подключение из локалки №2 идёт под другим адресом, поэтому правило POSTROUTING не нужно. По этой же причине не необходимо правило OUTPUT, ведь сервер Б видит сервер А напрямую и не будет подключаться к нему по своему адресу для сети №2.

Правило FORWARD — надо смотреть, хз. Зависит от того, как реализован доступ сервера Б к локалкам.

2013.03.07 23:46:29
#cid56633

Ответить

#cid56226, xman

Если для локальных клиентов организуется доступ к веб через шлюз (т.е. с применением SNAT), то в правиле для POSTROUTING/filter необходимо указать критерий -s 192.168.0.0/24, тем самым ограничив действие правила только для локальной сети, иначе преобразованию SNAT подвергнутся пакеты от внешних клиентов (из Интернет) и в логе веб-сервера будет регистрироваться адрес шлюза, а не ip клиента из Интернет.

Согласный.

Ровно по этой же причине предпочитаю делать доступ к внутренним веб-серверам через локальные DNS, а не через iptables. Тогда необходимость в правиле POSTROUTING пропадает. Собственно, как и проблема в целом: в логах будут правильно отображаться как внутренние, так и внешние адреса.

Думаю, как добавить информацию в основную заметку, не загромождая её.

CODer
2013.03.09 18:26:33
#cid56793

Ответить

#cid56632,

#cid56272, CODer

444.444.444.444 — это IP сервера Б, под которым он виден из локальной сети №2?

iptables -t nat -A PREROUTING --dst 444.444.444.444 -p tcp --dport 5555 -j DNAT --to-destination 555.555.555.555

Этого должно быть достаточно.
Подключение из локалки №2 идёт под другим адресом, поэтому правило POSTROUTING не нужно. По этой же причине не необходимо правило OUTPUT, ведь сервер Б видит сервер А напрямую и не будет подключаться к нему по своему адресу для сети №2.

Правило FORWARD — надо смотреть, хз. Зависит от того, как реализован доступ сервера Б к локалкам.

что то не выходит, добавляя данное правило с сети №2 так никто и не видит сервер... вот более конкретные данные:
ip сервера А локальной сети №1 - 10.101.16.67
ip сервера B локальной сети №1 - 10.100.113.201 (надо было бы указать сразу, что есть такой ип:))
ip сервера B локальной сети №2 - 10.11.52.56
это все через порт 7777

2013.03.11 23:20:20
#cid56950

Ответить

#cid56793, CODer

Является ли сервер Б шлюзом между локалками №1 и №2?

Доступна ли локалка №2 с сервера А напрямую, в обход сервера Б?

Никита
2013.05.28 18:24:10
#cid63510

Ответить

Автор статьи просто красавец.
В интернете полно инфы как это сделать, но нифига не работает, только этот скрипт заработал из коробки.
Выражаю благодарность.

Alexandr(gastu@mail.ru)
2014.02.17 15:42:35
#cid86854

Ответить

Здравсвтуйте. У меня есть vps на cent os со статическим ip и есть сервер дома с динамическим. Сервер подключен по впн к линуксу. Почитав ваш пост все стало понятно, вроде теперь я могу сделать проброс портов, и неважно если мой динамический айпи поменяется. Но вот как мне выдать внутреннюю статику для этого сервера на винде при подключении?

хочу сделать что-то типа динамик днс

gastu@mail.ru

2014.02.20 04:55:53
#cid86999

Ответить

#cid86854, Alexandr(gastu@mail.ru)

Здравсвтуйте. У меня есть vps на cent os со статическим ip и есть сервер дома с динамическим. Сервер подключен по впн к линуксу. Почитав ваш пост все стало понятно, вроде теперь я могу сделать проброс портов, и неважно если мой динамический айпи поменяется. Но вот как мне выдать внутреннюю статику для этого сервера на винде при подключении?

Вопрос не имеет отношения к заметке. Возможно, проброска порта была необходима, чтобы достучаться до VPN-сервера, но только и всего. После установки VPN соединения клиентский компьютер (или клиентская подсеть) начинает прозрачно видеть удалённую подсеть. Задача с выдачей внутренних адресов решается совсем отдельно, в рамках этой единой прозрачной сети.

хочу сделать что-то типа динамик днс

Можно так, можно привязать к MAC-адресу, можно вручную прописать. Как угодно.
Это совсем другая задача, нельзя мешать всё в кучу.

argus
2014.02.21 22:06:29
#cid87102

Ответить

Спасибо! единственная рабочяя статья попалась. проманался с ssh тунелями, но этот пост проще оказался.

2014.02.22 06:38:05
#cid87127

Ответить

#cid87102, argus

Спасибо! единственная рабочяя статья попалась. проманался с ssh тунелями, но этот пост проще оказался.

SSH-туннели тоже рулят!

marat4net
2014.03.12 15:30:32
#cid88486

Ответить

Огромное спасибо за материал!

alemaan
2014.03.26 16:19:36
#cid89084

Ответить

Большое спасибо, все просто и понятно)

Vadim_d67
2014.05.02 15:17:18
#cid89232

Ответить

Доброго времени суток.
Подскажите пож-та новичку.
Есть чисто роутер на ubuntu 12.04 сервер (192.168.0.2). У клиентов в сети все адреса статические, есть сервер Вин 2003 Задача: пробросить RDP порт на вин.сервер 192.168.0.1 и дать части клиентов доступ в инет, но при этом максимально прикрыть неиспользуемые порты, т.е. разрешить только ВЭБ, почту и скайп (это все что надо для работы). Но у меня получилось только дать доступ по всем портам, если я указываю конкретные порты (80,25,110,443) то инет у клиентов полностью отваливается. Сейчас работает вот так:
#!/bin/bash
/sbin/iptables -F
/sbin/iptables -t nat -F

# Прописываем политики по умолчанию:
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP

# Включаем форвардинг
sysctl -w net.ipv4.ip_forward="1"
# Включаем Маскарад
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o eth0 -j REJECT
/sbin/iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

#*****************************************************************************
# Защита самого сервера!!

# Номера непривилегированных портов
UNPRIPORTS="1024:65535"
# Разрешаем прохождение любого трафика по интерфейсу обратной петли.
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# Запрещаем любые новые подключения с любых интерфейсов, кроме lo к компьютеру.
/sbin/iptables -A INPUT -m state ! -i lo --state NEW -j DROP

# Если интерфейс не lo, то запрещаем входить в список его адресов.
/sbin/iptables -A INPUT -s 127.0.0.1/255.0.0.0 ! -i lo -j DROP

#Делаем защиту от Dos атак:
/sbin/iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

# Отбрасывать все пакеты, которые не могут быть идентифицированы и поэтому не могут иметь определенного статуса.
/sbin/iptables -A INPUT -m state --state INVALID -j DROP
/sbin/iptables -A FORWARD -m state --state INVALID -j DROP

# Принимать все пакеты, которые инициированы из уже установленного соединения, и имеющим признак ESTABLISHED.
# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.

/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Предупреждаю вас о туповатых провайдерах, которые назначают IP адреса, отведенные IANA для локальных сетей.
# Например адреса 10.X.X.X. Для этого надо установить правило, пропускающие трафик с этих серверов, ранее цепочки INPUT.
/sbin/iptables -t nat -I PREROUTING -i eth0 -s 10.0.0.1/32 -j ACCEPT

# Эти правила предохраняют от некоторых типов атак:

# SYN наводнение.
# Приводит к связыванию системных ресурсов, так что реальных обмен данными становится не возможным.
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
/sbin/iptables -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP

# UDP наводнение
# Службы использующие UDP, очень часто становятся мишенью для атак с целью вывода системы из строя.
/sbin/iptables -A INPUT -p UDP -s 0/0 --destination-port 138 -j DROP
/sbin/iptables -A INPUT -p UDP -s 0/0 --destination-port 113 -j REJECT
/sbin/iptables -A INPUT -p UDP -s 0/0 --source-port 67 --destination-port 68 -j ACCEPT
/sbin/iptables -A INPUT -p UDP -j RETURN
/sbin/iptables -A OUTPUT -p UDP -s 0/0 -j ACCEPT

# ICMP - перенаправление
# ICMP - сообщение указывает системе изменить содержимое таблиц маршрутизации с тем, что бы направлять
# пакеты по более короткому маршруту. Может быть использовано взломщиком для перенаправления вашего трафика через свою машину.
/sbin/iptables -A INPUT --fragment -p ICMP -j DROP
/sbin/iptables -A OUTPUT --fragment -p ICMP -j DROP

# Разрешаем ICMP соединение. Значительная часть ICMP используется для передачи сообщений о
# том, что происходит с тем или иным UDP или TCP соединением.
/sbin/iptables -A INPUT -p icmp -m icmp -i eth0 --icmp-type source-quench -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp -m icmp -o eth0 --icmp-type source-quench -j ACCEPT

# Разрешаем себе ping наружу - нас же не попингуешь - пакеты отбрасываются.
/sbin/iptables -A INPUT -p icmp -m icmp -i eth0 --icmp-type echo-reply -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp -m icmp -o eth0 --icmp-type echo-request -j ACCEPT

# Запрещаем подключение к X серверу через сетевые интерфейсы.
/sbin/iptables -A INPUT -p tcp -m tcp -i eth0 --dport 6000:6063 -j DROP --syn

# Прописываем порты, которые открыты в системе, но которые не должны быть открыты на сетевых интерфейсах:
# /sbin/iptables -A INPUT -p tcp -m tcp -m multiport -i eth0 -j DROP --dports #порта
/sbin/iptables -A INPUT -p tcp -m tcp -m multiport -i eth0 -j DROP --dports 783
/sbin/iptables -A INPUT -p tcp -m tcp -m multiport -i eth0 -j DROP --dports 3310
/sbin/iptables -A INPUT -p tcp -m tcp -m multiport -i eth0 -j DROP --dports 10000

# DNS сервер имен разрешаем.
/sbin/iptables -A OUTPUT -p udp -m udp -o eth0 --dport 53 --sport $UNPRIPORTS -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp -m tcp -o eth0 --dport 53 --sport $UNPRIPORTS -j ACCEPT
/sbin/iptables -A INPUT -p udp -m udp -i eth0 --dport $UNPRIPORTS --sport 53 -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m tcp -i eth0 --dport 1024:65353 --sport 53 -j ACCEPT

# Разрешаем AUTH-запросы на удаленные сервера, на свой же компьютер - запрещаем.
/sbin/iptables -A OUTPUT -p tcp -m tcp -o eth0 --dport 113 --sport $UNPRIPORTS -j ACCEPT
/sbin/iptables -A INPUT -p tcp -m tcp -i eth0 --dport $UNPRIPORTS --sport 113 -j ACCEPT ! --syn
/sbin/iptables -A INPUT -p tcp -m tcp -i eth0 --dport 113 -j DROP
# Разрешаем 22-й порт.
/sbin/iptables -A INPUT -p tsp -i eth0 -m multiports –-dports 22 -j ACCEPT
/sbin/iptables -A OUTPUT -p tsp -o eth0 -m multiports --sports 22 -j ACCEPT

# указываем путь к текстовому файлу, содержащему список запрещенных сайтов
badsite=($(cat”/home/vadim/sbd.txt”))

# указываем путь к текстовому файлу, содержащему список хороших IP
goodip=($(cat”/home/vadim/ipgood.txt))
# Делаем проброс портов, для достпа через удаленный рабочий стол RDP
# из внешней сети к компу (серверу) в локалке.
/sbin//sbin/iptables -t nat -A PREROUTING –dst eth0 -p tcp –-dport 3389 -j DNAT –-to-destination 192.168.0.1:3389
/sbin//sbin/iptables -t nat -A POSTPOUTING -p tcp --dst 192.168.0.1 –-dport 3389 -j SNAT –-to-sourse eth0

# теперь разрешаем траффик между этим компом и интернетом, но только на этот #порт.
/sbin/iptables -A FORWARD -i eth0 -o eth1 -d 192.168.0.1 -p tcp -m tcp --dport 3389 -j ACCEPT
# Ответ разрешаем с любого порта
/sbin/iptables -A FORWARD -i eth1 -o eth0 -s 192.168.0.1 -j ACCEPT

###################################################
# Запрещаем "плохие сайты"
##################################################
i=0
for i in "${badsite[@]}"
do
/sbin/iptables -A FORWARD -s $i -j DROP
done

################################################
Разрешаем интернет “хорошим” АйПи
###############################################
i=0
for i in "${goodip[@]}"
do
# tcp
#/sbin/iptables -A FORWARD -s $i -o eth0 -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A FORWARD -s $i -i eth1 -o eth0 -j ACCEPT
#/sbin/iptables -A FORWARD -i eth0 -o eth1 -d $i -j ACCEPT
#/sbin/iptables -A FORWARD -s $i -i eth1 -o eth0 -j ACCEPT
#/sbin/iptables -A FORWARD -i eth0 -o eth1 -d $i -p tcp --destination-port 8080 -j ACCEPT
#/sbin/iptables -A FORWARD -o eth0 -s $i -p tcp -m multiport --dports 53,80,25,110,443,5190 -j ACCEPT
#/sbin/iptables -A FORWARD -i eth0 -d $i -p tcp -m multiport --sports 53,80,25,110,443,5190 -j ACCEPT
#/sbin/iptables -A INPUT -p tcp -s $i --dport 80 -j ACCEPT
#/sbin/iptables -A FORWARD -p tcp -s $i ! -d 192.168.0.0/24 --sport 80 -j ACCEPT
#/sbin/iptables -A FORWARD -p tcp -d $i ! -s 192.168.0.0/24 -m multiport –-dports 80,53,25,110,5190,443 -j ACCEPT
#/sbin/iptables -A FORWARD -p tcp -s $i ! -d 192.168.0.0/24 -m multiport –-sports 80,53,25,110,5190,443 -j ACCEPT
#udp
#/sbin/iptables -A FORWARD -p udp -d $i ! -s 192.168.0.0/24 -m multiport --dports 53 -j ACCEPT
#/sbin/iptables -A FORWARD -p udp -s $i ! -d 192.168.0.0/24 -m multiport --sports 53 -j ACCEPT
done

Проброс портов на сервер пока не тестировал. (Дай бог с клиентами в локалке разобраться) В цикле "Разрешаем интернет “хорошим” АйПи" те строчки которые закомментированы я перепробовал. работает только так как с сейчас записано. Но по всем портам сразу. А я бы хотел комуто разрешить и скайп и ВЭБ а кому-то оставить только почту. Как сделать?
Зараннее благодарен.

CODer
2014.06.07 21:56:27
#cid89389

Ответить

#cid56950,

#cid56793, CODer

Является ли сервер Б шлюзом между локалками №1 и №2?

Доступна ли локалка №2 с сервера А напрямую, в обход сервера Б?

1 вопрос - скорее нет чем да, честно говоря не совсем понял вопрос)
2 вопрос - локальная сеть №1 сервера А (10.101.16.67) не доступна локальной сети №2 сервера Б (10.11.52.56), а доступна локальной сети №1 сервера Б (10.100.113.201)

Valera
2014.08.12 20:44:01
#cid89546

Ответить

подскажите, а как пробросить к примеру rdp на две машины ???

2014.08.12 21:39:36
#cid89547

Ответить

#cid89546, Valera

Посади на разные порты. Например, 33891 — первый комп, 33892 — второй (смотри «Перенаправление портов»).
И подключаться с явным указанием конкретного порта для подключения: "[ip-адрес]:[номер_порта]".

Valera
2014.08.13 10:09:06
#cid89548

Ответить

#cid89547,

#cid89546, Valera

Посади на разные порты. Например, 33891 — первый комп, 33892 — второй (смотри «Перенаправление портов»).
И подключаться с явным указанием конкретного порта для подключения: "[ip-адрес]:[номер_порта]".

Ну про такой способ я подумывал, но думал может можно как то и по другому можно решить.

2014.08.14 12:54:03
#cid89553

Ответить

#cid89548, Valera

Ну про такой способ я подумывал, но думал может можно как то и по другому можно решить.

У входящего пакета есть всего 3 критерия для нужного отбора: IP_источника, IP_назначения и порт_назначения.

IP_источника. Можно и нужно использовать, когда удалённый адрес не меняется. Этим убивается сразу несколько зайцев: 1) доступ ограничивается только для конкретного внешнего IP, это хорошо для безопасности; 2) не нужно менять порт для входящего подключения, для неопытных пользователей это может быть удобнее; 3) разные внешние IP при этом можно заассоциировать с разными внутренними машинами.

IP_назначения. Можно использовать, если у конторы есть целый пул лишних адресов. Но адресов IPv4 сейчас дефицит, и лично не представляю себе я такую ситуацию. "Лишним" адресам всегда найдётся лучшее применение.

Порт_назначения — можно использовать всегда. Для пущей безопасности, чтобы не светить порт всему инету, доступ можно сделать только для нескольких конкретных IP. То есть, это универсальный способ — и гибкий, и достаточно надёжный.

То есть, выбор существует. И иногда не только можно, но и нужно делать по-другому.

marat4net
2014.08.21 14:52:37
#cid89571

Ответить

При помощи Вашей статьи настроил web-сервер и сейчас настраиваю сервер эл.почты.
Имею:
1) шлюз с двумя сетевыми интерфейсами (первый: eth0 - внутренний с IP 192.168.0.1; второй интерфейс: eth1 - внешний с IP 8.8.8.300 и доменом example.com;
2) сервер эл.почты с одним интерфейсом (внутренний с IP 192.168.0.300).
Задача: настроить iptables на шлюзе для работы с эл.почтой по Интернету и локальной сети.
Возникла следующая проблема: почтовые клиенты (Outlook, Thunderbird) не могут подключиться к серверу эл.почты из локальной сети, если в настройках клиента указать адрес сервера в виде example.com. Но если указать внутренний IP-адреса сервера эл.почты (192.168.0.300), то клиенты подключаются к нему и работают без проблем. При этом почтовые клиенты из Интернета, в настройках которых адрес сервера указан в виде exmaple.com, работают без проблем. Я подозреваю, что неверно настроил iptables с момента, указанного в статье:

"С другой - а что будет, если попытается подключиться клиент из локальной сети?"

Пожалуйста, помогите решить проблему. Фрагмент текущих настроек iptables (касаемо именно работы эл.почты):

-A PREROUTING -i eth0 -p tcp -d 192.168.0.300 --dport 25 -j DNAT --to-destination 192.168.0.300:25
-A PREROUTING -i eth0 -p tcp -d 192.168.0.300 --dport 143 -j DNAT --to-destination 192.168.0.300:143
-A PREROUTING -i eth1 -p tcp -d 8.8.8.300 --dport 143 -j DNAT --to-destination 192.168.0.300:143
-A PREROUTING -i eth1 -p tcp -d 8.8.8.300 --dport 25 -j DNAT --to-destination 192.168.0.300:25

-A POSTROUTING --dst 192.168.0.300 -p tcp --dport 25 -j SNAT --to-source 192.168.0.1
-A OUTPUT --dst 8.8.8.300 -p tcp --dport 25 -j DNAT --to-destination 192.168.0.300

-A POSTROUTING --dst 192.168.0.300 -p tcp --dport 143 -j SNAT --to-source 192.168.0.1
-A OUTPUT --dst 8.8.8.300 -p tcp --dport 143 -j DNAT --to-destination 192.168.0.300

-A POSTROUTING -o eth0 -p tcp -s 192.168.0.0/24 -d 192.168.0.300 --dport 25 -j SNAT --to-source 192.168.0.1
-A POSTROUTING -o eth0 -p tcp -s 192.168.0.0/24 -d 192.168.0.300 --dport 143 -j SNAT --to-source 192.168.0.1
-A POSTROUTING -o eth1 -j SNAT --to-source 8.8.8.300

nur
2014.09.01 06:39:20
#cid89601

Ответить

Три года заметке, сто комментариев. В остальных заметках, где нужны примеры адресов, 333-й тоже фигурирует.
Ты — первый, кто обратил внимание.

дык, ты ж мануал написал для людей не очень в этом сображающих )
у меня был случай - клиент пытался требовать ип 777 )))

Была задача обрисовать — по возможности — все нюансы проброса, но без лишних оговорок и уточнений. Для новичков.
Вроде получилось.
Справедливости ради надо сказать, что лично я POSTROUTING тоже никогда не ставлю — не вижу смысла.
Внутренние службы (локалка-локалка) идут мимо роутера. Внешние (инет-локалка) не нуждаются в этой записи. А общие службы надо >> располагать в DMZ, так правильнее.

для новичков спасибо, но блин у меня стоит задача видеть реальные ипы на веб-сервере, можно мануал подправить в эту сторону? )
а то я еще не мегоодмин :\

Дункан Макдак
2014.09.01 22:53:46
#cid89603

Ответить

Второй конфиг (с изменением порта) не работает :(

1@svetlana:/etc/network$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere 192.168.56.101 tcp dpt:ssh
ACCEPT tcp -- anywhere 192.168.56.101 tcp dpt:http

и вот http пробрасывается (апач работает), а в ssh не попасть...

Дункан Макдак
2014.09.01 23:57:00
#cid89604

Ответить

у меня был случай - клиент пытался требовать ип 777 )))

как-то два дня бился с настройкой роутера у клиента. ну вот вижу сеть по tcpdump, а никуда не пускает, хоть тресни!
на второй день в техподдержке таки взял трубку не мальчик, но админ.
хрюкая от смеха, он рассказал мне, что оператор, вчера прописывавший MAC-адрес роутера под мою диктовку вместо 2D записал 2T...

nur
2014.09.02 00:20:00
#cid89605

Ответить

имхо в провайдинге фильтрация по макам уже устарела, недаром же более распространена парольная аутентификация, например pppoe
фильтр по макам еще можно применить в отдельном единственном офисе, где админ может придти ногами и настучать юзеру по шапке за смену мака

а в твоем примере выше ты показал не всё, во первых кроме iptables -L надо бы показать iptables -L -t nat

а во вторых, можно еще добавить ключ -n , там просто отображение понятнее-равномеренее, с одними цыфарками

#iptables -nL
#iptables -nL -t nat

2014.09.02 12:19:37
#cid89608

Ответить

#cid89601, nur

Все пакеты, прошедшие через NAT, дальше идут от имени шлюза. Так устроен NAT.
В комментах уже был подобный вопрос.

у меня стоит задача видеть реальные ипы на веб-сервере

Тогда веб-серверу надо давать реальный IP и выставлять наружу.

Или сопоставлять логи сервера и шлюза, но это чудовищный гемор.

можно мануал подправить в эту сторону? )

Это ж другое. К данному мануалу не относится.

imen
2014.09.03 17:34:24
#cid89614

Ответить

#cid89608,

Тогда веб-серверу надо давать реальный IP и выставлять наружу.

Или сопоставлять логи сервера и шлюза, но это чудовищный гемор.

Почему?!?
http://httpd.apache.org/docs/2.2/mod/mod_log_config.html
%a Remote IP-address
%h Remote host
ЕМНИП должно решить проблему.
* Глянул в журнал сервера (access.log), IP-адрес сетевого интерфейса которого мягко говоря не совпадает с IP-адресом, на который идут обращения к нему и убедился в правильности высказанного утверждения.

Или у web-сервера несколько разных IP-адресов (интерфейсы или alias'ы) и интересует кто на какой ходит?

Это ж другое. К данному мануалу не относится.

Это да.
Но достаточно часто к решению задачи можно идти сильно разными маршрутами.

2014.09.03 20:23:47
#cid89616

Ответить

#cid89614, imen

Круто.

Расскажи в двух словах, как оно берёт реальный айпишник клиента из шлюза?

Гость
2014.09.07 10:31:55
#cid89642

Ответить

#cid89608,

#cid89601, nur

Все пакеты, прошедшие через NAT, дальше идут от имени шлюза. Так устроен NAT.

верно, но... такая схема уже работала, на центос (который линух, и в котором редиректить можно иптаблесом. например такое еще умеет redir, но он точно не умеет ип передавать)
жаль я не удосужился спросить как

а еще до этого я сам такое делал на фрибсд, там вообще элементарно - две строки в конфиге ipnat

насколько я слышал чтобы такая схема работала, веб сервер должен находиться в одной подсети с рутером (на котором нат)

2014.09.09 20:07:34
#cid89653

Ответить

#cid89642, Гость

Многие видели, что это — принципиально возможно, у кого-то даже работает на практике, но никто не признаётся, как именно это реализовано :)

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

imen
2014.09.12 16:40:44
#cid89656

Ответить

#cid89616,

Расскажи в двух словах, как оно берёт реальный айпишник клиента из шлюза?

Физику сети здесь держу не я.
За полный цикл не копенгаген и вполне согласен с твоим мнением о том, что в данном решении используется не столько iptables.

Однако есть мнение, что если проброс осуществляется маршрутизатором (который default route), то достаточно переписать адрес хоста назначения для входящих пакетов, и соответственно источника для исходящих.
Не трогая адреса клиента.
Как это делается (и вообще: можно ли это сделать) средствами iptables — честно скажу: не знаю.

marat4net
2014.09.12 22:44:03
#cid89657

Ответить

Откликнетесь, если я неправильно настроил для ситуации, когда клиент подключается из локальной сети:http://www.it-simple.ru/?p=2250#cid89571

2014.09.13 03:24:16
#cid89659

Ответить

#cid89657, marat4net

Откликнетесь, если я неправильно настроил для ситуации, когда клиент подключается из локальной сети:

#cid89571, marat4net

При помощи Вашей статьи настроил web-сервер и сейчас настраиваю сервер эл.почты.
Имею:
1) шлюз с двумя сетевыми интерфейсами (первый: eth0 - внутренний с IP 192.168.0.1; второй интерфейс: eth1 - внешний с IP 8.8.8.300 и доменом example.com;
2) сервер эл.почты с одним интерфейсом (внутренний с IP 192.168.0.300).
Задача: настроить iptables на шлюзе для работы с эл.почтой по Интернету и локальной сети.

Для таких задач всегда рекомендую настраивать локальный DNS.
Это честное слово очень, очень, очень сильно облегчает жизнь.
И пакеты ходят как надо, а не раком через Киев.

Возникла следующая проблема: почтовые клиенты (Outlook, Thunderbird) не могут подключиться к серверу эл.почты из локальной сети, если в настройках клиента указать адрес сервера в виде example.com. Но если указать внутренний IP-адреса сервера эл.почты (192.168.0.300), то клиенты подключаются к нему и работают без проблем. При этом почтовые клиенты из Интернета, в настройках которых адрес сервера указан в виде exmaple.com, работают без проблем. Я подозреваю, что неверно настроил iptables с момента, указанного в статье:

Пожалуйста, помогите решить проблему. Фрагмент текущих настроек iptables (касаемо именно работы эл.почты):

-A PREROUTING -i eth0 -p tcp -d 192.168.0.300 --dport 25 -j DNAT --to-destination 192.168.0.300:25

SMTP: Если пакет пришёл на локальный интерфейс шлюза, а в его пункте назначения прописан локальный адрес почтовика (как это возможно в штатной ситуации?) то переписываем адрес назначения на локальный адрес почтовика (то есть, ничего не делаем).

Зачем это? Какую роль выполняет это правило?

-A PREROUTING -i eth0 -p tcp -d 192.168.0.300 --dport 143 -j DNAT --to-destination 192.168.0.300:143

IMAP: Делаем то же самое. То есть — генерируем порожняки для несуществующей ситуации.

-A PREROUTING -i eth1 -p tcp -d 8.8.8.300 --dport 143 -j DNAT --to-destination 192.168.0.300:143
-A PREROUTING -i eth1 -p tcp -d 8.8.8.300 --dport 25 -j DNAT --to-destination 192.168.0.300:25

IMAP и SMTP: Если почтовый пакет пришёл на внешний интерфейс шлюза и в его пункте назначения прописан внешний адрес шлюза, то переписываем адрес назначения на локальный адрес почтовика.

Здесь всё вроде нормально, но про службу POP3 (110 порт) и шифрованное соединение можно забыть. Странно, что по твоим словам подключения из интернета идут без проблем.

-A POSTROUTING --dst 192.168.0.300 -p tcp --dport 25 -j SNAT --to-source 192.168.0.1
-A OUTPUT --dst 8.8.8.300 -p tcp --dport 25 -j DNAT --to-destination 192.168.0.300

-A POSTROUTING --dst 192.168.0.300 -p tcp --dport 143 -j SNAT --to-source 192.168.0.1
-A OUTPUT --dst 8.8.8.300 -p tcp --dport 143 -j DNAT --to-destination 192.168.0.300

Здесь вроде всё правильно, но опять же:
- если шлюз не является почтовым клиентом, то правила OUTPUT не нужны;
- если в сети поднят локальный DNS и в нём переписаны MX-записи exmaple.com на локальные, то правила POSTROUTING не нужны и снимается ряд других возможных проблем;
- про POP3 и шифрование снова забыли.

-A POSTROUTING -o eth0 -p tcp -s 192.168.0.0/24 -d 192.168.0.300 --dport 25 -j SNAT --to-source 192.168.0.1
-A POSTROUTING -o eth0 -p tcp -s 192.168.0.0/24 -d 192.168.0.300 --dport 143 -j SNAT --to-source 192.168.0.1

Обеспечиваем возврат локальных пакетов через шлюз. Вроде всё нормально. POP3 и шифрование идут нахер.

-A POSTROUTING -o eth1 -j SNAT --to-source 8.8.8.300

Ну а это стандартная шлюзовая функция, не имеющая отношения к почте.

Наверное, ошибка в правилах FORWARD, которые здесь вообще не представлены.
Ты, вероятно, разрешил проход пакетов из интернета в локалку, но забыл, что пакеты из локалки в локалку тоже надо явно разрешать. Это частая ошибка.

2014.09.13 14:10:02
#cid89660

Ответить

#cid89656, imen

Однако есть мнение, что если проброс осуществляется маршрутизатором (который default route), то достаточно переписать адрес хоста назначения для входящих пакетов, и соответственно источника для исходящих.
Не трогая адреса клиента.

В пакетах типа интернет-локалка, проходящих через NAT, меняется адрес назначения (это отражено в PREROUTING). Всё остальное остаётся без изменений. Далее пакет отправляется в маршрутизатор и тот отправляет его на сервер в локальной сети. Как результат — в логах сервера будет вписан внешний адрес клиента, и ответ пойдёт на этот адрес, то есть в default route, то есть через шлюз.

В пакетах типа локалка-локалка, принудительно идущих через шлюз, адрес внутреннего клиента подменяется на адрес шлюза. Логирование внутренних клиентов становится затруднено: все локальные подключения происходят от имени шлюза. Мы, как бы, говорим именно про эту ситуацию.

Именно поэтому я не устаю повторять:

Во всех сомнительных ситуациях для локальных соединений надо использовать внутренний DNS. Это лучше, чем заставлять идти пакеты через шлюз.

Во всех ситуациях надо чётко понимать что, как и для чего ты делаешь. Если ты этого не понимаешь — не делай этого.

Алекс
2015.02.26 10:20:55
#cid90338

Ответить

Помогите разобраться
Ситуация такова.
есть роутер с адресом 192.168.1.1 и внешним статическим адресом и DHCP и WiFi
к нему подключен кабелем lan-lan OpenWRT с VPN и SSH серверами и дальше локальный PC кабелем подключен в lan порт OpenWRT
Сделан проброс порта на VPN OpenWRT из интернета. ВПН цепляется без проблем. PC домашний пингуется. но по RDP не пускает. ТАже ситуация ели дома через WiFi цепляемся к роутеру RDP на PC не пускает. хотя и пингуется.
Если PC подключить напрямую к роутеру а не в OpenWRT то тогда с RDP проблем нет.
Какими правилами и настройками это можно поправить ? без привязки к конкретному компьютеру. т.к. в OpenWRT может быть подключено несколько разных машин

Андрей
2015.04.15 09:44:18
#cid90486

Ответить

Вот еще один рабочий пример, всегда им пользуюсь:

$EXT_R_IP - внешний IP роутера
$LOCAL_IP - внутренний "фэйковый" адрес машины, которую надо "выкидывать" наружу
$PORT1 - Порт, на который будут заходить извне и попадать на локальную машину
$PORT2 - Порт, который "выбрасывается" наружу(например, 80 - http, либо 21 - ftp)

iptables -t nat -A PREROUTING -p tcp -d $EXT_R_IP --dport $PORT1 -j DNAT --to-destination $LOCAL_IP:$PORT2
iptables -A FORWARD -i eth0 -d $LOCAL_IP -p tcp --dport $PORT2 -j ACCEPT

2015.04.15 12:31:44
#cid90487

Ответить

#cid90486, Андрей

Дык это ж то же самое, только упрощённый вариант.
Да, в подавляющем большинстве случаев достаточно единственной записи PREROUTING в "nat" и корректного разрешения FORWARD в "filter".

ivan
2015.05.04 11:37:15
#cid90528

Ответить

Подскажите, как подключиться с локальной сети в которой веб сервер по внешнему ІР, то что в статье не работает.

NINJA2121
2015.07.08 12:46:30
#cid90755

Ответить

подскажи момент один (я в линуксе полный ноль, а на новой работе шлюз на gentoo)
нужно разрешить из локалки во внешний мир порт хххх.
Заранее благодарен за отет.

2015.07.08 13:35:36
#cid90756

Ответить

#cid90755, NINJA2121

подскажи момент один (я в линуксе полный ноль, а на новой работе шлюз на gentoo)
нужно разрешить из локалки во внешний мир порт хххх.

Неправильная постановка вопроса.
"Порт" — это способ отличать сетевые пакеты разных типов, которые приходят на сервер. "Разрешить из локалки во внешний мир порт" — нельзя, можно разрешить внешнему миру подключаться к серверу и сетевой службе. IP определяет конкретный сервер, к которому идёт подключение, а порт — конкретную сетевую службу на нём.

Если служба работает на шлюзе, она уже слушает свой порт, и достаточно прописать разрешающее правило для входящих пакетов (таблица filter, цепочка INPUT).
Если служба работает на внутреннем сервере локальной сети — читай "проброс портов", там всё написано и достаточно подробно.

imen
2015.07.08 16:42:52
#cid90757

Ответить

#cid90756,

Неправильная постановка вопроса.
"Порт" — это способ отличать сетевые пакеты разных типов, которые приходят на сервер. "Разрешить из локалки во внешний мир порт" — нельзя, можно разрешить внешнему миру подключаться к серверу и сетевой службе. IP определяет конкретный сервер, к которому идёт подключение, а порт — конкретную сетевую службу на нём.

Строго говоря, ты тоже можешь ошибаться.
Даже если не ставить вопрос о терминологии (оставим «службы» вместе с иконками самой распространённой ОС).

Из локальной сети доступ вовне обычно лимитирован (особенно этим славны боящиеся эксплуатируемых чёрных ящиков и не отличающиеся навыками работы с подсистемой журналирования вендоодменестраторы), в том числе по разрешённым сервисам (/etc/services) сети общего пользования. Характернейший, пример — smtp на стандартном порту (понятно почему). Или https (злободневно при необходимости работы с несколькими виртуальными хостами на одном IP–адресе, потому что осёл как минимум в старшей из доступных для «лучшей ОС майкрософта» версии не умеет работать с NameBased SSL Virtual Hosts).
Так что столкнуться с ситуацией, когда доступ с рабочей станции в ЛВС на некоторый нестандартный (или просто не понравившийся одмену) порт вовне (независимо от адреса узла) запрещён очень даже можно.
Примеров тому наблюдал достаточно. Последний — акурат на этой неделе.

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

NINJA2121
2015.07.09 05:07:39
#cid90758

Ответить

тогда сформулирую по-другому:
есть некий сервер с сервисом лицензирования MS Office за пределами нашего города (kms_srv)
наши клиентские машины не могут до него достучаться по порту 1688
есть VPN с серваком. при команде ping адрес показывает но при этом request timed out.
как посмотреть разрешения и вообще исправить ситуацию?
повторюсь, что в линухе полный ноль, но вот надо вникать, обещаю обучаться))))

imen
2015.07.09 09:57:16
#cid90759

Ответить

#cid90758, NINJA2121

есть некий сервер с сервисом лицензирования MS Office

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

наши клиентские машины не могут до него достучаться по порту 1688

Неполно.
Я конечно могу с достаточной степенью вероятия предположить использование транспортного протокола tcp.
Но в общем случае это неверно. Как раз вчера, разбираясь с монтированием NFS при включённом пакетном фильтре наблюдал пример.

есть VPN с серваком. при команде ping адрес показывает но при этом request timed out.

Пакеты, надо полагать, должны ходить через VPN?
Отсюда сразу вопросы об используемых адресах (публичные или из диапазонов для частных сетей: 10.0.0.0/8, 192.168.0.0/16 и третий с /12 маской навскидку не помню) и настройке маршрутизации.
Не говоря о том, что прохождение ping (icmp-пакетов) внезапно совсем ≠ доступности нужного порта по требуемому протоколу (tcp || udp).

как посмотреть разрешения и вообще исправить ситуацию?

Правила пакетного фильтра:
/sbin/iptables -L -n
Маршруты:
route -n
Сетевые интерфейсы:
ifconfig -a

Прежде чем что-либо менять, надо определиться с проблемой.
Т.е. смотри настройки маршрутизации (трассу).
Сначала traceroute с сервера (шлюза), потом tracert с рабочих станций.

2015.07.10 12:25:10
#cid90765

Ответить

#cid90758, NINJA2121

есть некий сервер с сервисом лицензирования MS Office за пределами нашего города (kms_srv)
наши клиентские машины не могут до него достучаться по порту 1688

Стучатся снаружи, по прямому адресу? Или через ВПН, о котором ниже?

есть VPN с серваком. при команде ping адрес показывает но при этом request timed out.

Если пингуешь имя и высвечивается адрес — это означает всего лишь то, что нормально сработал DNS и в нём есть пингуемое имя. Не более того. С доступностью сервера (см. "request timed out") оно никак не связано.

как посмотреть разрешения и вообще исправить ситуацию?

Самое важное — разобраться, как (через какие узлы, по ВПН или нет и т.д.) ходят сетевые пакеты. Тогда станет понятно, какие узлы надо проверять на наличие блокировок. Пока — непонятно.

ваня
2015.07.17 07:47:52
#cid90789

Ответить

помогите, у меня не срабатывает правило
iptables -A FORWARD -m string --string "vk.com" --algo kmp --to 65535 -j DROP. Захожу с браузера на vk.com работает, а когда пишу
iptables -A FORWARD -m string --string "vk" --algo kmp --to 65535 -j DROP не могу зайти на vk.com. Мне нужно первое правило, чтобы на vk.com не давал доступ.

2015.07.17 10:30:35
#cid90792

Ответить

#cid90789, ваня

помогите, у меня не срабатывает правило
iptables -A FORWARD -m string --string "vk.com" --algo kmp --to 65535 -j DROP. Захожу с браузера на vk.com работает, а когда пишу
iptables -A FORWARD -m string --string "vk" --algo kmp --to 65535 -j DROP не могу зайти на vk.com. Мне нужно первое правило, чтобы на vk.com не давал доступ.

Должно работать. Проверь последовательность правил. Включи "-j LOG" и посмотри, что происходит (только не забудь выключить потом, а то место может быстро закончиться).

Способ решения проблемы — изначально неверный.

1. Использование расширения "string" конкретно замедляет работу iptables и нагружает процессор, ведь проверяется содержимое области данных каждого сетевого пакета.

2. Так как проверяется каждый пакет, то любое упоминание "vk.com" будет заблокировано. То есть, пакеты с запросом "http://yandex.ru/search/?text=vk.com" или "ftp://vk.company.some" не пройдут, если ты понимаешь о чём я.

3. Если строка окажется разбита по разным пакетам, блокировка не сработает.

4. Содержимое "string" чувствительно к регистру. Да, вконтактик сбрасывает регистр на нижний, но анонимайзеры прекрасно отдадут запрос к "VK.com".

В итоге — каждый должен заниматься своим делом. Имена пусть блокирует локальный DNS, веб-пакеты — какой-нибудь фильтрующий прокси, а iptables должен обрабатывать айпишники.
Моё такое мнение.

ваня
2015.07.17 18:05:06
#cid90803

Ответить

Спасибо за быстрый и подробный ответ. Если способ решения проблемы — изначально неверный, как Вы писали, то еще как можно?

В общем у меня стоит такая задача: мне нужно фильтровать пакеты с содержанием domen.ru (берется из AD, имена_ПК.domen.ru). Если содержится domen.ru, то дать интернет через прокси, если нет-то напрямую в интернет. Как можно реализовать такую задачу?

2015.07.18 08:27:45
#cid90804

Ответить

#cid90803, ваня

еще как можно?

Я ж в конце кратко написал.
В подавляющем большинстве случаев достаточно заблокировать сайты на внутреннем DNS.

В общем у меня стоит такая задача: мне нужно фильтровать пакеты с содержанием domen.ru

Определись с задачей. Тебе точно нужно именно это?
Интернет не ограничивается одним лишь вебом, а в сетевых пакетах содержатся не только имена сайтов. Ты можешь заблокировать не то, что хотел. А потом, когда возникнут непонятки, будешь долго искать причину "сбоя" и рвать волосы на попе.

берется из AD, имена_ПК.domen.ru

DNS и DHCP которые идут с AD — адское говно. Использовать их можно только в самом крайнем случае, когда вообще без вариантов. Не используй их.

Поставь нормальный отдельный DNS (например dnsmasq, он шустрый и лёгкий в настройке), подцепи его к домену (чтобы нормально работал с AD) и радуйся жизни.

Если содержится domen.ru, то дать интернет через прокси, если нет-то напрямую в интернет. Как можно реализовать такую задачу?

Запросы бывают разных типов. И прокси, соответственно, тоже бывают разных типов. "Дать интернет через прокси" невозможно.
Ещё раз: определись с задачей. И сформулируй, потому что лично мне она пока непонятна. Слишком много надо додумывать, а это неправильно.

Святослав
2016.02.17 18:46:56
#cid91397

Ответить

Статья по теме ограничения параллельных соединений в Iptables https://shneider-host.ru/blog/iptables-ogranichenie-kolichestva-parallelnyh-soedineniy-k-serveru-dlya-odnogo-ip.html

Станислав
2016.04.10 19:29:05
#cid91486

Ответить

Здравствуйте.
Передо мной стоит задача, осуществить перенаправление с одного ipv4 по разным портам на ipv6.
Так, что бы по каждому разному порту, на выходе был разный ipv6.
Подскажите, пожалуйста, где можно прочитать инфу по данному вопросу или как осуществить такой финт?)
Спасибо заранее

2016.04.11 03:27:43
#cid91487

Ответить

#cid91486, Станислав

Передо мной стоит задача, осуществить перенаправление с одного ipv4 по разным портам на ipv6.

Похоже, это две задачи:
— переделать ipv4 в ipv6
— сделать перенаправление на нужные ip

Конкретнее сказать не могу, никогда такое не делал на практике.

imen
2016.04.19 13:17:19
#cid91504

Ответить

Кстати, вторая ссылка тоже того… кончилась.

2016.04.19 20:23:24
#cid91505

Ответить

#cid91504, imen

Кстати, вторая ссылка тоже того… кончилась.

Хе хе хе. А мы ещё живы.
Ну и с первой ссылкой тоже ничего не должно случиться, а она главная.

Саня
2016.04.20 15:51:03
#cid91506

Ответить

Спасибище!

2016.04.20 23:06:08
#cid91507

Ответить

#cid91506, Саня

Спасибище!

Скоро будет больше, в том числе и про MikroTik!

imen
2016.04.21 09:25:54
#cid91508

Ответить

#cid91505,

Ну и с первой ссылкой тоже ничего не должно случиться, а она главная.

Сколько можно предупреждать о мурзилочной сучности опеннета?!?

Не говоря про ссылки на левые (первые попавшиеся) ресурсы, она была obsolete ещё во времена, когда я начинал разбираться с фильтрацией сетевых пакетов в Linux.
При этом в лучших традициях Культуры ресурса не то, что описания *правильной* методики нет, но хотя бы указания на неё.

О хотя бы флагах актуальности (доку постигла обычная судьба фундаментальной документации) не говорю.
Смотрим на даты:
Переведённая версия 1.19 — 21 мая 2003
Последняя 1.2.2 — 20 ноября 2006
http://freecode.com/projects/iptables-tutorial (когда-то freshmeat.net)

ЗЫ: Планирую попробовать сочинить *правильное* описание *базовой* теории.
Действительными *первоисточниками* (RTFM на предмет гугля vs стандартной справочной подсистемы Unix) являются:
man 8 iptables
man 8 iptables-extensions

droom
2016.05.31 11:43:34
#cid91556

Ответить

Подскажите как решить задачку, есть 2 инет канала eth1 и eth2 ну и локалка eth0 все ходят через прозрачный сквид на eth1
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.20:3128
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A INPUT -p tcp --dport 80 -j ACCEPT
-A FORWARD -i eth1 -p tcp --dport 80 -j ACCEPT
-A FORWARD -i eth0 -p tcp --dport 80 -j ACCEPT
так вот в iptables eth2 нигде не прописан, как можно указать клиенту с определенным адресом ходить именно на eth2 в инет?

просто видеонаблюдение берется с инета, основной канал погибает от этого немного, хотел комп с видеонаблюдением прокинуть на резервный инет..
или это невозможно?

холодильщик
2016.05.31 19:44:07
#cid91557

Ответить

Помогите настроить доступ к веб камере, которая подключена к роутеру(openwrt)(внутренний адрес 192.168.1.1) и вещает на 8080 порту. роутер подключен к интернету через модем 4G и имеет соответственно серый ip адрес. На роутере поднят openvpn client до vpn servera(vpn ceть 192.168.10.1 255.255.255.0) работающего на ноутбуке(дебиан), который находится за другим роутером подключенным по оптике к билайну с динамическим ip адресом (xxx.dlinkddns.com) и с проброшенным портом 443 для vpn сервера.Сейчас я смотрю камеру запустив в смартфоне openvpn clienta и набрав в браузере 192.168.1.1:8080, а хотелось бы смотреть без запуска в смартфоне (или на любом компе) openvpn clienta, по адресу xxx.dlinkddns.com:8080. VPN Сервер поднят на ноутбуке а не непосредственно на роутере смотрящем в инетернет потому что vpn сервер грузит сильно роутер 2Mbit -90%.

2016.06.02 00:35:51
#cid91558

Ответить

#cid91556, droom

Подскажите как решить задачку, есть 2 инет канала eth1 и eth2 ну и локалка eth0 все ходят через прозрачный сквид на eth1
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.20:3128
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A INPUT -p tcp --dport 80 -j ACCEPT
-A FORWARD -i eth1 -p tcp --dport 80 -j ACCEPT
-A FORWARD -i eth0 -p tcp --dport 80 -j ACCEPT
так вот в iptables eth2 нигде не прописан, как можно указать клиенту с определенным адресом ходить именно на eth2 в инет?

просто видеонаблюдение берется с инета, основной канал погибает от этого немного, хотел комп с видеонаблюдением прокинуть на резервный инет..
или это невозможно?

Транзитный пакет идёт по такому пути:
PREROUTING → маршрутизатор → FORWARD → маршрутизатор → POSTROUTING

PREROUTING и POSTROUTING — это NAT, подмена адресов, относится к iptables.
FORWARD — это FILTER, межсетевой экран, тоже iptables

А вот между цепочками iptables проходит принятие решения о маршрутизации.
Где, собственно, и происходит передача определённого пакета в определённый интерфейс.

man route.

2016.06.02 01:21:40
#cid91559

Ответить

#cid91557, холодильщик

Помогите настроить доступ к веб камере, которая подключена к роутеру(openwrt)(внутренний адрес 192.168.1.1) и вещает на 8080 порту. роутер подключен к интернету через модем 4G и имеет соответственно серый ip адрес. На роутере поднят openvpn client до vpn servera(vpn ceть 192.168.10.1 255.255.255.0) работающего на ноутбуке(дебиан), который находится за другим роутером подключенным по оптике к билайну с динамическим ip адресом (xxx.dlinkddns.com) и с проброшенным портом 443 для vpn сервера.Сейчас я смотрю камеру запустив в смартфоне openvpn clienta и набрав в браузере 192.168.1.1:8080, а хотелось бы смотреть без запуска в смартфоне (или на любом компе) openvpn clienta, по адресу xxx.dlinkddns.com:8080. VPN Сервер поднят на ноутбуке а не непосредственно на роутере смотрящем в инетернет потому что vpn сервер грузит сильно роутер 2Mbit -90%.

Пробрось 8080 с xxx.dlinkddns.com до дебиана, а дебиан пусть пихает его в туннель до 192.168.1.1.
Т.е. сделай дебиан ещё одним, промежуточным, vpn-шлюзом.

холодильщик
2016.06.03 13:39:21
#cid91563

Ответить

Порт 8080 открыл до дебиана. Вот его ifconfig
eth0 Link encap:Ethernet HWaddr 00:1b:38:d0:a6:24
inet addr:192.168.5.101 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::21b:38ff:fed0:a624/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1955 errors:0 dropped:0 overruns:0 frame:0
TX packets:1972 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:313021 (305.6 KiB) TX bytes:347722 (339.5 KiB)
Interrupt:18

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:240 (240.0 B) TX bytes:240 (240.0 B)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.10.1 P-t-P:192.168.10.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:864 (864.0 B) TX bytes:864 (864.0 B)

route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.5.1 0.0.0.0 UG 1024 0 0 eth0
192.168.1.0 192.168.10.2 255.255.255.0 UG 0 0 0 tun0
192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.10.0 192.168.10.2 255.255.255.0 UG 0 0 0 tun0
192.168.10.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
у меня ступор. пакеты на дебиан пришли как я понимаю с назначением 192.168.5.101:8080. мне их надо пропихнуть сперва на 192.168.10.2? а как затем их отправить на 192.168.1.1?

холодильщик
2016.06.03 13:49:35
#cid91564

Ответить

Да,еще, роутер к которому подсоединена камера, имеет vpn адрес 192.168.10.6 может на него как то завернуть пакеты с 192.168.5.101:8080?

холодильщик
2016.06.03 14:05:02
#cid91565

Ответить

дал следующие команды:iptables -t nat -A PREROUTING --dst 192.168.5.101 -p udp --dport 8080 -j DNAT --to-destination 192.168.10.6
и iptables -I FORWARD 1 -i eth0 -o tun0 -d 192.168.5.101 -p udp -m udp --dport 8080 -j ACCEPT. Пишет в браузере сайт не позволяет установить соединение. Что я делаю не так?

imen
2016.06.03 16:08:45
#cid91567

Ответить

#cid91565, холодильщик

Что я делаю не так?

Твоя главная, *фундаментальная* ошибка в том, что ты решаешь задачу отладки пакетного фильтра без использования подсистемы журналирования.
И без хотя бы формулировки задачи на прокачивание базовых скиллов.

ЗЫ: Использование policy ACCEPT в Chain FORWARD — косяк статьи.

ЗЗЫ: Ты уверен, что соединение использует [*только*] протокол udp?

холодильщик
2016.06.03 19:35:03
#cid91568

Ответить

Изменил протокол openvp на tcp и настроил по https://m.habrahabr.ru/post/202278/. Все заработало.вот понять бы почему

iks
2016.08.12 10:45:36
#cid91643

Ответить

Спасибо автору за статью, сразу все заработало. Сколько сайтов и форумов перепробовал, ничего не выходило. Тут с первого раза.
Поскольку я начинающий, подскажите в цепочке FORWARD зачем стоит 1, без него тоже работает?

2016.08.17 21:13:02
#cid91646

Ответить

#cid91643, iks

FORWARD зачем стоит 1, без него тоже работает?

-A FORWARD ... — добавляет правило в конец цепочки FORWARD. Что не всегда хорошо, потому что выше по цепочке может быть другое правило, которое "перекроет" то, что мы хотим добавить. Поэтому для надёжности используем ключ "-I [цепочка] N ...", который сразу ставит новую запись на нужное место — в данном случае в начало.

Но по умолчанию N=1 и без явного указания тоже будет работать, да.

Vlad
2016.09.01 18:27:56
#cid91654

Ответить

Добрый день Всем.

Может кто подскажет как настроить роутер D-Link DSR-1000N для правильного прохождения пакетов на почтовый сервер без подмены IP-адресов клиентов?
Интересует как раз 25 и 143 порт. Есть WAN to LAN , WAN to DMZ , LAN to DMZ . Почтовик стоит в DMZ. Порты проброшены. Все работает, но в логах почтовика только 2 IP ... IP Lan шлюза и IP DMZ шлюза , а хотелось бы IP клиентов. Никак не могу настроить...
Может кто подскажет как по этим двум портам пускать пакеты без NATa?

Заранее всем спасибо...

server
2016.09.05 16:37:03
#cid91658

Ответить

Доброго времени суток. Ребята подскажите пожалуйста возможна ли не стандартная реализация с перенаправлением портов?
есть сервер ubuntu 14.04 который ловит все пакеты и раздает во внутреннюю сеть
есть ли возможность сделать так что пришедший пакет на адрес 192.168.1.1 (адрес сервера) по порту 80 перенаправлял во внутреннюю сеть но уже не по 80 порту одному а на несколько портов на разные адреса одновременно?
т.е пришел на 192.168.1.1 (80 порт) перенаправил на 10.0.0.1 (81); 10.0.0.2 (83); 10.0.0.3 (84); 10.0.0.4 (85);
а если возможна перенаправление 80 порта на несколько других портов во внутреннюю сеть на один адрес это конечно было бы шикарно. но я думаю так не получится. но первый вариант есть ли возможность так реализовать?
Заранее спасибо

Юрий
2017.06.22 13:55:50
#cid91873

Ответить

Спасибо, только ваша статья мне помогла :)

2017.06.22 22:05:55
#cid91874

Ответить

#cid91873, Юрий

Пожалуйста :)

Дмитрий
2020.09.07 13:45:41
#cid92348

Ответить

Не работают эти правила в случае если второй внутренний интерфейс поднимается по PPPoE (PPTP).