LINUX.ORG.RU
решено ФорумAdmin

Проброс портов наружу для VMWare. Как реализовать?

 , , , ,


1

2

Здравствуйте, уважаемые знатоки. Знаю, что данный вопрос уже давно избитый, но я что-то запутался.

В общем, имеется следующее:
1. PC-роутер (192.168.0.1) с внешним белым IP (12.34.56.78, который привязывается к доменному имени с помощью freedns.afraid.org);
2. ПК с ОС Windows 7 (192.168.0.103);
3. Виртуальная машина VMWare Workstation с установленным на ней Debian (192.168.0.32), которая запущена на ПК с ОС Windows 7 (192.168.0.103).

На PC-роутере имеются следующие сетевые интерфейсы:
1. eth0 - смотрит в Интернет;
2. eth1 - смотрит в локальную сеть;
3. wlan0 - беспроводная точка доступа с доступом к локальной сети и к Интернет при помощи сетевого моста;
4. br0 - сетевой мост, для обеспечения доступа к Интернет из локальной сети.

Подскажите, пожалуйста, какие правила нужно прописать с помощью iptables на PC-роутере, чтобы был доступ снаружи к виртуальной машине, которая запущена на ПК?

P.S. На PC-роутере для INPUT и FORWARD по умолчанию установлена политика DROP. PC-роутер, ПК и виртуальная машина по локальным адресам между собой исправно пингуются.


Для проброса конкретного порта:

iptables -t nat -A PREROUTING -p tcp -i eth0 -d 12.34.56.78 --dport $port -j DNAT --to 192.168.0.32:$PORT

где $port - номер порта на роутере, через который Вы хотите получить доступ к вирт. машине, а $PORT - номер порта на виртуалке. Если нужны другие протоколы (udp, icmp, etc), их надо добавлять отдельными правилами по аналогии с этим.

Кроме этого необходимо добавить правила, разрешающие доступ к $port в цепь INPUT и доступ к $PORT в цепь FORWARD:

iptables -A INPUT -p tcp -i eth0 -s 0/0 --dport $port -j ACCEPT
iptables -A FORWARD -p tcp --dport $PORT -j ACCEPT
Serge10 ★★★★★ ()
Ответ на: комментарий от anc

Простите, но INPUT тут как бэ не причем.

Точно, Вы правы. Опять забыл, что цепь prerouting раньше срабатывает :((.

А вот по поводу вредности не понял - все равно ведь ни один пакет, отправленный в данный порт, не дойдет до роутера, а будет завернут в виртуальную машину. Так какая разница, какое там правило в input?

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

Точно, Вы правы. Опять забыл, что цепь prerouting раньше срабатывает :((.

Нет, Вы забыли схему прохождения цепочек. INPUT для локальных процессов.

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

А вот «завтра» ТС (или еще один подаван прочитавший ваш коммент) выкинет одно правило а другое оставит. Именно по этой причине я добавил слово «вредно», что бы кто-то случайно на грабли не наступил.

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

Нет, Вы забыли схему прохождения цепочек. INPUT для локальных процессов.

У нас на интерфейс eth0 приходит пакет, скажем, на локальный адрес и 22 порт. В отсутствие цепи prerouting он бы сразу попал в цепь input. А так его заворачивают на совсем другую машину.

А вот «завтра» ТС (или еще один подаван прочитавший ваш коммент) выкинет одно правило а другое оставит.

А, вот что Вы имеете ввиду. Понял, согласен с Вами.

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

На PC-роутере (192.168.0.1) выполнил следующее:

iptables -A PREROUTING -t nat -p tcp -i eth0 -d 12.34.56.78 --dport 1234 -j DNAT --to 192.168.0.32:22
iptables -A FORWARD -p tcp --dport 22 -j ACCEPT

, однако подключиться извне по SSH к виртуалке по-прежнему не удаётся. Локальный доступ сохраняется.

На виртуальной машине в /etc/ssh/sshd_conf прописано:

Port 22
ListenAddress 0.0.0.0

Вывод iptables -L -n -v -x на виртуалке:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

В чём может быть дело?

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

Во-первых, проверьте саму виртуалку - c хоста можно по ssh подключиться?

Во-вторых, откуда Вы пытаетесь подключаться? И куда?

В-третьих, запустите сниффер (например, tcpdump) на виртуалке и на роутере (если возможно), посмотрите, куда идут пакеты.

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

Во-первых, проверьте саму виртуалку - c хоста можно по ssh подключиться?

Подключаюсь с хоста (Windows 7, 192.168.0.103) к виртуалке (Debian, 192.168.0.32) - успешно.

Во-вторых, откуда Вы пытаетесь подключаться? И куда?

Пытаюсь подключиться с того же хоста (Windows 7, 192.168.0.103) к виртуалке (Debian, 12.34.56.78:1234) извне. Подключения нет: PuTTY пишет «Неактивно».

В-третьих, запустите сниффер (например, tcpdump) на виртуалке и на роутере (если возможно), посмотрите, куда идут пакеты.

Как я понял, пакеты не идут с роутера и, соответственно, не приходят на виртуалку.

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

Пытаюсь подключиться с того же хоста (Windows 7, 192.168.0.103) к виртуалке (Debian, 12.34.56.78:1234) извне.

Вы сломали мне мозг. Так с хоста «хоста (Windows 7, 192.168.0.103)» или «извне» ?
Если слово «извне» было лишним, то все логично, вы использовали правила которые привел Serge10 -i eth0, -i это от слова input т.е. входящий интерфейс который у вас внешний, на него ничего изнутри и не прилетает. Но даже если вы его уберете все равно работать не будет, почему предлагаю «догадаться» самому (намек на роутинг или snat).

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

Так с хоста «хоста (Windows 7, 192.168.0.103)» или «извне» ?

С хоста, указав в PuTTY для подключения не локальный адрес 192.168.0.32:22, а внешний 12.34.56.78:1234.

Через мобильный интернет по 12.34.56.78:1234 через SSH - подключается, с хоста по 12.34.56.78:1234 - нет.

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

Ну таки выше я вам дал варианты. Если вам уж таки необходимо с хоста ходить по внешнему адресу, добавьте роутинг на гостя. Это самое простое решение, и будет вам таки большое счастье.

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

Опишите чуть полнее.
Вам на 12.34.56.78 надо ходить со всех хостов локалки (192.168.0.0 префикс вангую /24)? Учитывая задачу в топике предполагаю что нет. Если все верно, просто пропишите на хосте статик роутинг до 12.34.56.78 «и будет счастье».

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

Чтобы из некой внутренней сети ходить на хост в той же внутренней сети используя внешний IP роутера, который обслуживает эту внутреннюю сеть (дает её NAT) вам нужно помимо обычного проброса порта так же создать дополнительные спец. правила. Слова для гугла: iptables loopback nat, iptables nat reflection.

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

Вам на 12.34.56.78 надо ходить со всех хостов локалки (192.168.0.0 префикс вангую /24)?

Да, всё именно так. Можно, конечно, с хоста по SSH к виртуалке и по 192.168.0.32:22 подключаться, но для завершённости картины хотелось бы, чтоб и по 12.34.56.78:1234 можно было с хоста заходить.

К примеру, к роутеру со всех хостов локалки я подключаться могу как по 192.168.0.1:22, так и по 12.34.56.78:22.

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

общего развития.

Для общего развития почитайте документацию а не просите готового решения. Одно из простых решений в кач-ве намека, правило PREROUTING убрать интерфейс, и добавить еще одно правило на POSTROUTING для snat. Минус такого правила все прилетающие будут от ip роутера, но зато быстрое решение.

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

Для удобства и общего развития.

Честно говоря, удобства тут никакого нет - пр наличии прямого доступа к машине ходить на нее через NAT. Ну а решение Вам anc уже подсказал выше, внимательно перечитайте тред.

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

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

Верно?

iptables -A PREROUTING -t nat -p tcp -d 12.34.56.78 --dport 1234 -j DNAT --to-destination 192.168.0.32:22
iptables -A POSTROUTING -t nat -p tcp -d 192.168.0.32 --dport 22 -j SNAT --to-source 12.34.56.78

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

Проверил - работает лишь наполовину, т.е. только первое правило: успешно подключаюсь к виртуалке через SSH извне (12.34.56.78:1234, example.com:1234).

Находясь же на хосте (192.168.0.103), пытаюсь подключиться через SSH к виртуалке (которая в локалке на 192.168.0.32:22) по 12.34.56.78:1234 (example.com:1234). В ответ - тишина.

Не пойму, в чём ещё может быть дело. Подозреваю, что ещё и с 192.168.0.103 нужно взаимодействовать.

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

Да, на br0 локалка.

bridge name     bridge id               STP enabled     interfaces
br0             8000.90f6526a37dc       no              eth1
                                                        wlan0

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

1. Откуда такая норкомания? Напоминает простыню которую кописастили еще со времен ipchains
2. Пропишите FORWARD -i br0 -j ACCEPT

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

Прописал следующие строки:

iptables -A PREROUTING -t nat -p tcp -d 12.34.56.78 --dport 1234 -j DNAT --to-destination 192.168.0.32:22
iptables -A FORWARD -i br0 -j ACCEPT
iptables -A POSTROUTING -t nat -p tcp -d 192.168.0.32 --dport 22 -j SNAT --to-source 12.34.56.78
К сожалению, без изменений - не пускает.

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

1. Вы не ответили про «наркоманию»
2. Совсем с горя
iptables -I FORWARD -i br0 -j ACCEPT
iptables -I FORWARD -o br0 -j ACCEPT
Только не забывайте возвращать как было, а то судя по вашему выхлопу н-цать раз уже правила добавляли.

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

1. А что про «наркоманию» говорить? Каждый по-своему с ума сходит. Давно нашёл на просторах Сети более-менее подходящий скрипт, применяющий определённые iptables, с помощью гугла немного допилил его под свои нужды. С тех пор и работает.
2. Прописал:

iptables -A PREROUTING -t nat -p tcp -d 12.34.56.78 --dport 1234 -j DNAT --to-destination 192.168.0.32:22
iptables -I FORWARD -i br0 -j ACCEPT
iptables -I FORWARD -o br0 -j ACCEPT
iptables -A POSTROUTING -t nat -p tcp -d 192.168.0.32 --dport 22 -j SNAT --to-source 12.34.56.78
Всё равно не пускает. Вернее, с мобильного-то пускает по 12.34.56.78:1234, а вот из локалки по 12.34.56.78:1234 ни в какую.

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

Тогда вернемся к tcpdump. Насколько я распарсил вашу жуткую простыню все должно заработать. Кстати вы сами понимаете что в ней написано? :)

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

Частично. Местами - поверхностно, местами - интуитивно.

Что касается tcpdump, то я его запустил на виртуалке:
tcpdump -i eth0 > /dump.txt

и попытался подключиться к ней из локалки по 12.34.56.78:1234.

Содержимое файла dump.txt

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

1. Выше писал на роутере посмотреть для начала
2. Ограничите выхлопом только нужного трафика tcp, порты 22,1234, интерфейс br0
3. ключик -n используйте, а то вдруг имя окажется тем самым 12.34.56.78 а мы и не в курсе.

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

Запустил на роутере tcpdump со следующими параметрами:
tcpdump -n -i br0 tcp port 22 or port 1234 > /dump.txt

Содержимое файла dump.txt

P.S. Заметил такое дело: пока на роутере запущен tcpdump (команда выше), с виртуалкой можно установить соединение из локалки по 12.34.56.78:1234. Стоит только прервать работу tcpdump - и доступ к виртуалке тут же прекращается.

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

Вывод sysctl -a | grep «net.ipv4.conf.*.arp_filter»:

net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.br0.arp_filter = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.tun0.arp_filter = 0
net.ipv4.conf.wlan0.arp_filter = 0

Завтра после работы попробую заменить 0 на 2. Отпишусь тогда.

Доброй ночи.

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

Вывод sysctl -a | grep «net.ipv4.conf.*.rp_filter» | grep -w «rp_filter»:

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.br0.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.tun0.rp_filter = 2
net.ipv4.conf.wlan0.rp_filter = 2
Без изменений. Не подключается из локалки по внешнему IP. При запущенном tcpdump на роутере - из локалки подключение есть до тех пор, пока запущен tcpdump на интерфейсе br0. При значении 0 для rp_filter ситуация аналогичная.

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

Кажется мои скилы закончились.
vel Краткое описание. сама задача в топике, локалка это br0, правила в iptables вроде рабочие. «При запущенном tcpdump на роутере - из локалки подключение есть до тех пор, пока запущен tcpdump на интерфейсе br0» Честно говоря я не понимаю почему при promiscuous оно начинает работать.
Что-то еще подскажите?

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

Что-то еще подскажите?

Не знаю, важно ли это, но ПК с Windows 7 (192.168.0.103), на котором находится виртуалка (192.168.0.32) подключается к роутеру по WiFi (wlan0). При помощи WiFi-адаптера D-Link DWA-131 (USB).

P.S. Если нужно, могу предоставить сам BASH-скрипт, который прописывает все iptables.

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

Попробую сегодня после работы через кабель подключиться.

По поводу беспроводного подключения: как одно из решений - поместить tcpdump в автозагрузку роутера. Чтоб он работал в фоне на интерфейсе br0 (придерживал, так сказать, двери лифта открытыми), а логи писал в /dev/null. Но это уже какой-то костыль получается.

В итоге, на данный момент по беспроводному подключению сейчас следующий расклад:
1. Я МОГУ с TELE2 подключаться через ConnectBot к гостевой ОС по example.com:1234;
2. Я МОГУ с хостовой ОС подключаться через PuTTY к гостевой ОС по 192.168.0.32:22;
3. Я НЕ МОГУ с хостовой ОС подключаться через PuTTY к гостевой ОС по example.com:1234 если на роутере не запущен tcpdump на интерфейсе br0;
4. Я МОГУ подключаться к роутеру по 192.168.0.1:22 или по example.com:22.

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

Попробую сегодня после работы

Представительство Израильской конторы в другой стране? Простите не удержался :)

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

ip link set br0 promisc on

Спасибо большое. Это помогло! :)

Представительство Израильской конторы в другой стране?

Не, у нас всё) Служба есть служба: и в будни, и в выходные :)

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

Спасибо большое. Это помогло! :)

Но это не понятно почему. Поэтому я и кастовал vel. Все-таки проверьте на проводном только при ip link set br0 promisc off, уже сильно интересно стало. :)

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

уже сильно интересно стало. :)

Итак, проводное подключение. При:

ip link set br0 promisc off
Из локалки по 12.34.56.78:1234 или example.com:1234 подключения нет.

При:

ip link set br0 promisc on
Из локалки по 12.34.56.78:1234 или example.com:1234 подключается успешно.

P.S. Аналогичные результаты что и у беспроводного подключения.

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