Допустим, мы находимся в локальной сети и от внешнего мира отделены шлюзом под управлением 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-адрес клиента внутри локальной сети.
- сотрудник вводит в адресную строку браузера адрес webname.dom
- компьютер обращается к DNS и разрешает имя webname.dom в адрес 1.2.3.4
- маршрутизатор понимает, что это внешний адрес и отправляет пакет на шлюз
- шлюз, в соответствии с нашим правилом, подменяет в пакете адрес 1.2.3.4 на 192.168.0.22, после чего отправляет пакет серверу
- веб-сервер видит, что клиент находится в этой же локальной сети (обратный адрес пакета - 192.168.0.333) и пытается передать данные напрямую клиенту, в обход шлюза
- клиент игнорирует ответ, потому что он приходит не с 1.2.3.4, а с 192.168.0.22
- клиент и сервер ждут, ведут себя как «две целки на морозе», связи и обмена данными нет
Есть два способа избежать подобной ситуации.
Первый - чётко разграничивать обращения к серверу изнутри и извне.
Создать в локальном 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, достаточно набрать в консоли от имени суперпользователя:
Экономия времени и сил налицо.
Перенаправление портов
Перенаправление портов нужно в том случае, если мы хотим «замаскировать» внутреннюю службу, обеспечив к ней доступ извне не по стандартному, а совсем по другому порту. Конечно, можно заставить сам веб-сервер слушать нестандартный порт, но если он используется рядовыми сотрудниками внутри локальной сети, то мы элементарно столкнёмся с человеческим фактором. Сотрудникам будет очень тяжело объяснить, что теперь для доступа к корпоративному сайту надо после его имени вводить набор цифр через двоеточие.
Именно из-за человеческого фактора перенаправление портов используется, в основном, специалистами, для удалённого администрирования.
Пусть $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
По сути изменилась только первая строчка, поскольку только она отвечает за первичную обработку входящих пакетов. Дальше всё следует по стандартной процедуре таблиц и цепочек правил.
Изменения в остальных правилах сделаны для наглядности и их сути не меняют.
- Руководство по iptables (Iptables Tutorial 1.1.19)
- http://iptables-tutorial.frozentux.net/
- Таблица портов
Комментарии
vilfred
#cid214
Ответить
спасибо! при помощи статьи был жоско прохачен беспроводный модем cnu680pro
vilfred
#cid215
Ответить
собсно тут http://www.lor-ng.org/message.php?newsid=8020
#cid216
Ответить
))
Пожалуйста!
jetmind
#cid586
Ответить
Спасибо! Чуть ли не единственная адекватная статья по теме :)
Huntervp
#cid1385
Ответить
Долго мучалсо с пробросом портов пока не нашел эту статью, единственный адекватный ответ, а то все пересылать только куда то умеют, а по делу сказать ни чего умного не могут.
oermolaev
#cid1543
Ответить
столько ресурсов пришлось перелопатить прежде чем нашёл этот реально работающий материал!!!
СПАСИБО!
WowihaY
#cid1679
Ответить
Ну хоть что-то заработало! Спасибо за разъяснения, ибо iptables дремучий лес. А так ткнулся в скрипт, и ок!
#cid1680
Ответить
По первой ссылке в конце - отличный мануал по iptables.
Низзя запускать непроверенные скрипты с посторонних сайтов!!!
Vlad29
#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
#cid2066
Ответить
Спасибо!!!
Dmitii
#cid2614
Ответить
Спасибо за статью. Преподнес идеально! Молодец!
Михаил
#cid2778
Ответить
Спасибо. Всё подошло и работает.
Михаил
#cid2883
Ответить
Спасибо за статью , всё очень просто и понятно написано !
papont2007
#cid2904
Ответить
А вот у меня пока облом. И самое главное что в принципе это должно работать а ..... Рою.
Тебе бы в таком духе весь iptables расписать. Очень доходчиво и не обидно для тех кто что то знает но в некоторых местах сомневается. Я понимаю что это будет повторение HOWTO, но почему бы и нет с твоими коментариями.
#cid2923
Ответить
Это как у программистов: 5% потраченного времени занимает написание кода, а оставшиеся 95% — его отладка )
Весь iptables — это слишком круто. Но есть запись по его основам, в черновом варианте, пока недоступна для просмотра. Возможно, буду выкладывать по частям.
Не знаю, лично мне эта запись кажется слишком громоздкой и поэтому сложной для восприятия. Вношу исправления периодически.
Constantin
#cid3236
Ответить
Спасибо!!!Помогло.Отлично обьяснил.
zerg90
#cid3532
Ответить
Автору спасибо. сейчас на любой форум как не зайдешь все только пальцы гнут да в мануалы посылают.
Fleeseace
#cid4338
Ответить
Большое спасибо за помощь в этом вопросе.
Kurs
#cid4639
Ответить
Огромное СПАСИБО!!!
YuSV
#cid4750
Ответить
Спасибо, второй день мучаюсь, скрип работает под Дебиан 6.
Sergey95
#cid5624
Ответить
Сдраствуйте не могли бы вы мне помочь? у меня два прова НО! один работает через DHCP, а второй DHCP ->VPN как всё это настроить с нуля в командной строке?
Sergey95
#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
#cid5628
Ответить
Топрый теннь.
У вас два рабочих шланга в интернет. Откуда шлюз знает через который трафик гонять? Вот оно и отваливается.
А чтобы ничего не отваливалось — надо правильно прописать маршрутизацию. Или другим способом извращаться, всё зависит от целей.
Ищите в Яндексе «linux шлюз два провайдера». Это целый ряд задач, с разными решениями. Я в двух словах объяснить, к сожалению, не смогу.
Sergey95
#cid5634
Ответить
xexe в том то и дело что инструкций про DHCP провов нету!дык вот и прошу помощи
Sergey95
#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" - гейт второго провайдера.
#cid5664
Ответить
Проблема — не в этом. Сейчас попробую объяснить.
Просто представь, что у тебя оба внешних адреса, равно как и все остальные адреса — статические.
Как при этом должен работать шлюз? Как он будет решать, какие пакеты отправлять первому провайдеру, а какие — второму? Это будет разделение по внутренним айпишникам (например, чётные адреса одному, нечётные другому), или по службам (на основе порта назначения), или должно быть просто распределение нагрузки между провайдерами? Или один провайдер используется постоянно, а второй — резервный, который начинает работать только при обрыве доступа к первому?
Почему при подключении второго провайдера сеть пропадает вообще? Да потому, что шлюз не знает, что ему делать со всем этим хозяйством! С одним провайдером всё понятно: получили пакет из локалки, проверили фильтрами и кинули провайдеру. Но с двумя — как делить трафик? Из предоставленной информации это не ясно, а это — самый важный вопрос, который для шлюза надо разрешить.
То, что оба провайдера раздают адреса по DHCP — всего лишь нюанс, который, по сути, не имеет значения.
Разбей большую задачу на маленькие и решай их отдельно друг от друга, по очереди.
И начни с того, что представь свои адреса статическими, потому что после регистрации интерфейса в DHCP так оно и есть.
Sergey95
#cid5672
Ответить
ок я понял.помочь сможешь?прост дело в моей топологии сети,ну тут всё описывать не буду ес смож помоч ася378906051 (Sergey040195) skype
#cid5679
Ответить
Друг, без обид.
Ты думаешь, мне больше нечем заняться?
Sergey95
#cid5687
Ответить
я сказал если сможешь)_)
#cid5690
Ответить
Обрати внимание:
Цитата из моего первого ответа.
Sergey95
#cid5695
Ответить
"ряд задач" у меня это балансировка нагрузки на инет для внутрилокалки + раскидывание портов с VPNа на остальные сервы воуля!
iksigrikov
#cid6630
Ответить
Спасибо за понятные разъяснения =)
Михаил
#cid6637
Ответить
Огромное спасибо! С ходу все заработало! Все толково и понятно! А вот теперь можно попытаться и родные инструкции почитать
Andrey
#cid7357
Ответить
А вот интересно, если в локальной сети стоят два веб сервевра. Один на Linux а второй на Windows Asp. Как тогда к ним настроить проброс?
Например, ввел www.local-linux.com - попал на веб сервер Linux, а ввел www.local-windows asp.com попал на windows Asp
#cid7392
Ответить
Вариант 1: повесить сайты на разные внешние айпишники. И запросы к 80 порту для разных внешних адресов перебрасывать на разные внутренние.
Если провайдер дал единственный внешний адрес и взять ещё один не представляется возможным, то средствами iptables такая задача не решается.
iptables работает с сетевыми пакетами на низком уровне, а тут нужно будет читать HTTP-заголовки пакетов. Поэтому,
Вариант 2: поставить на шлюз веб-сервер. Или что-нибудь другое, что сможет слушать 80 порт, читать HTTP-заголовки и на основе них делать одну из следующих вещей:
- перенаправлять запросы (например, деля их по разным портам — 81 и 82, после чего их можно будет обработать iptables)
- выдавать страницы самостоятельно, опрашивая внутренние веб-сервера.
Первый вариант полюбому лучше.
ermak
#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
#cid8222
Ответить
iptables работает с пакетами, а не с данными в нём.
Я в том смысле, что ему всё равно что это за пакет и кому он предназначен. HTTP, FTP, OPENVPN — без разницы.
http://port.it-simple.ru/?search=vpn
Надо убедиться, что ответные пакеты тоже проходят нормально через фильтр FORWARD в iptables.
Чтобы проверить, уходят ли пакеты назад — можно использовать tcpdump на шлюзе.
Вобщем, надо проверять каждый шаг движения пакетов, сверяясь с логами.
ermak
#cid8236
Ответить
OPEN VPN соединился по порту 5001, но почему то сервер выдает такую строку на команду
sudo sockstat | grep 5001
root openvpn 7021 udp4 *:5001 *:* CLOSED
При этом от клиента пинги идут на внутренний ip OPENVPN сервера, на другие компьютеры той же подсети что и OPENVPN сервер пинги не идут.Так же пинги идут в обеих направлениях и от сервера и от клиента на их виртуальные IP,т.е они пингуются взаимно.
Как думаете, проблема в маршрутизации?
Если OPENVPN соединился(так как порт теперь для него открыт),логично - ковырять iptables больше не нужно?
#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
Пинг — это ICMP пакет, OPENVPN работает у тебя на UDP, а правила iptables написаны для TCP. Это абсолютно разные протоколы.
Не, точно не в маршрутизации.
ermak
#cid8238
Ответить
Когда комент писал не изменил tcp на udp. В нат у меня прописан udp.
Значит этим же правилом нужно открыть icmp пакеты на этот порт?
#cid8239
Ответить
Нет, icmp вообще не нужен.
Надо удостовериться, что при подключении извне пакеты приходят на VPN сервер и после этого копать его настройки.
http://bozza.ru/art-129.html
Да, и убедись, что FORWARD в обратную сторону разрешён! А то мало ли.
ermak
#cid8348
Ответить
Как раз на VPN сервер пакеты из вне идут, могу даже подключаться к его RDP и SSH порту, а вот в сеть пакеты не идут.
А FORWARD разрешил таким правилом iptables -A FORWARD -p UDP --dport 5001 -j ACCEPT
Грызу мозг, а мысли не идут)
nur
#cid8502
Ответить
у меня скрипт не заработал, может потому что интерфейс один?
и как вообще быть в этом случае?
#cid8543
Ответить
Для начала неплохо бы понять — что ты вообще хочешь сделать?
egojob
#cid8900
Ответить
Мучился 2 дня с adsl модемом dlink 2500u. Твоя статья помогла. Спасибо
GMasta
#cid10724
Ответить
Статья хорошая, но с одним не согласен )
POSTROUTING во внутрь - убивает всякую возможность увидеть реального клиента (или злоумышленника) на внутреннем сервере и нужно только если не верно настроен роуте.. Не говоря уже о более сложных задачах например использования почтовых серверов..
Если кто то побывает у вас.. то после уже концов не найдешь.. В логах будет смотреться что нас взломал наш роутер ;)
#cid10808
Ответить
#cid10724, GMasta
Была задача обрисовать — по возможности — все нюансы проброса, но без лишних оговорок и уточнений. Для новичков.
Вроде получилось.
Справедливости ради надо сказать, что лично я POSTROUTING тоже никогда не ставлю — не вижу смысла.
Внутренние службы (локалка-локалка) идут мимо роутера. Внешние (инет-локалка) не нуждаются в этой записи. А общие службы надо располагать в DMZ, так правильнее.
Дык в логах сервера оно по любому так будет смотреться. Вне зависимости откуда взломали — изнутри или снаружи (если взламывали через проброшенное соединение). Поэтому надо смотреть логи роутера, в которых пакеты типа "из локалки в локалку" тоже должны быть учтены.
Nite
#cid12773
Ответить
Нельзя ли расписать правила для случая, когда проброс разрешен не всему интернету, а только определенному внешнему ip адресу (фиксированному)?
#cid12782
Ответить
#cid12773, Nite
Для фильтрации пакетов в 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
#cid12899
Ответить
Спасибо :) Полезная инфа.
Ivan
#cid19469
Ответить
Огромное спасибо!
ATAMAH
#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
пожалуста, помогите правильно завернуть, или настроить...
#cid36657
Ответить
#cid36640, ATAMAH
А зачем пинговать через интерфейс 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
#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
#cid36765
Ответить
#cid36725, ATAMAH
Извиняй, я не могу посмотреть на месте что и как, поэтому все мои советы носят сугубо теоретический характер.
На eth1 поступают правильные пакеты, но это и так очевидно.
Тебе нужно проверить, уходят ли они куда нужно, т.е. на tap0 интерфейс.
ATAMAH
#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
#cid36829
Ответить
рано радовался :(
работает только в одну сторону, т.е. я могу звонить, а мне нет...
АТС говорит:
-- Registered SIP '123' at 192.168.2.123:5060
получается, когда мне звонят атс шлет звонки на 192.168.2.123, а такой подсети в локалке нету..., как быть?
#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
#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
не пойму как и где правила писать :(
#cid36897
Ответить
#cid36887, ATAMAH
Правила не помогут до тех пор, пока АТС будет считать, что SIP зарегистрирован по левому (для неё) адресу.
Есть смысл смотреть настройки аналогового шлюза.
Походу, он для обратного соединения почему-то даёт АТС-ке адрес 192.168.2.123, который находится за NAT-ом на твоей машине и о котором АТС-ка вообще не знает и не должна знать.
Можно попробовать вообще изменить всю схему подключения, а то она какой-то диковатой получилась.
Например, можно соединить tap0 и eth1 мостом.
Но лично я бы сначала, всё-таки, разобрался, почему не работает текущая схема, где в ней ошибка.
ATAMAH
#cid37109
Ответить
йё-хо! :)
с мостом получилось как надо!
Спасибо!
ты, всетаки, про пиво подумай ;)
Boba
#cid38112
Ответить
Спасибо большое !!!
Из 18 статей твоя первая, которая заработала. Очень ценные пояснения. Пиши, пожалуйста еще!
#cid38113
Ответить
#cid38112, Boba
Пожалуйста )
Дык — и так уже дохрена написано. Отсортировать бы то что есть, для удобного поиска. Этим сейчас и занимаюсь.
#cid38114
Ответить
#cid37109, ATAMAH
Пожалуйста )
Налива-а-ай!!! )
терм
#cid39033
Ответить
автору респект)
Илья Семенов
#cid40140
Ответить
Боже, до чего люди любят прикручивать системы костылей и подпорок вместо того, чтобы немного подумать головой.
Вся "проблема" решается так:
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, а клиентская ОС может на лету перестроить свою таблицу роутинга и посылать пакеты на сервер в обход шлюза.
#cid40143
Ответить
#cid40140, Илья Семенов
За вариант решения — спасибо!
Но чем оно качественно лучше описанных?
По сравнению со стандартным решением (второй способ) — добавляются "лишние" алиас и маршрут.
Илья Семенов
#cid40232
Ответить
#cid40143,
1) в логах веб-сервера остаются настоящие внутрение IP-адреса клиентов, а при способе с DNAT - всегда внутренний IP-адрес шлюза.
2) если клиент динамически перестраивает роутинг, то трафик не гоняется через шлюз (правда, не всегда это работает)
Но, я, кстати, был не прав. Мой способ работает, когда в наличии есть несколько внешних IP, и нужно целиком пробросить какой-то IP через шлюз на внутренний сервер. Если внешний IP только один, а пробрасывать нужно отдельные порты, то просто через ip route это не решается.
#cid40235
Ответить
#cid40232, Илья Семенов
То же самое делает первый способ (который, кстати, я и предпочитаю). Трафик чётко разграничен, во внутренних соединениях шлюз не участвует, корректирующей записи в iptables (того самого костыля) нет вообще. Всё предельно надёжно, ничего лишнего.
Не, ну как вариант решения какой-то частной проблемы — имеет право на существование. С определённой доработкой.
Но, честно говоря, после такого яркого вступления про костыли и подпорки я ожидал чего-то более революционного. ;)
Илья Семенов
#cid40263
Ответить
#cid40235,
Ничего лишнего?? Каждую зону хранить на DNS-сервере в двух экземплярах и постоянно синхронизировать в этих копиях изменения - это ничего лишнего? А если DNS-сервера некоторых доменов вообще где-то снаружи под внешним управлением??
Я почему оставил комментарий - только вчера выбросил из DNS весь split horizon, надоело поддерживать этот мрак. Одна запись в таблицу роутинга на шлюзе, один алиас при инициализации интерфейса на веб-сервере - всё, все счастливы и довольны.
Илья Семенов
#cid40266
Ответить
Да, ещё со split horizon есть (была?) проблема с кешированием DNS-записей на ноутах. Приехал на работу - открыл сайт, он отрезолвился во внутренний IP. Закрыл ноут, приехал домой, открыл ноут - продолжить работать с сайтом просто так нельзя. Правда, почему-то я с этой проблемой перестал сталкиваться последнее время: возможно, с какой-то версии OS X при смене точки доступа стала автоматически очищать кеш DNS. Как с этим в других ОС - не знаю.
#cid40280
Ответить
#cid40263, Илья Семенов
Как бы, изначально в заметке говорится именно о локальном DNS, который не виден снаружи. И лично я твёрдо убеждён, что такой DNS должен быть в любой сети в обязательном порядке, хотя бы ради кэширования запросов. А если DNS-ов несколько, то синхронизация между ними должна происходить в автоматическом режиме.
Честно говоря, я не понимаю, в чём проблема. Ну не вижу я связи между справочником DNS и проблемами маршрутизации в сети.
#cid40266, Илья Семенов
Ну, это — опять всё в кучу...
:) Можно почитать тут: Очистка кэшей сетевых адресов
Ямыч
#cid40607
Ответить
Доброго времени суток!
После прочтения кучи статей и мануалов по iptables в голове каша... а хочется результата уже сейчас, поэтому прошу совета.
Задача: с домашнего компа получить доступ к внутренним ресурсам корпоративной сети (1с, шара) — 192.168.0.0/24
Дано: маршрутизатор (192.168.1.1) на openwrt + домашний комп (192.168.1.2).
На маршрутизаторе поставил и настроил openvpn — корпоративные ресурсы пингуются. А вот с локального компа нет.
Понимаю, что это делается в таблице nat с помощью FORWARD, но четкой картинки к сожалению нет... (
#cid40634
Ответить
#cid40607, Ямыч
iptables настраивается на корпоративном шлюзе, для входящих соединений. Для исходящих соединений на домашнем роутере его настраивать не надо. Вернее, надо, но это совсем-совсем-совсем другое.
adik
#cid42105
Ответить
Доброго времени суток. Помогите пожалуйста решить проблемку.
Суть такова, имеется два пк на деби,шлюз и сервер кс соединены через свич,интернет поднят - l2tp - раздается, полет нормальный
Стоит dhcp и dnsmasq, вроде все настроенО)
Нужно вывести сервер в интернет, тоесть открыть порты, сделать проброс там...
Пытался по этой статейке - но чет не получается. сервер не видно
#cid42116
Ответить
#cid42105, adik
Шлюз соединён с интернетом через определённый интерфейс.
На сервере КС открыт определённый порт, или набор портов.
На шлюзе необходимо пробросить соединения, входящие на определённый интерфейс и на нужные порты. Пробросить до сервера КС.
Эта заметка (внимание!) как раз и рассказывает о том, как это сделать.
l2tp, dhcp, dnsmasq и модель свича — не имеют абсолютно никакого значения.
Имеют значение: 1) название внешнего интерфейса на шлюзе; 2) внешний IP шлюза; 3) внутренний IP сервера; 4) Набор портов, которые надо пробросить.
adik
#cid42139
Ответить
eth0 - сеть внешняя
eth1 - сеть внутреняя
ppp0 - интернет
Внешние адреса 10.136.xx.xx и 95.31.xx.xx
Шлюз 192.168.0.100
Адрес сервера 192.168.0.105
Порты 27010,27015,27016
Прошу помощи)
#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
#cid42171
Ответить
вот я делал что то похожее.. но даже с этими правилами сервер не доступен из интернета и внешней сети :( в этом то и проюлемма. сервер доступен тока в локальной сети ( моей )
imen
#cid42174
Ответить
Стандартный вопрос: что на этот счёт говорит журнал пакетного фильтра (на этапе тестирования категорически показана запись в журнал ВСЕХ отвергаемых, а иногда и некоторых пропускаемых, пакетов)?
adik
#cid42215
Ответить
#cid42174, imen
Прошу прощения. но я не так давно начал юзать деби. да и вообще ось линевскую...
Как или где посмотреть?))
#cid42218
Ответить
#cid42215, adik
iptables -I FORWARD 1 -j LOG
Лог лежит по адресу /var/log/syslog. Прочитать можно с помощью утилит dmesg, syslogd и др.
И будь внимателен: лог будет расти ОЧЕНЬ быстро. Включи, потестируй и отключи.
Также не помешает проследить путь внешних пакетов через шлюз утилитой tcpdump (наблюдать каждый интерфейс по отдельности).
Но перед всем этим действом — убедись, что:
1) Приведённых портов достаточно для функционирования сервера КС.
2) Другие правила iptables не конфликтуют с твоим пробросом.
imen
#cid42273
Ответить
Сначала настроить.
Например http://ru.gentoo-wiki.com/wiki/Пакетный_фильтр_Linux (настройка журналирования пакетного фильтра описана в разделе 3.2).
Писать в журнал последовательно по шагам (чтобы определеиться начиная с которого проброс перестаёт работать).
Ну и отказы (кроме разве что стандартного флуда альтернативной ОС) полезно писать в журнал ВСЕГДА.
imen
#cid42274
Ответить
Интересный тезис.
Сервер с ненастроенной подсистемой журналирования суть нонсенс.
Начиная понимать причину популярности FreeBSD...
dmesg - сообщения ядра.
syslogd - собственно демон, пишущий централизованный журнал (но достаточно популярна ситуация, когда приложение пишёт свой журнал самостоятельно, в локальный файл).
Для _чтения_ же (и поиска) журналов есть более подходящие утилиты: more/[z,bz,]less/[z,bz,]grep.
#cid42290
Ответить
#cid42274, imen
dmesg и syslogd рекомендованы в мане iptables.
А насчёт пути к системному журналу — надо понимать: adik настраивает iptables, но при этом не может отследить путь сетевого пакета. С огромной вероятностью логи у него лежат в /var/log/syslog.
imen
#cid42375
Ответить
net-firewall/iptables-1.4.13
В тексте стрнаицы руководства упоминание syslogd не обнаружено.
По сути: dmesg - утилита для чтения сообщений ядра.
syslogd - стандартный демон. Если кто-то предпочитает иное решение, то автоматически предполагается, что он знает _почему_ это делает и как настраивать выбранный им инструмент.
#cid42382
Ответить
#cid42375, imen
Первая ссылка в конце заметки:
Руководство по iptables (Iptables Tutorial 1.1.19)
«LOG -- действие, которое служит для журналирования отдельных пакетов и событий. В журнал могут заноситься заголовки IP пакетов и другая интересующая вас информация. Информация из журнала может быть затем прочитана с помощью dmesg или syslogd либо с помощью других программ.»
imen
#cid42482
Ответить
#cid42382,
Особенности (и следствие) проблемы перевода.
syslogd упомянут как стандартный (generic) демон.
Если используется что-то отличное - см. замечание выше.
vel
#cid43051
Ответить
помогите написать правило для зеркалирования трафика на другой порт
грубо говоря через сервер выходят в интернет, нужно исходящие данные зеркалировать на другой порт для их обработки, а сами пользователи интернета все так же пользовались им и у них все грузилось.
#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
Питер
#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
#cid49611
Ответить
Спасибо все работает. только как сделать что бы лановская машина определяла ip клиента
а то определяет адрес шлюза если люди заходят в твою сеть;((((((
#cid49612
Ответить
#cid49611, msc
Никак, таков механизм NAT.
Чтобы определять ip клиента надо либо сопоставлять логи сервера с логами шлюза, либо менять структуру доступа к серверу.
msc
#cid49616
Ответить
хорошо как менять? куда капать? что делать?
msc
#cid49618
Ответить
что скажете по поводу pfsense? он подойдет?
#cid49624
Ответить
#cid49616, msc
Либо обеспечить доступ к серверу извне, без NAT (выделить айпишник / поставить на шлюз / сделать прокси на шлюзе), либо сопоставлять логи сервера и шлюза.
К чему доступ-то делаем? Что за сервер?
#cid49618, msc
Не знаю. Вряд ли.
Гость
#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
С такими настройками доступ возможен только из локальной сети, во внешнюю сеть, а обратно никак. Подскажите, что можно подправить?
Андрей
#cid50152
Ответить
Блин, подключение к файлохранилищу из из локальной сети окончательно пропало, заподозрил подвох.., сходил на верх, лично посмотреть, что с ним. Оказалось полчаса как полку с ним уронили... не рассчитали нагрузку. Но ничего, воткнул питание, зафырчало. Обошлось без потерь.
Проверил доступ. Из внешней сети по ftp доступ есть, но только в пассивном режиме:
227 Entering Passive Mode (192,168,0,203,195,80).
Хотя внутри локальной сети, работает и в активном. Настройки те же, что писал выше.
Username
#cid50162
Ответить
Толково, просто и по делу. Автор молодец, спасибо! Единственное адрес 192.168.0.333 изменить бы в тексте, а то 333 как то глаз режет своей нереальностью =)
#cid50222
Ответить
#cid50162, Username
А-а-а! Камрад! Как я долго тебя ждал!
Три года заметке, сто комментариев. В остальных заметках, где нужны примеры адресов, 333-й тоже фигурирует.
Ты — первый, кто обратил внимание.
Написал специально, ради смеха. Так веселее читать. Менять не буду :)
#cid50225
Ответить
#cid50152, Андрей
Надо разбираться в особеностях работы FTP, с вмысле как происходит подключение в активном и пассивном режимах, пошагово. И как каждый шаг согласуется с правилами iptables.
Сходу ничего толкового сказать не могу, извиняй.
Как разберусь — вывешу отдельную заметку, а сюда добавлю ссылку.
Андрей
#cid50485
Ответить
Спасибо, буду ждать, ибо неделю бьюсь, никак не дается чертяка..
Андрей
#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
#cid55712
Ответить
Спасибо огромное !!!
xman
#cid56226
Ответить
Полезная заметка, но есть важное замечание.
Если для локальных клиентов организуется доступ к веб через шлюз (т.е. с применением SNAT), то в правиле для POSTROUTING/filter необходимо указать критерий -s 192.168.0.0/24, тем самым ограничив действие правила только для локальной сети, иначе преобразованию SNAT подвергнутся пакеты от внешних клиентов (из Интернет) и в логе веб-сервера будет регистрироваться адрес шлюза, а не ip клиента из Интернет.
CODer
#cid56272
Ответить
#cid42142
Помогите пожалуйста разобраться в проблеме:
существует игровой сервер А, в локальной сети №1 доступный по ип 555.555.555.555:5555, необходимо провести доступ к этому серверу по ип 444.444.444.444:5555 из локальной сети №2 через другой сервер Б у которого имеется доступ к обоим локальным сетям, то есть пользователи имеющие локальную сеть №2 заходя на сервер Б подключались на сервер А. Как бы это все правильно написать в правило?:)
#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 — надо смотреть, хз. Зависит от того, как реализован доступ сервера Б к локалкам.
#cid56633
Ответить
#cid56226, xman
Согласный.
Ровно по этой же причине предпочитаю делать доступ к внутренним веб-серверам через локальные DNS, а не через iptables. Тогда необходимость в правиле POSTROUTING пропадает. Собственно, как и проблема в целом: в логах будут правильно отображаться как внутренние, так и внешние адреса.
Думаю, как добавить информацию в основную заметку, не загромождая её.
CODer
#cid56793
Ответить
#cid56632,
что то не выходит, добавляя данное правило с сети №2 так никто и не видит сервер... вот более конкретные данные:
ip сервера А локальной сети №1 - 10.101.16.67
ip сервера B локальной сети №1 - 10.100.113.201 (надо было бы указать сразу, что есть такой ип:))
ip сервера B локальной сети №2 - 10.11.52.56
это все через порт 7777
#cid56950
Ответить
#cid56793, CODer
Является ли сервер Б шлюзом между локалками №1 и №2?
Доступна ли локалка №2 с сервера А напрямую, в обход сервера Б?
Никита
#cid63510
Ответить
Автор статьи просто красавец.
В интернете полно инфы как это сделать, но нифига не работает, только этот скрипт заработал из коробки.
Выражаю благодарность.
Alexandr(gastu@mail.ru)
#cid86854
Ответить
Здравсвтуйте. У меня есть vps на cent os со статическим ip и есть сервер дома с динамическим. Сервер подключен по впн к линуксу. Почитав ваш пост все стало понятно, вроде теперь я могу сделать проброс портов, и неважно если мой динамический айпи поменяется. Но вот как мне выдать внутреннюю статику для этого сервера на винде при подключении?
хочу сделать что-то типа динамик днс
gastu@mail.ru
#cid86999
Ответить
#cid86854, Alexandr(gastu@mail.ru)
Вопрос не имеет отношения к заметке. Возможно, проброска порта была необходима, чтобы достучаться до VPN-сервера, но только и всего. После установки VPN соединения клиентский компьютер (или клиентская подсеть) начинает прозрачно видеть удалённую подсеть. Задача с выдачей внутренних адресов решается совсем отдельно, в рамках этой единой прозрачной сети.
Можно так, можно привязать к MAC-адресу, можно вручную прописать. Как угодно.
Это совсем другая задача, нельзя мешать всё в кучу.
argus
#cid87102
Ответить
Спасибо! единственная рабочяя статья попалась. проманался с ssh тунелями, но этот пост проще оказался.
#cid87127
Ответить
#cid87102, argus
SSH-туннели тоже рулят!
marat4net
#cid88486
Ответить
Огромное спасибо за материал!
alemaan
#cid89084
Ответить
Большое спасибо, все просто и понятно)
Vadim_d67
#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
#cid89389
Ответить
#cid56950,
1 вопрос - скорее нет чем да, честно говоря не совсем понял вопрос)
2 вопрос - локальная сеть №1 сервера А (10.101.16.67) не доступна локальной сети №2 сервера Б (10.11.52.56), а доступна локальной сети №1 сервера Б (10.100.113.201)
Valera
#cid89546
Ответить
подскажите, а как пробросить к примеру rdp на две машины ???
#cid89547
Ответить
#cid89546, Valera
Посади на разные порты. Например, 33891 — первый комп, 33892 — второй (смотри «Перенаправление портов»).
И подключаться с явным указанием конкретного порта для подключения: "[ip-адрес]:[номер_порта]".
Valera
#cid89548
Ответить
#cid89547,
Ну про такой способ я подумывал, но думал может можно как то и по другому можно решить.
#cid89553
Ответить
#cid89548, Valera
У входящего пакета есть всего 3 критерия для нужного отбора: IP_источника, IP_назначения и порт_назначения.
IP_источника. Можно и нужно использовать, когда удалённый адрес не меняется. Этим убивается сразу несколько зайцев: 1) доступ ограничивается только для конкретного внешнего IP, это хорошо для безопасности; 2) не нужно менять порт для входящего подключения, для неопытных пользователей это может быть удобнее; 3) разные внешние IP при этом можно заассоциировать с разными внутренними машинами.
IP_назначения. Можно использовать, если у конторы есть целый пул лишних адресов. Но адресов IPv4 сейчас дефицит, и лично не представляю себе я такую ситуацию. "Лишним" адресам всегда найдётся лучшее применение.
Порт_назначения — можно использовать всегда. Для пущей безопасности, чтобы не светить порт всему инету, доступ можно сделать только для нескольких конкретных IP. То есть, это универсальный способ — и гибкий, и достаточно надёжный.
То есть, выбор существует. И иногда не только можно, но и нужно делать по-другому.
marat4net
#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
#cid89601
Ответить
дык, ты ж мануал написал для людей не очень в этом сображающих )
у меня был случай - клиент пытался требовать ип 777 )))
для новичков спасибо, но блин у меня стоит задача видеть реальные ипы на веб-сервере, можно мануал подправить в эту сторону? )
а то я еще не мегоодмин :\
Дункан Макдак
#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 не попасть...
Дункан Макдак
#cid89604
Ответить
как-то два дня бился с настройкой роутера у клиента. ну вот вижу сеть по tcpdump, а никуда не пускает, хоть тресни!
на второй день в техподдержке таки взял трубку не мальчик, но админ.
хрюкая от смеха, он рассказал мне, что оператор, вчера прописывавший MAC-адрес роутера под мою диктовку вместо 2D записал 2T...
nur
#cid89605
Ответить
имхо в провайдинге фильтрация по макам уже устарела, недаром же более распространена парольная аутентификация, например pppoe
фильтр по макам еще можно применить в отдельном единственном офисе, где админ может придти ногами и настучать юзеру по шапке за смену мака
а в твоем примере выше ты показал не всё, во первых кроме iptables -L надо бы показать iptables -L -t nat
а во вторых, можно еще добавить ключ -n , там просто отображение понятнее-равномеренее, с одними цыфарками
#iptables -nL
#iptables -nL -t nat
#cid89608
Ответить
#cid89601, nur
Все пакеты, прошедшие через NAT, дальше идут от имени шлюза. Так устроен NAT.
В комментах уже был подобный вопрос.
Тогда веб-серверу надо давать реальный IP и выставлять наружу.
Или сопоставлять логи сервера и шлюза, но это чудовищный гемор.
Это ж другое. К данному мануалу не относится.
imen
#cid89614
Ответить
#cid89608,
Почему?!?
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'ы) и интересует кто на какой ходит?
Это да.
Но достаточно часто к решению задачи можно идти сильно разными маршрутами.
#cid89616
Ответить
#cid89614, imen
Круто.
Расскажи в двух словах, как оно берёт реальный айпишник клиента из шлюза?
Гость
#cid89642
Ответить
#cid89608,
верно, но... такая схема уже работала, на центос (который линух, и в котором редиректить можно иптаблесом. например такое еще умеет redir, но он точно не умеет ип передавать)
жаль я не удосужился спросить как
а еще до этого я сам такое делал на фрибсд, там вообще элементарно - две строки в конфиге ipnat
насколько я слышал чтобы такая схема работала, веб сервер должен находиться в одной подсети с рутером (на котором нат)
#cid89653
Ответить
#cid89642, Гость
Многие видели, что это — принципиально возможно, у кого-то даже работает на практике, но никто не признаётся, как именно это реализовано :)
Сдаётся мне, в таком решении iptables играет очень второстепенную роль.
imen
#cid89656
Ответить
#cid89616,
Физику сети здесь держу не я.
За полный цикл не копенгаген и вполне согласен с твоим мнением о том, что в данном решении используется не столько iptables.
Однако есть мнение, что если проброс осуществляется маршрутизатором (который default route), то достаточно переписать адрес хоста назначения для входящих пакетов, и соответственно источника для исходящих.
Не трогая адреса клиента.
Как это делается (и вообще: можно ли это сделать) средствами iptables — честно скажу: не знаю.
marat4net
#cid89657
Ответить
Откликнетесь, если я неправильно настроил для ситуации, когда клиент подключается из локальной сети:http://www.it-simple.ru/?p=2250#cid89571
#cid89659
Ответить
#cid89657, marat4net
#cid89571, marat4net
Для таких задач всегда рекомендую настраивать локальный DNS.
Это честное слово очень, очень, очень сильно облегчает жизнь.
И пакеты ходят как надо, а не раком через Киев.
SMTP: Если пакет пришёл на локальный интерфейс шлюза, а в его пункте назначения прописан локальный адрес почтовика (как это возможно в штатной ситуации?) то переписываем адрес назначения на локальный адрес почтовика (то есть, ничего не делаем).
Зачем это? Какую роль выполняет это правило?
IMAP: Делаем то же самое. То есть — генерируем порожняки для несуществующей ситуации.
IMAP и SMTP: Если почтовый пакет пришёл на внешний интерфейс шлюза и в его пункте назначения прописан внешний адрес шлюза, то переписываем адрес назначения на локальный адрес почтовика.
Здесь всё вроде нормально, но про службу POP3 (110 порт) и шифрованное соединение можно забыть. Странно, что по твоим словам подключения из интернета идут без проблем.
Здесь вроде всё правильно, но опять же:
- если шлюз не является почтовым клиентом, то правила OUTPUT не нужны;
- если в сети поднят локальный DNS и в нём переписаны MX-записи exmaple.com на локальные, то правила POSTROUTING не нужны и снимается ряд других возможных проблем;
- про POP3 и шифрование снова забыли.
Обеспечиваем возврат локальных пакетов через шлюз. Вроде всё нормально. POP3 и шифрование идут нахер.
Ну а это стандартная шлюзовая функция, не имеющая отношения к почте.
Наверное, ошибка в правилах FORWARD, которые здесь вообще не представлены.
Ты, вероятно, разрешил проход пакетов из интернета в локалку, но забыл, что пакеты из локалки в локалку тоже надо явно разрешать. Это частая ошибка.
#cid89660
Ответить
#cid89656, imen
В пакетах типа интернет-локалка, проходящих через NAT, меняется адрес назначения (это отражено в PREROUTING). Всё остальное остаётся без изменений. Далее пакет отправляется в маршрутизатор и тот отправляет его на сервер в локальной сети. Как результат — в логах сервера будет вписан внешний адрес клиента, и ответ пойдёт на этот адрес, то есть в default route, то есть через шлюз.
В пакетах типа локалка-локалка, принудительно идущих через шлюз, адрес внутреннего клиента подменяется на адрес шлюза. Логирование внутренних клиентов становится затруднено: все локальные подключения происходят от имени шлюза. Мы, как бы, говорим именно про эту ситуацию.
Именно поэтому я не устаю повторять:
Во всех сомнительных ситуациях для локальных соединений надо использовать внутренний DNS. Это лучше, чем заставлять идти пакеты через шлюз.
Во всех ситуациях надо чётко понимать что, как и для чего ты делаешь. Если ты этого не понимаешь — не делай этого.
Алекс
#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 может быть подключено несколько разных машин
Андрей
#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
#cid90487
Ответить
#cid90486, Андрей
Дык это ж то же самое, только упрощённый вариант.
Да, в подавляющем большинстве случаев достаточно единственной записи PREROUTING в "nat" и корректного разрешения FORWARD в "filter".
ivan
#cid90528
Ответить
Подскажите, как подключиться с локальной сети в которой веб сервер по внешнему ІР, то что в статье не работает.
NINJA2121
#cid90755
Ответить
подскажи момент один (я в линуксе полный ноль, а на новой работе шлюз на gentoo)
нужно разрешить из локалки во внешний мир порт хххх.
Заранее благодарен за отет.
#cid90756
Ответить
#cid90755, NINJA2121
Неправильная постановка вопроса.
"Порт" — это способ отличать сетевые пакеты разных типов, которые приходят на сервер. "Разрешить из локалки во внешний мир порт" — нельзя, можно разрешить внешнему миру подключаться к серверу и сетевой службе. IP определяет конкретный сервер, к которому идёт подключение, а порт — конкретную сетевую службу на нём.
Если служба работает на шлюзе, она уже слушает свой порт, и достаточно прописать разрешающее правило для входящих пакетов (таблица filter, цепочка INPUT).
Если служба работает на внутреннем сервере локальной сети — читай "проброс портов", там всё написано и достаточно подробно.
imen
#cid90757
Ответить
#cid90756,
Строго говоря, ты тоже можешь ошибаться.
Даже если не ставить вопрос о терминологии (оставим «службы» вместе с иконками самой распространённой ОС).
Из локальной сети доступ вовне обычно лимитирован (особенно этим славны боящиеся эксплуатируемых чёрных ящиков и не отличающиеся навыками работы с подсистемой журналирования вендоодменестраторы), в том числе по разрешённым сервисам (/etc/services) сети общего пользования. Характернейший, пример — smtp на стандартном порту (понятно почему). Или https (злободневно при необходимости работы с несколькими виртуальными хостами на одном IP–адресе, потому что осёл как минимум в старшей из доступных для «лучшей ОС майкрософта» версии не умеет работать с NameBased SSL Virtual Hosts).
Так что столкнуться с ситуацией, когда доступ с рабочей станции в ЛВС на некоторый нестандартный (или просто не понравившийся одмену) порт вовне (независимо от адреса узла) запрещён очень даже можно.
Примеров тому наблюдал достаточно. Последний — акурат на этой неделе.
Потому сначала нужно ставить вопрос о способе доступа из локальной сети в сеть общего пользования.
Ибо задачу, традиционно можно решать несколькими различными способами.
NINJA2121
#cid90758
Ответить
тогда сформулирую по-другому:
есть некий сервер с сервисом лицензирования MS Office за пределами нашего города (kms_srv)
наши клиентские машины не могут до него достучаться по порту 1688
есть VPN с серваком. при команде ping адрес показывает но при этом request timed out.
как посмотреть разрешения и вообще исправить ситуацию?
повторюсь, что в линухе полный ноль, но вот надо вникать, обещаю обучаться))))
imen
#cid90759
Ответить
#cid90758, NINJA2121
Сколько дурной и ненужной работы (не говоря о задействуемых ресурсах) включается в затраты производства.
Неполно.
Я конечно могу с достаточной степенью вероятия предположить использование транспортного протокола tcp.
Но в общем случае это неверно. Как раз вчера, разбираясь с монтированием NFS при включённом пакетном фильтре наблюдал пример.
Пакеты, надо полагать, должны ходить через 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 с рабочих станций.
#cid90765
Ответить
#cid90758, NINJA2121
Стучатся снаружи, по прямому адресу? Или через ВПН, о котором ниже?
Если пингуешь имя и высвечивается адрес — это означает всего лишь то, что нормально сработал DNS и в нём есть пингуемое имя. Не более того. С доступностью сервера (см. "request timed out") оно никак не связано.
Самое важное — разобраться, как (через какие узлы, по ВПН или нет и т.д.) ходят сетевые пакеты. Тогда станет понятно, какие узлы надо проверять на наличие блокировок. Пока — непонятно.
ваня
#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 не давал доступ.
#cid90792
Ответить
#cid90789, ваня
Должно работать. Проверь последовательность правил. Включи "-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 должен обрабатывать айпишники.
Моё такое мнение.
ваня
#cid90803
Ответить
Спасибо за быстрый и подробный ответ. Если способ решения проблемы — изначально неверный, как Вы писали, то еще как можно?
В общем у меня стоит такая задача: мне нужно фильтровать пакеты с содержанием domen.ru (берется из AD, имена_ПК.domen.ru). Если содержится domen.ru, то дать интернет через прокси, если нет-то напрямую в интернет. Как можно реализовать такую задачу?
#cid90804
Ответить
#cid90803, ваня
Я ж в конце кратко написал.
В подавляющем большинстве случаев достаточно заблокировать сайты на внутреннем DNS.
Определись с задачей. Тебе точно нужно именно это?
Интернет не ограничивается одним лишь вебом, а в сетевых пакетах содержатся не только имена сайтов. Ты можешь заблокировать не то, что хотел. А потом, когда возникнут непонятки, будешь долго искать причину "сбоя" и рвать волосы на попе.
DNS и DHCP которые идут с AD — адское говно. Использовать их можно только в самом крайнем случае, когда вообще без вариантов. Не используй их.
Поставь нормальный отдельный DNS (например dnsmasq, он шустрый и лёгкий в настройке), подцепи его к домену (чтобы нормально работал с AD) и радуйся жизни.
Запросы бывают разных типов. И прокси, соответственно, тоже бывают разных типов. "Дать интернет через прокси" невозможно.
Ещё раз: определись с задачей. И сформулируй, потому что лично мне она пока непонятна. Слишком много надо додумывать, а это неправильно.
Святослав
#cid91397
Ответить
Статья по теме ограничения параллельных соединений в Iptables https://shneider-host.ru/blog/iptables-ogranichenie-kolichestva-parallelnyh-soedineniy-k-serveru-dlya-odnogo-ip.html
Станислав
#cid91486
Ответить
Здравствуйте.
Передо мной стоит задача, осуществить перенаправление с одного ipv4 по разным портам на ipv6.
Так, что бы по каждому разному порту, на выходе был разный ipv6.
Подскажите, пожалуйста, где можно прочитать инфу по данному вопросу или как осуществить такой финт?)
Спасибо заранее
#cid91487
Ответить
#cid91486, Станислав
Похоже, это две задачи:
— переделать ipv4 в ipv6
— сделать перенаправление на нужные ip
Конкретнее сказать не могу, никогда такое не делал на практике.
imen
#cid91504
Ответить
Кстати, вторая ссылка тоже того… кончилась.
#cid91505
Ответить
#cid91504, imen
Хе хе хе. А мы ещё живы.
Ну и с первой ссылкой тоже ничего не должно случиться, а она главная.
Саня
#cid91506
Ответить
Спасибище!
#cid91507
Ответить
#cid91506, Саня
Скоро будет больше, в том числе и про MikroTik!
imen
#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
#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 в инет?
просто видеонаблюдение берется с инета, основной канал погибает от этого немного, хотел комп с видеонаблюдением прокинуть на резервный инет..
или это невозможно?
холодильщик
#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%.
#cid91558
Ответить
#cid91556, droom
Транзитный пакет идёт по такому пути:
PREROUTING → маршрутизатор → FORWARD → маршрутизатор → POSTROUTING
PREROUTING и POSTROUTING — это NAT, подмена адресов, относится к iptables.
FORWARD — это FILTER, межсетевой экран, тоже iptables
А вот между цепочками iptables проходит принятие решения о маршрутизации.
Где, собственно, и происходит передача определённого пакета в определённый интерфейс.
man route.
#cid91559
Ответить
#cid91557, холодильщик
Пробрось 8080 с xxx.dlinkddns.com до дебиана, а дебиан пусть пихает его в туннель до 192.168.1.1.
Т.е. сделай дебиан ещё одним, промежуточным, vpn-шлюзом.
холодильщик
#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?
холодильщик
#cid91564
Ответить
Да,еще, роутер к которому подсоединена камера, имеет vpn адрес 192.168.10.6 может на него как то завернуть пакеты с 192.168.5.101:8080?
холодильщик
#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
#cid91567
Ответить
#cid91565, холодильщик
Твоя главная, *фундаментальная* ошибка в том, что ты решаешь задачу отладки пакетного фильтра без использования подсистемы журналирования.
И без хотя бы формулировки задачи на прокачивание базовых скиллов.
ЗЫ: Использование policy ACCEPT в Chain FORWARD — косяк статьи.
ЗЗЫ: Ты уверен, что соединение использует [*только*] протокол udp?
холодильщик
#cid91568
Ответить
Изменил протокол openvp на tcp и настроил по https://m.habrahabr.ru/post/202278/. Все заработало.вот понять бы почему
iks
#cid91643
Ответить
Спасибо автору за статью, сразу все заработало. Сколько сайтов и форумов перепробовал, ничего не выходило. Тут с первого раза.
Поскольку я начинающий, подскажите в цепочке FORWARD зачем стоит 1, без него тоже работает?
#cid91646
Ответить
#cid91643, iks
-A FORWARD ... — добавляет правило в конец цепочки FORWARD. Что не всегда хорошо, потому что выше по цепочке может быть другое правило, которое "перекроет" то, что мы хотим добавить. Поэтому для надёжности используем ключ "-I [цепочка] N ...", который сразу ставит новую запись на нужное место — в данном случае в начало.
Но по умолчанию N=1 и без явного указания тоже будет работать, да.
Vlad
#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
#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 порта на несколько других портов во внутреннюю сеть на один адрес это конечно было бы шикарно. но я думаю так не получится. но первый вариант есть ли возможность так реализовать?
Заранее спасибо
Юрий
#cid91873
Ответить
Спасибо, только ваша статья мне помогла :)
#cid91874
Ответить
#cid91873, Юрий
Пожалуйста :)
Дмитрий
#cid92348
Ответить
Не работают эти правила в случае если второй внутренний интерфейс поднимается по PPPoE (PPTP).