Re: проброс порта и доступ к проброшенному порту по внешнему адресу шлюза из локальной сети
Владимир Скубриев -> Debian-russian@lists.debian.org @ Fri, 06 Sep 2013 10:52:12 +0400:
>> ВС> Как правильно пробросить порт для доступа к проброшенному порту по внешнему
>> ВС> адресу шлюза из локальной сети.
>>
>> ВС> есть такое правило в фаерволе у меня
>>
>> ВС> iptables -A INPUT -d $INETIP -p TCP --dport 6480 -j ACCEPT
>> ВС> iptables -t nat -A PREROUTING -d $INETIP -p TCP --dport 6480 -j
>> ВС> DNAT --to-destination $EARTHVM:80
>> ВС> iptables -t nat -A POSTROUTING -d $EARTHVM -p TCP --dport 80 -j
>> ВС> SNAT --to-source $LANIP
>>
>> ВС> из вне, т.е. например с других мест работает проброс всегда работает
>>
>> ВС> но если из локальной сети(где стоит этот шлюз) пытаться зайти на внешний адрес
>> ВС> INETIP и порт 6480, то я не могу достучаться до веб сервера.
>>
>> ВС> причем что интересно, если на шлюзе запустить tpdump то в локальной сети с
>> ВС> клиентов все начинает работать.
>>
>> ВС> в чем подвох ?
>>
>> С виду все правильно. Ну, по классике, не хватает, конечно, правила для
>> nat в цепочку OUTPUT, но оно влияет только на попытки зайти туда с
>> самого шлюза, на клиентов из локальной сети не влияет.
ВС> А что это за правило ? Можно пример
Такое же, как, если не ошибаюсь, для PREROUTING. Идея в том, что пакет,
сгенерированный на самом шлюзе, не проходит цепочку PREROUTING, а
проходит вместо этого цепочку OUTPUT.
>> Вообще диагностика "если запустить tcpdump" заставляет заподозрить
>> глючный драйвер сетевки, шибко умный свитч, либо их взаимодействие. В
>> смысле, если результат в этой ситуации зависит от того, в promiscuous
>> mode стоит сетевка или нет, то вопрос в том, что обратные, вероятно,
>> пакеты то ли не доходят до сетевки шлюза, то ли не воспринимаются ею как
>> адресованные ей.
>>
>> При одном "если". Если последнее правило не содержит ошибок и успешно
>> срабатывает для клиентов из локальной сети (в смысле, ничем не
>> перебивается, поскольку само оно никаких отсылок к локалке не содержит).
>> С виду не содержит, а вот как на самом деле, во взаимодействии с
>> остальными правилами... Впрочем, "во взаимодействии" актуально для всех
>> трех правил и для маршрутизации вообще.
>>
>> Попробуй еще запустить tcpdump с -p и посмотреть, что будет.
>>
>>
ВС> 1.68 - это клиент ЛВС, который обращается к внешнему IP сервера
ВС> запустил с -p (т.е. без не разборчевого режима сетевой) ни чего не ходит,
ВС> т.е. правило
ВС> tcpdump -p -i br-eth0 'src port 80 and dst 192.168.1.68'
ВС> ни чего не показывает
Для начала - и не должно. Когда dst 1.68, src port должен уже быть 6480.
Этого мало для выяснения картины. Надо
(dst port 6480 and src 1.68) or (dst port 80 and dst $EARTHVM) - каждому
пакету с клиента на внешний адрес должен соответствовать
оттранслированный пакет на $EARTHVM
и аналогично с перестановкой dst и src, для возвращающихся пакетов.
Так, стоп. VM, говоришь? Не на самом шлюзе, часом? Если на самом, то
ты не тот адрес прописываешь в SNAT...
ВС> без -p все работает и tcpdump видит пакеты от приходящие к серверу.
ВС> по ходу надо сетевуху сменить и проверить, хотя там встроенная realtek 1Gbps
Reply to: