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

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

))

Пожалуйста!

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

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

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

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

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

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

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

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

понятно и со знанием написано. больше недели не мог ничего вразумительного найти
использовал скрипт с такими параметрами:
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) происходит,
скачивание файлов выполняется.
СПАСИБО !!!

Спасибо!!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да для полной кортины 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

Сдраствуйте

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

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

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

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

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

к примеру
$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" - гейт второго провайдера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вот интересно, если в локальной сети стоят два веб сервевра. Один на 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)
- выдавать страницы самостоятельно, опрашивая внутренние веб-сервера.

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

Подскажите по этой схеме проброс 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

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

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

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

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

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

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

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

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

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. Это абсолютно разные протоколы.

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

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

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

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

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

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

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

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

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

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

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

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

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

#cid10724, GMasta

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

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

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

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

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

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

#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 — тот самый внешний айпишник, которому разрешено пользоваться пробросом.

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

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

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

выход в инет идет через 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

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

#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".

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

# 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

#cid36725, ATAMAH

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

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

# tcpdump -i eth1

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

АбАлдеть....
после ребута всего и вся, снова дал:
# 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

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

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

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

#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.

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

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

-- 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

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

#cid36887, ATAMAH

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

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

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

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

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

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

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

#cid38112, Boba

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

Пожалуйста )

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

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

#cid37109, ATAMAH

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

Пожалуйста )

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

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

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

Есть два способа избежать подобной ситуации.
Первый - чётко разграничивать обращения к серверу изнутри и извне.
Создать в локальном 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, а клиентская ОС может на лету перестроить свою таблицу роутинга и посылать пакеты на сервер в обход шлюза.

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

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

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

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

#cid40143,

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

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

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

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

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

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

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

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

#cid40235,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#cid40607, Ямыч

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

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

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

#cid42105, adik

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

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

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

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

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

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

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

#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 написано для наглядности: показать, что это правило должно быть первым.

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

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

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

#cid42174, imen

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

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

#cid42215, adik

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

iptables -I FORWARD 1 -j LOG

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

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

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

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

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

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

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

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

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

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

#cid42274, imen

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

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

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

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

#cid42375, imen

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

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

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

#cid42382,

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

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

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

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

#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

добрый день. в линуксе совсем не давно закономерно возникают периодически вопросы на этот раз по 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 восьмым номером тут не указанным идет внешний адрес прова. Вот кажется полная картина!
возможно ли пробросить себя до внешнего интеренета и если да как это сделать . буду крайне признателен за любую помощь, так как поиск "незнаю чего" ни чего не дает.

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

#cid49611, msc

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

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

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

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

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

#cid49616, msc

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

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

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

#cid49618, msc

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

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

Добрый день.

Прочел описание (отлично кстати изложенное), добавил правила скриптом, но 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

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

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

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

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

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

#cid50162, Username

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

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

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

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

#cid50152, Андрей

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

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

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

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

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

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

# 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

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

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

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

#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 — надо смотреть, хз. Зависит от того, как реализован доступ сервера Б к локалкам.

#cid56226, xman

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

Согласный.

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

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

#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

#cid56793, CODer

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

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