Допустим, мы находимся в локальной сети и от внешнего мира отделены шлюзом под управлением 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