LINUX.ORG.RU
ФорумAdmin

пробросить порт

 


0

1

Есть шлюз с внешним интерфейсом например eth0 5.5.5.5 и внутренним интерфейсом eth1 10.10.10.254

На внешнем интерфейсе работает openvpn на порту 5555.

Есть ноутбук на котором настроен openvpn клиент с подключением к внешнему интерфейсу. Этот ноутбук сейчас подключён во внутренней сети с ip 10.10.10.10. Он будет выноситься и у него будет внешний ip.

Хочу сейчас проверить работу openvpn, собственно конект к openvpn серверу.

На сетевом фильтре шлюза настроил проброс.

-A FORWARD -i eth1 -o eth0 -p udp -s 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -p tcp -s 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p udp -d 10.01.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -d 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT

Проверяю приходят ли пакеты на внутренний интерфейс:

tcpdump -i eth1 -n -nn host 10.10.10.10

Да пакеты приходят.

Проверяю на внешний:

tcpdump -i eth0 -n -nn host 10.10.10.10

Не приходят.

Проверяю проходят ли они цепочку форвад на сетевом фильтре:

watch "iptables -nvL | grep -w 10.10.10.10

Пакетов в форварде нет.

По логике вещей они должны попадать в форвапрд и доходить до внешнего интерфейса, но получается что это не правильно.

Не пойму почему?

★★

Ответ на: комментарий от v4567

может быть так нельзя сделать как я хочу.

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

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

-A FORWARD -i eth1 -o eth0 -p udp -d 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -p tcp -d 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p udp -s 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -s 10.10.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT
а так?)

lasthappy
()
Ответ на: комментарий от lasthappy

по логике вещей не должно работать

проверил

не работает

v4567 ★★
() автор топика

Показывай вывод iptables-save

tcpdump -i eth0 -n -nn host 10.10.10.10

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

Проверяю приходят ли пакеты на внутренний интерфейс:

tcpdump -i eth1 -n -nn host 10.10.10.10

Да пакеты приходят.

Проверяю на внешний:

tcpdump -i eth0 -n -nn host 10.10.10.10

Не приходят.

Ты вообще откуда и куда трафик пускаешь?

Deleted
()
Ответ на: комментарий от Deleted

Ты вообще откуда и куда трафик пускаешь?

Вот я же написал:

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

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

Вот я же написал:

Ты написал бред. Мне нужны не твои попытки объяснить происходящее, а описание твоих действий. Например, «с адреса 10.10.10.20 во внутренней сети я пытаюсь установить соединение с адресом 5.5.5.5, которое должно транслироваться на внутренний адрес 10.10.10.10».

Получается пакет на внешний интерфейс шлюза приходит на внутренний интерфейс этого шлюза

Интерфейс - это дырка в твоей сетевой карте. Если ты посылаешь трафик из локалки, то в какую дырку, по-твоему, он попадает?

И где вывод iptables-save?

Deleted
()
Ответ на: комментарий от Deleted

И где вывод iptables-save?

я не могу выложить настройки сетевого фильтра.

Правил запрещающих и правил nat для ip 10.10.10.10 нет.

Интерфейс - это дырка в твоей сетевой карте. Если ты посылаешь трафик из локалки, то в какую дырку, по-твоему, он попадает?

это понятно что если я из локалки посылаю пакеты на внешний Ip адрес то они придут на шлюз по умолчанию, то есть в моём случае на ip 10.10.10.254 - это внутренний интерфейс eth1 моего шлюза.

С адреса 10.10.10.10 из внутренней подсети я пытаюсь установить соединение с внешним ip 5.5.5.5 - это внешний ip адрес eth0 шлюза по умолчанию - его внутренний eth1 ip 10.10.10.254

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

С адреса 10.10.10.10 из внутренней подсети я пытаюсь установить соединение с внешним ip 5.5.5.5 - это внешний ip адрес eth0 шлюза по умолчанию - его внутренний eth1 ip 10.10.10.254

правил nat для ip 10.10.10.10 нет.

Что тогда по-твоему должен делать с трафиком шлюз? Если нет правил трансляции, то шлюз будет считать, что этот трафик - для него, и он никуда дальше не уйдет.

Deleted
()
Ответ на: комментарий от Deleted

Что тогда по-твоему должен делать с трафиком шлюз? Если нет правил трансляции, то шлюз будет считать, что этот трафик - для него, и он никуда дальше не уйдет.

правильно на вне они и не должны выйти, но до eth0 5.5.5.5 должны ведь дойти, а они не доходят.

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

Если ты сделал такой вывод на основании (отсутствующего) вывода команды tcpdump -i eth0 -n -nn host 10.10.10.10, то это неправильно. tcpdump не показывает, как пакет гуляет внутри ядра. Он показывает, в каком виде пакет уходит/приходит по конкретному физическому медиуму, в данном случае, по интерфейсу eth0. И если шлюз не будет маршрутизировать этот пакет, то и в tcpdump ты ничего не увидишь.

Deleted
()
Ответ на: комментарий от Deleted

Если ты сделал такой вывод на основании (отсутствующего) вывода команды tcpdump -i eth0 -n -nn host 10.10.10.10, то это неправильно. tcpdump не показывает, как пакет гуляет внутри ядра. Он показывает, в каком виде пакет уходит/приходит по конкретному физическому медиуму, в данном случае, по интерфейсу eth0. И если шлюз не будет маршрутизировать этот пакет, то и в tcpdump ты ничего не увидишь.

То есть ты хочешь сказать, что пакет всё таки приходит на интерфейс eth0 5.5.5.5

Не буду спорить, так как на 100% не уверен, но думаю что если бы даже пакет прошёл внутри ядра и дошёл до интерфейса eth0 5.5.5.5 то tcpdump его увидел бы.

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

То есть ты хочешь сказать, что пакет всё таки приходит на интерфейс eth0 5.5.5.5

Пакет приходит на интерфейс eth1. На eth0 он НЕ приходит.

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

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

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

Не буду спорить, так как на 100% не уверен, но думаю что если бы даже пакет прошёл внутри ядра и дошёл до интерфейса eth0 5.5.5.5 то tcpdump его увидел бы.

Думать, не имея ни теоретических знаний о том, как работает сеть в линуксе, ни практических знаний, основанных на опыте работы с сетью, - это мощно.

Deleted
()
Ответ на: комментарий от Deleted

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

Если бы пакет был адресован какому нибудь внешнему сервису и был отправлен из внутренней сети, то он бы пришёл на внутренний интерфейс eth1 и вышел бы через внешний интерфейс eth0 и tcpdump это бы всё показал - пакет на интерфейсе eth1 и пакет на интерфейсе eth0.

Думать, не имея ни теоретических знаний о том, как работает сеть в линуксе, ни практических знаний, основанных на опыте работы с сетью, - это мощно.

На основании чего ты сделал такой ошеломительный вывод.

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

Если бы пакет был адресован какому нибудь внешнему сервису и был отправлен из внутренней сети, то он бы пришёл на внутренний интерфейс eth1 и вышел бы через внешний интерфейс eth0 и tcpdump это бы всё показал - пакет на интерфейсе eth1 и пакет на интерфейсе eth0.

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

При транзите трафика между двумя интерфейсами его можно будет увидеть на обоих, это само собой.

На основании чего ты сделал такой ошеломительный вывод.

На основании этого треда, блин. *facepalm*

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

При транзите трафика между двумя интерфейсами его можно будет увидеть на обоих, это само собой.

В моём случае то же транзит из интерфнйса eth1 в интерфейс eth0, или нет?

v4567 ★★
() автор топика

На внешнем интерфейсе работает openvpn
tcpdump -i eth0 -n -nn host 10.10.10.10
Не приходят.

У вас каша в голове.

anc ★★★★★
()

До кучи

NEW,ESTABLISHED

Что за норкомания? Откуда скописастили? Сами хоть понимаете смысл написанного?
Кстати я не первый раз такое вижу, явно где-то «просочилось» и из этой «канализации» копипастят.

я не могу выложить настройки сетевого фильтра.

Настолько стыдно?

ip r s 
ip a s
Тоже стыдно будет выложить?

anc ★★★★★
()
Ответ на: комментарий от v4567

В моём случае то же транзит из интерфнйса eth1 в интерфейс eth0, или нет?

нет

Deleted
()
Ответ на: комментарий от anc

NEW,ESTABLISHED

Что за норкомания? Откуда скописастили? Сами хоть понимаете смысл написанного?

Кстати я не первый раз такое вижу, явно где-то «просочилось» и из этой «канализации» копипастят.

Например вот отсюда:

https://ru.wikibooks.org/wiki/Iptables

-m state --state устарел, согласен, сейчас лучше использовать -m conntrack --ctstate

но чем вам NEW,ESTABLISHED не понравился?

я не могу выложить настройки сетевого фильтра.

Настолько стыдно?

Нет, не хочу светить айпишники.

На внешнем интерфейсе работает openvpn

tcpdump -i eth0 -n -nn host 10.10.10.10

Не приходят.

У вас каша в голове.

host 10.10.10.10 взят ip из внутренней сети, хотя смотрю на внешнем интерфейсе, но по логике на него пакеты и должны прийти из внутренней сети.

v4567 ★★
() автор топика
Последнее исправление: v4567 (всего исправлений: 4)
Ответ на: комментарий от v4567

Например вот отсюда:
https://ru.wikibooks.org/wiki/Iptables

ESTABLISHED,RELATED вижу, варианта NEW, ESTABLISHED не вижу

но чем вам NEW,ESTABLISHED не понравился?

Т.е. NEW пропускаем, ESTABLISHED тоже а вот RELATED нифига. Почему?

Нет, не хочу светить айпишники.

Т.е. замена это не про нас?

host 10.10.10.10 взят ip из внутренней сети, хотя смотрю на внешнем интерфейсе, но по логике на него пакеты и должны прийти из внутренней сети.

Вы пишите про openvpn, а теперь еще раз подумайте на каком интерфейсе смотреть?

anc ★★★★★
()
Ответ на: комментарий от anc

ESTABLISHED,RELATED вижу, варианта NEW, ESTABLISHED не вижу

NEW пропускает самый первый пакет во время установки соединения,

ESTABLISHED пропускает уже следующие пакеты.

Если написать ESTABLISHED без NEW соединение не будет установлено и работать не будет. Я прверял это так и естьна самом деле.

RELATED этот статус соединение получает если оно связано с другим соединением которое получило статус ESTABLISHED. В моём случае таких нет, поэтому RELATED я и не использую.

Т.е. замена это не про нас?

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

Вы пишите про openvpn, а теперь еще раз подумайте на каком интерфейсе смотреть?

Самый первый пакет, да и второй от клиента, должен прийти на интерфейс eth0, при этом он будет от внутреннего айпишника.

Кстати и все остальные пакеты то же будут идти через внешний интерфейс.

v4567 ★★
() автор топика
Ответ на: комментарий от anc

Зачем на него тратить время, если он никого кроме себя не слушает?

Deleted
()

ip route show table local

Когда нагуглите и прочитаете, что за таблица маршрутизации ″local″, тогда и задавайте вопросы. Может к тому моменту вас отпустит и вы перестанете писать ″-m state --state NEW,ESTABLISHED -j ACCEPT″ так как это по сути просто ″-j ACCEPT″.

mky ★★★★★
()
Ответ на: комментарий от mky

-m state --state NEW,ESTABLISHED -j ACCEPT так как это по сути просто -j ACCEPT

Согласен. Я просто не обратил на это внимание и не мог понять намёков, тут ведь прямо сказать не могут, обязательно надо намёками сказать что ты дурак, при этом прямого ответа так и не дать.

ip route show table local

я почитаю. Поищу там ответ на мой начальный вопрос, почему мой случай не является транзитом из eth1 в eth0.

v4567 ★★
() автор топика
Ответ на: комментарий от mky

″-m state --state NEW,ESTABLISHED -j ACCEPT″ так как это по сути просто ″-j ACCEPT″.

Не совсем верно, точнее совсем неверно. Можно привести кучу примеров когда будут INVALID пакеты. Причем таковыми будут являться не по причине «прилетевших»

anc ★★★★★
()
Ответ на: комментарий от anc

Ну, если это совсем не верно, приводите кучу примеров, когда возникают INVALID UDP пакеты и чем страшно делать на них ACCEPT.

mky ★★★★★
()
Ответ на: комментарий от mky

1. Конечно я чуть «усугубил» уж простите. Но например при send redirect и разных сетях на одной сетевке, пакеты будут INVALID.
2. Все-таки не правильно когда «левые» пакеты летают. И отсекать их лучше раньше чем позже.
Но все это я написал к тому что считать NEW,ESTABLISHED == ACCEPT не верно.

anc ★★★★★
()
Ответ на: комментарий от anc

Левые они с точки зрения conntrack'а, он же не знает о реальном состоянии сокета, сам отслеживает и решает какой пакет нужный, а какой нет.

И отсекать их лучше раньше чем позже.

Вот это для меня самое спорное утверждение, которое ещё завязано на net.netfilter.nf_conntrack_tcp_loose. Поэтому для меня NEW,ESTABLISHED == ACCEPT, так как я не вижу страшного в прохождении INVALID пакета.

А, с другой стороны, если нужно как можно раньше, то первым правилом ставим ″INVALID -j DROP″ и до последующих правил INVALID пакеты уже не доходят. И тогда опять там только NEW и ESTABLISHED.

mky ★★★★★
()
Ответ на: комментарий от anc

Чем спорить, лучше бы в общих чертах объяснили почему мой случай не является транзитом из интерфейса eth1 в интерфейс eth0.

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

mky вам выше уже не прозрачно намекнул на счет таблицы local. Чуть по другому опишу, хоть и коряво, но возможно вам так станет понятнее, смотрите вы прописали правило -o eth1 но ведь он не исходящий физически, с этого интерфейса физически ничего не улетит.

anc ★★★★★
()
Ответ на: комментарий от anc

смотрите вы прописали правило -o eth1 но ведь он не исходящий физически, с этого интерфейса физически ничего не улетит

Не совсем понял, что Вы имеете ввиду. Детально почитаю про таблицу local, думаю будут вопросы, я тогда спрошу.

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

Я так и не пойму каким образом таблица маршрутизации local связана с моим вопросом.

На шлюзе выполнил команду:

ip route list table local

Получил:

broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
broadcast zzz.zzz.zzz.0 dev tap0  proto kernel  scope link  src zzz.zzz.zzz.1
local zzz.zzz.zzz.1 dev tap0  proto kernel  scope host  src zzz.zzz.zzz.1
broadcast zzz.zzz.zzz.255 dev tap0  proto kernel  scope link  src zzz.zzz.zzz.1
broadcast xxx.xxx.xxx.80 dev eth0  proto kernel  scope link  src xxx.xxx.xxx.82
local xxx.xxx.xxx.82 dev eth0  proto kernel  scope host  src xxx.xxx.xxx.82
broadcast xxx.xxx.xxx.83 dev eth0  proto kernel  scope link  src xxx.xxx.xxx.82
broadcast yyy.yyy.yyy.0 dev eth1  proto kernel  scope link  src yyy.yyy.yyy.254
broadcast www.www.www.0 dev eth2  proto kernel  scope link  src www.www.www.253 linkdown
local www.www.www.253 dev eth2  proto kernel  scope host  src www.www.www.253
local yyy.yyy.yyy.254 dev eth1  proto kernel  scope host  src yyy.yyy.yyy.254
broadcast yyy.yyy.yyy.255 dev eth1  proto kernel  scope link  src yyy.yyy.yyy.254
broadcast www.www.www.255 dev eth2  proto kernel  scope link  src www.www.www.253 linkdown

Где:

eth0 внешний интерфейс

tap0 openvpn на внешнем интерфейсе

eth1 внутренний интерфейс

eth2 ещё один внутренний интерфейс который сейчас не подключён.

У ip своеобразное представление о сети, маршрутах и т.д.

Вот например:

broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1

Разве 127.0.0.0 это броадкаст?

v4567 ★★
() автор топика
Ответ на: комментарий от anonymous

Оскорбляют в большинстве своём анонимы. Не бойся зайди под своим ником и тогда начинай оскорблять.

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

Это адрес сети, но как указано в RFC1812 это устаревшая форма броадкаста. И допускается трактовать пакеты на такой адрес как броадкасты.

Были ли где-то когда-то реальный программы, которые броадкастили по таким адресам это уж копайте сами, информации из 80-х мало.

mky ★★★★★
()
Ответ на: комментарий от mky

mky спасибо за помощь!

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

Openvpn у меня висит на внешнем интерфейсе eth0. Я пытаюсь подключиться из внутренней сети, в пакете ip назначения стоит внешний ip openvpn сервера, а от кого стоит внутренний ip компьютера, соответственно пакеты приходят на внутренний интерфейс eth1.

Судя по картинке пакет пройдя цепочки PREROUTING попадёт в маршрутизатор, который (может я ошибаюсь) должен будет его направить в цепочку INPUT интерфейса eth0 (да я наверно ошибался и в цепочку FORWARD он не попадёт).

Если это так то став tcpdump на интерфейс eth0 я должен буду увидеть этот пакет - ip назначения внешний, ip от кого внутренний, но этого пакета я не вижу. На внутреннем интерфейсе eth1 этот пакет я вижу.

v4567 ★★
() автор топика
Последнее исправление: v4567 (всего исправлений: 3)

шлюз с… внутренним интерфейсом eth1 10.10.10.254
ноутбук… с ip 10.10.10.10

Маски везде /24, я правильно понимаю? Если да, то в чём был смысл загонять внутренний интерфейс в сеть туннеля?

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

XMs ★★★★★
()
Последнее исправление: XMs (всего исправлений: 1)
Ответ на: комментарий от v4567

Цепочка INPUT не привязана к интерфейсу, она одна на все интерфейсы. Туда попадают все пакеты по маршруту типа ″local″. Пакет с eth1 сразу попадает в INPUT, и у него будет ″-i eth1″, и не определено ″-o″.

mky ★★★★★
()
Ответ на: комментарий от XMs

Маски везде /24, я правильно понимаю? Если да, то в чём был смысл загонять внутренний интерфейс в сеть туннеля?

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

Маски /24.

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

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

Пакет с eth1 сразу попадает в INPUT, и у него будет ″-i eth1″, и не определено ″-o″.

Честно говоря не пойму почему не определено "-o" у меня ведь назначением стоит внешний ip -> eth0.

v4567 ★★
() автор топика
Ответ на: комментарий от v4567

Если это так то став tcpdump на интерфейс eth0 я должен буду увидеть этот пакет

Нет. Я выше писал с интерфейса eth0 никакие пакеты не улетают.
Забудьте про интерфейсы когда речь идет о локальных процессах. Попробую еще более по другому пояснить. У вас есть n-ип адресов и без разницы на каком интерфейсе они. На одном или нескольких слушает процесс запущенный локально. Для него прилетает пакет через интерфейс - все. Т.е. прохождение входящий интерфейс -> локальный процесс. Конкретно для вашего примера это будет входящий eth1, в iptables цепочка INPUT, исходящий тот же eth1 цепочка OUTPUT

anc ★★★★★
()

-A FORWARD -i eth0 -o eth1 -p udp -d 10.01.10.10 -m state --state NEW,ESTABLISHED -j ACCEPT

10.01.10.10 - это не роляет?

anonymous
()
Ответ на: комментарий от anonymous

10.01.10.10 - это не роляет?

Это опечатка, должно быть 10.10.10.10

v4567 ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.