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

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

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

Простите, но INPUT тут как бэ не причем. Более того, это вредно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во-первых, проверьте саму виртуалку - 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) на виртуалке и на роутере (если возможно), посмотрите, куда идут пакеты.

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

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

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

Так с хоста «хоста (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 - нет.

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

Вы имеете в виду то, что для этого нужно сохранить строчку?

iptables -A INPUT -p tcp -i eth0 -s 0/0 --dport $port -j ACCEPT

Нет.

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

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

Вам на 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.

А зачем это вам нужно?

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

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

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

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

Честно говоря, удобства тут никакого нет - пр наличии прямого доступа к машине ходить на нее через NAT. Ну а решение Вам 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

Да вполне. Можно и так.

Проверил - работает лишь наполовину, т.е. только первое правило: успешно подключаюсь к виртуалке через 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 нужно взаимодействовать.

Да должно. Посмотрите tcpdump на роутере. Не поленился проверить, правила рабочие.
Покажите iptables-save

Покажите iptables-save

Извольте.

Уточню по интерфейсам у вас на br0 локалка?
brctl show - покажите еще

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

net.ipv4.conf.*.arp_filter в 2 или 0

Вывод 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. Отпишусь тогда.

Доброй ночи.

Простите, буковкой ошибся rp_filter

Вывод 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

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

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

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

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

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

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

По поводу беспроводного подключения: как одно из решений - поместить 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.

поместить tcpdump в автозагрузку роутера

Это действительно костыль :) ip link set br0 promisc on

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

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

ip link set br0 promisc on

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

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

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

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

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

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

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

ip link set br0 promisc off

При:

ip link set br0 promisc on

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

Спасибо за тест.
Если vel откликнется, может как-то прокомментирует.