Автор Тема: Маршрутизация и проброс портов в другую подсеть  (Прочитано 17022 раз)

Оффлайн tt1

  • Начинающий
  • *
  • Сообщений: 5
    • Email
День добрый!
Прошу помочь с проблемой. Имеется шлюз - altlinux-6.0.0-lxdesktop (шлюз нужно было поднимать срочно, а с диска кентавра не получилось установить, под рукой был образ с LXDE, поэтому с него и установил)  с 2 сет. картами.
192.168.181.10 (eth0) - смотрит на провайдера
192.168.0.1 (eth1)- смотрит в локалку
В локальной сети имеется xDSL-модем Zyxel (192.168.0.56, подключен через свитч), который соединяется со своим "братом" в другой сети (192.168.192.0/24)
Задача - сделать на шлюзе проброс портов в сеть 192.168.192.0/24
На шлюзе прописан маршрут в нужную сеть:

cat /etc/net/ifaces/eth1/ipv4route
default via 192.168.0.1
192.168.192.0/24 via 192.168.0.56 metric 50 weight 5 table 100

ip r
default via 192.168.181.1 dev eth0  proto static
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.1  metric 1
192.168.181.0/24 dev eth0  proto kernel  scope link  src 192.168.181.10  metric 1
192.168.192.0/24 via 192.168.0.56 dev eth1  proto static  metric 50

с самого шлюза хосты в сети 192.168.192.0 пингуются.

В веб-интерфейсе настроил перенаправление портов, в журнале брандмауэра выглядит так:
"-p tcp --destination 192.168.181.10 --dport 3389 -j DNAT --to-destination 192.168.192.105:3389"
пытаюсь достучаться снаружи на порт 3389 через внешний IP - тишина. При тестовом пробросе данного порта в подсеть 192.168.0.0 - все работает.

В этот момент:
dmesg | tail
[402485.715072] device eth1 entered promiscuous mode
[402485.721196] device eth1 left promiscuous mode
[402485.743669] device eth1 entered promiscuous mode
[423829.822915] nm-dispatcher.a[1517]: segfault at 0 ip b772e128 sp bfd06c60 error 4 in libnm-glib.so.2.5.0[b7727000+26000]
[423867.966461] nm-dispatcher.a[1610]: segfault at 0 ip b771c128 sp bff5e170 error 4 in libnm-glib.so.2.5.0[b7715000+26000]
[423869.273665] nm-dispatcher.a[1646]: segfault at 0 ip b7767128 sp bfec44e0 error 4 in libnm-glib.so.2.5.0[b7760000+26000]
[423879.212497] nm-dispatcher.a[1705]: segfault at 0 ip b76d3128 sp bfda4ac0 error 4 in libnm-glib.so.2.5.0[b76cc000+26000]
[423880.497270] nm-dispatcher.a[1742]: segfault at 0 ip b777c128 sp bf99b640 error 4 in libnm-glib.so.2.5.0[b7775000+26000]
[426670.781579] nm-dispatcher.a[17507]: segfault at 0 ip b7706128 sp bfa79490 error 4 in libnm-glib.so.2.5.0[b76ff000+26000]
[426673.012217] nm-dispatcher.a[17826]: segfault at 0 ip b7723128 sp bfe52fb0 error 4 in libnm-glib.so.2.5.0[b771c000+26000]
порт 3389 приведен для примера, нужны будут и другие порты.
Подскажите, пожалуйста, в чем ошибка?

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
В локальной сети имеется xDSL-модем Zyxel (192.168.0.56, подключен через свитч), который соединяется со своим "братом" в другой сети (192.168.192.0/24)

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

Оффлайн Salomatin

  • Модератор раздела
  • ****
  • Сообщений: 981
    • Пошаговые инструкции
    • Email
Попробуйте так:
cat /etc/net/ifaces/eth1/ipv4route
192.168.192.0/24 via 192.168.0.56 src 192.168.0.1

cat /etc/net/ifaces/eth0/ipv4route
default via 192.168.181.1

service network restart


С любого хоста локальной сети будет видна вся сеть 192.168.192.0/24
« Последнее редактирование: 01.06.2012 09:11:35 от Salomatin »
Хочешь понять сам, объясни другому.
"Если уже все испробовал и ничего не помогает - почитай инструкцию"

Оффлайн tt1

  • Начинающий
  • *
  • Сообщений: 5
    • Email
Спасибо за ответы, завтра на работе буду пробовать. Кстати, может ли быть причина в том, что используется altLXDE, а не серверный вариант кентавра? в ближайшее время планирую поменять шлюз на машину с кентавром.

Оффлайн tt1

  • Начинающий
  • *
  • Сообщений: 5
    • Email
Доброго дня!

To asy:
Модемы в режиме маршрутизатора, оба.  В свое время модемы настраивались по инструкции из KB на zyxel.ru. В режиме бриджа (по-крайней мере тогда) не завелись. Забыл упомянуть (может это играет роль), что это не ADSL, а SHDSL-модемы (Zyxel Prestige 791R EE), связывающие через телефонный кабель 2 здания. С сетки 192.168.0.0 связь с сеткой 192.168.192.0 есть, в частности пинги проходят. Например, со шлюза:
ping 192.168.192.105
PING 192.168.192.105 (192.168.192.105) 56(84) bytes of data.
64 bytes from 192.168.192.105: icmp_req=1 ttl=126 time=5.94 ms
64 bytes from 192.168.192.105: icmp_req=2 ttl=126 time=3.75 ms
^C
--- 192.168.192.105 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 3.750/4.849/5.948/1.099 ms

traceroute to 192.168.192.105 (192.168.192.105), 30 hops max, 60 byte packets
 1  192.168.0.56 (192.168.0.56)  6.267 ms  6.012 ms  6.013 ms
 2  192.168.192.105 (192.168.192.105)  7.017 ms  7.495 ms  8.096 ms.
С Windows-машин по RDP пускает.

На WAN-интерфейсе модема 192.168.0.56 (192.168.3.1) шлюзом стоит WAN-интерфейс второго модема (192.168.3.2), LAN-интерфейс которого (192.168.192.254), соответственно, смотрит в сеть 192.168.192.0. В веб-админке обоих модемов пинг на 192.168.192.105 проходит:
Resolving 192.168.192.105 ... 192.168.192.105
Reply from 192.168.192.105
Reply from 192.168.192.105
Reply from 192.168.192.105
Ping Host Successful
Исходя из этого, мне кажется, что дело не в модемах, а в шлюзе.

To Salomatin:
подправил:
cat /etc/net/ifaces/eth1/ipv4route
default via 192.168.0.1
192.168.192.0/24 via 192.168.0.56 src 192.168.0.1

cat /etc/net/ifaces/eth0/ipv4route
default via 192.168.181.1
Результат:
ping 192.168.192.105
PING 192.168.192.105 (192.168.192.105) 56(84) bytes of data.
64 bytes from 192.168.192.105: icmp_req=1 ttl=126 time=3.54 ms
64 bytes from 192.168.192.105: icmp_req=2 ttl=126 time=3.69 ms
64 bytes from 192.168.192.105: icmp_req=3 ttl=126 time=3.53 ms
^C
--- 192.168.192.105 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2012ms

пинг с других linux-машин в сети 192.168.0.0:
ping 192.168.192.105
PING 192.168.192.105 (192.168.192.105) 56(84) bytes of data.
64 bytes from 192.168.192.105: icmp_seq=1 ttl=126 time=3.79 ms
From 192.168.0.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.0.56)
64 bytes from 192.168.192.105: icmp_seq=2 ttl=126 time=3.90 ms
From 192.168.0.1: icmp_seq=3 Redirect Host(New nexthop: 192.168.0.56)
64 bytes from 192.168.192.105: icmp_seq=3 ttl=126 time=3.78 ms
64 bytes from 192.168.192.105: icmp_seq=4 ttl=126 time=3.72 ms
^C
--- 192.168.192.105 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

пинг с Windows Vista:
C:\Users\user>ping 192.168.192.105

Обмен пакетами с 192.168.192.105 по с 32 байтами данных:
Ответ от 192.168.192.105: число байт=32 время=3мс TTL=126
Ответ от 192.168.192.105: число байт=32 время=3мс TTL=126
Ответ от 192.168.192.105: число байт=32 время=3мс TTL=126
Ответ от 192.168.192.105: число байт=32 время=3мс TTL=126

Статистика Ping для 192.168.192.105:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 3мсек, Максимальное = 3 мсек, Среднее = 3 мсек

Таким образом, связь с сетью 192.168.192.0 есть (в том числе и в первую очередь со шлюза). Увы, не работает проброс портов на эту сеть. И как подправить - пока знаний не хватает :(.
Если у уважаемых коллег есть мысли, куда копать - буду рад их проверить на практике :)

В ходе разбирательства выявил свою ошибку (?) - сетевые интерфейсы управлялись нетворк-менеджером. Изменил на etcnet, рестартанул network - без изменений.
« Последнее редактирование: 06.06.2012 14:17:37 от tt1 »

Оффлайн Salomatin

  • Модератор раздела
  • ****
  • Сообщений: 981
    • Пошаговые инструкции
    • Email
Увы, не работает проброс портов на эту сеть. И как подправить - пока знаний не хватает :(.
Что вы понимаете под понятием проброс портов?
Часто слышу просьбу некоторых системных администраторов - пробросить порт. Но не все понимают, что просят.
У вас сеть видна полностью.
Сделайте nmap 192.168.192.105 или другой адрес, увидите какие порты слушают запросы.
Либо nmap -p 80 192.168.192.105 - увидите открыт 80 порт или нет.
Вам надо наверное маскирование, когда вы обращаетесь на порт одного IP, а попадаете на порт другого IP.
Для этого существуют масса способов, один из них:
iptables -t nat -A PREROUTING -d 192.168.0.1 -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.2:22  - перенаправление пакетов, адресованных одному хосту, на другой хост
С понятием порта надо понимать некоторые особенности.
Часто просят открыть порт и получают ответ, а кто его закрывал?
Порт не открывают. Запускают сервис. FTP слушает 21 порт, т.е. когда запущен на сервере FTP, то сервер начинает слушать запросы по 21 порту и на них отвечать, если обращение происходит по знакомому ему протоколу. Видеорегистратор  слушает запросы по другому порту. Если FTP клиент обратится на видеорегистратор, они друг друга не поймут, даже если будет один и то же порт.
Иногда пробросить порт, например для видеорегистратора недостаточно и работать не будет. Есть протоколы, когда первичная связь осуществляется по одному порту, а потом сервер предлагает клиенту перейти на другой порт, а этот  оставить готовым для приема новых клиентов. Это совсем упрощенно теория.
Короче, не факт, что  простой проброс порта сработает. Зависит от самого сервиса.
А так непонятен вопрос. У вас же все работает.
 

 
Хочешь понять сам, объясни другому.
"Если уже все испробовал и ничего не помогает - почитай инструкцию"

Оффлайн tt1

  • Начинающий
  • *
  • Сообщений: 5
    • Email
Цитировать
Что вы понимаете под понятием проброс портов?
В данной ситуации - понимаю как перенаправление клиента RDP, который стучится на внешний интерфейс шлюза, на windows-ПК, который находится в сети 192.168.192.0.
Возможно, я и впрямь путаю терминологию, спасибо за разъяснение. Приведенный пример правила iptables - возможно ли в данной ситуации реализовать требуемое через модуль "перенаправление портов" альтератора или все-таки надо включать "ручной режим управления" и настраивать правила в нем?

Цитировать
Для этого существуют масса способов, один из них:
подскажите, пожалуйста, про другие способы - в каком направлении "курить"?

P.S. спасибо за помощь и за ваши инструкции на форуме.

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 19 908
    • Домашняя страница
    • Email
возможно ли в данной ситуации реализовать требуемое через модуль "перенаправление портов" альтератора
Вроде можно.
Андрей Черепанов (cas@)

Оффлайн Salomatin

  • Модератор раздела
  • ****
  • Сообщений: 981
    • Пошаговые инструкции
    • Email
подскажите, пожалуйста, про другие способы - в каком направлении "курить"?

На сервере поднимите OpenVPN
http://forum.altlinux.org/index.php/topic,8557.0.html
там же настройка клиента.
Подключаетесь к шлюзу из инета и видите любой комп локальной сети.
Хочешь понять сам, объясни другому.
"Если уже все испробовал и ничего не помогает - почитай инструкцию"

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Забыл упомянуть (может это играет роль), что это не ADSL, а SHDSL-модемы
Роли не играет, тем более, что ZyXEL не делал отдельных ADSL-модемов серверных. Так что я так и предполагал, что shdsl.
traceroute to 192.168.192.105 (192.168.192.105), 30 hops max, 60 byte packets
 1  192.168.0.56 (192.168.0.56)  6.267 ms  6.012 ms  6.013 ms
 2  192.168.192.105 (192.168.192.105)  7.017 ms  7.495 ms  8.096 ms.
А вот этот 192.168.192.105 - это кто ? Второй 791R ? При трейсе до произвольного хоста в сети 192.168.192.0 должно бы быть видно оба промежуточных маршрутизатора.

Оффлайн asket

  • Завсегдатай
  • *
  • Сообщений: 355
  • просто пользователь..
    • Email
В данном случае лучше было бы поставить их прозрачными бриджами и подключить  ближний из них (физически или через VLAN) к интерфейсу сервера, и дать интерфейсу IP из подсети  192.168.192.0/24.  Тогда и маршруты писать нужно будет только на одном роутере, что существенно упростит задачу.

Оффлайн tt1

  • Начинающий
  • *
  • Сообщений: 5
    • Email
Доброго дня всем!
Цитировать
А вот этот 192.168.192.105 - это кто ? Второй 791R ?
это windows-ПК во второй сети. На втором модеме - WAN(192.168.3.2)/LAN(192.168.192.254). Согласен, что они должны быть видны, но почему так - не знаю.

Цитировать
В данном случае лучше было бы поставить их прозрачными бриджами
Буду пробовать этот вариант, настраивая модемы по КБ http://zyxel.ru/kb/1792 или http://zyxel.ru/kb/1323, а также вариант
Цитировать
На сервере поднимите OpenVPN
.

Попробую оба варианта, а там решим, возможно и совмещение их.
Спасибо всем за помощь, как закончу - напишу здесь, если есть необходимость :)

Оффлайн maestro

  • Завсегдатай
  • *
  • Сообщений: 270
    • Email
Тоже возник вопрос с перенаправлением.
Внешний ПК-шлюз (Альт-линукс Десктоп). Внешний адрес 10.xxx.xxx.xxx
Внутри ftp-сервер (21 порт) Адрес 192.168.27.253

Как сделать так, чтобы при обращении на ftp://10.xxx.xxx.xxx открывался бы ФТП 192.168.27.253?

С маршрутизацией всё нормально. ПК-шлюз видит и внешнюю и внутреннюю сеть.

Оффлайн maestro

  • Завсегдатай
  • *
  • Сообщений: 270
    • Email
Тоже возник вопрос с перенаправлением.
Внешний ПК-шлюз (Альт-линукс Десктоп). Внешний адрес 10.xxx.xxx.xxx
Внутри ftp-сервер (21 порт) Адрес 192.168.27.253

Как сделать так, чтобы при обращении на ftp://10.xxx.xxx.xxx открывался бы ФТП 192.168.27.253?

С маршрутизацией всё нормально. ПК-шлюз видит и внешнюю и внутреннюю сеть.
Странная картина с пробросом в альтераторе. Галку ставишь, а кнопки применить нет. Выходишь, опять заходишь - галка исчезла...

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Тоже возник вопрос с перенаправлением.
Внешний ПК-шлюз (Альт-линукс Десктоп). Внешний адрес 10.xxx.xxx.xxx
А зачем xxx.xxx.xxx ? 10.0.0.0/8 точно такая же приватная сеть, как и 192.168.0.0/16. ;-)

Как сделать так, чтобы при обращении на ftp://10.xxx.xxx.xxx открывался бы ФТП 192.168.27.253?
С маршрутизацией всё нормально. ПК-шлюз видит и внешнюю и внутреннюю сеть.
Как-то так:
iptables -t nat -A PREROUTING -d 10.xxx.xxx.xxx --dport 20 -j DNAT --to 192.168.27.253
iptables -t nat -A PREROUTING -d 10.xxx.xxx.xxx --dport 21 -j DNAT --to 192.168.27.253

Возможно, ещё POSTROUTING/SNAT не повредит в обратную сторону, чтобы запрос пришёл с того же IP, на который попал.