Доступ к виртуальному Windows с другого хоста

Для начала, включите маршрутизацию используя sysctl.

Потом проверьте состояние iptables (команда iptables-save и внимательно прочесть ее вывод). Исправить найденные проблемы.

И после этого у вас всё заработает

В свежих virtualbox есть опция проброса портов. Без этого достучаться до машины за NAT'ом не получится.

Зачем NAT, когда все виртуальные машины умеют port forwarding?

Не надо городить!

включено:

[root@localhost lib]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1


[root@localhost lib]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp  — anywhere anywhere udp dpt:domain
ACCEPT tcp  — anywhere anywhere tcp dpt:domain
ACCEPT udp  — anywhere anywhere udp dpt:bootps
ACCEPT tcp  — anywhere anywhere tcp dpt:bootps
ACCEPT all  — anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp — anywhere anywhere
ACCEPT all  — anywhere anywhere
ACCEPT tcp  — anywhere anywhere state NEW tcp dpt:ftp
ACCEPT tcp  — anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp  — anywhere anywhere state NEW tcp dpt:cbserver
ACCEPT udp  — anywhere anywhere state NEW udp dpt:cbserver
ACCEPT tcp  — anywhere anywhere state NEW tcp dpt:ms-wbt-server
ACCEPT udp  — anywhere anywhere state NEW udp dpt:ms-wbt-server
ACCEPT tcp  — anywhere anywhere state NEW tcp dpt:dsc
ACCEPT udp  — anywhere anywhere state NEW udp dpt:dsc
ACCEPT tcp  — anywhere anywhere state NEW tcp dpt:5801
ACCEPT udp  — anywhere anywhere state NEW udp dpt:5801
ACCEPT tcp  — anywhere anywhere state NEW tcp dpt:vnc-server
ACCEPT udp  — anywhere anywhere state NEW udp dpt:vnc-server
ACCEPT tcp  — anywhere anywhere state NEW tcp dpt:5901
ACCEPT udp  — anywhere anywhere state NEW udp dpt:5901
ACCEPT tcp  — anywhere anywhere state NEW tcp dpt:6001
ACCEPT udp  — anywhere anywhere state NEW udp dpt:6001
REJECT all  — anywhere anywhere reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all  — anywhere 192.168.122.0/24 state RELATED,ESTABLISHED
ACCEPT all  — 192.168.122.0/24 anywhere
ACCEPT all  — anywhere anywhere
REJECT all  — anywhere anywhere reject-with icmp-port-unreachable
REJECT all  — anywhere anywhere reject-with icmp-port-unreachable
ACCEPT all  — anywhere anywhere PHYSDEV match --physdev-is-bridged
REJECT all  — anywhere anywhere reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@localhost lib]#

подскажите пожалуйста, где?

На линукс установил виртуальую машину Windows.

Кто эти виртуальныя человечики?

Ну тогда завершающий аккорд - а маршрут на сеть 192.168.122.0 через хост-систему описать не забыли?

Естественно, этот маршрут надо прописывать где-то на 192.168.0.1

нужно и tcp и udp перенаправить.

На виртулбоксе установил, если да, то используй опцию «сетевой мост» в настройках сетевки.

чего-то не понимаю. Для 192.168.0.1 существует один интерфейс - 192.168.0.102 Пакеты идут на 192.168.0.102 порт 3389 с порта редиректятся на 192.168.122.252. -- Вы предлагаете все пакеты на сеть 192.168.122.0 посылать на тот-же интерфейс (192.168.0.102)?

на гостевой машине default gw кто? порт вообще открыт? с хостовой машины через nmap или telnet виден?

Попробую объяснить еще раз:

Пусть у вас есть:
машина А - 192.168.0.50/24
хост-система Б - 192.168.0.102/24 + 192.168.122.0/24
маршрутизатор В - 192.168.0.1.24

Если сделать с машины A ping 192.168.0122.252, то пакет уйдет на 192.168.0.1 (он ведь маршрутизатор по умолчанию для А и Б). И если маршрутизатор В ничего не знает о том, что сеть 192.168.122.0/24 доступна через Б (192.168.0.102), это приведет к тому, что пакет пройдя через В отправится в далекое никуда не ведущее странствие. Именно за этим я и предлагаю прописать на маршрутизаторе В маршрут 192.168.122.0/24 via 192.168.0.102.

Ну а единственное что позволит сделать ваша команда
iptables -t nat -A PREROUTING -d 192.168.0.102 -p tcp --dport 3389 -j DNAT --to-destination 192.168.122.252:3389
так это запустить rdekstop 192.168.0.102:3389 который будет проброшен в виртуалку - а я очень сомневаюсь что это то, что Вам нужно на самом деле.

Я что-то не понял, ты там чего нагородил?

В настройках Виртуалбокса выбираешь тип сети Bridge и всё заработает сразу. Либо NAT и пробрасываешь порт при помощи VBoxManage. Всё остальное - это микроскоп и костыли.

Спасибо Nastishka,
Видимо у меня маршрутизатор 192.168.0.1 атстойный, маршрут на нем я могу прописать - но он все равно использует WAN интерфейс для етого маршрута:
«Specifies the interface — WAN — that the IP packet must use to transit out of the router, when this route is used.»
вобщем пинговать на хост 192.168.122.252 не получается.
почему не будет работать редирект?
в принципе мне нужен rdekstop на 192.168.122.252 что и ожидаю от :
iptables -t nat -A PREROUTING -d 192.168.0.102 -p tcp --dport 3389 -j DNAT --to-destination 192.168.122.252:3389

|Вы можете зайти на свою виртуальную машину через remote desktop?

да

Бридж как видите настроен но похоже продлемма с роутером.
--
Можно подробнее об етом?:
«пробрасываешь порт при помощи VBoxManage.»

6.3. Network Address Translation (NAT) Network Address Translation (NAT) is the simplest way of accessing an external network from a virtual machine. Usually, it does not require any configuration on the host network and guest system. For this reason, it is the default networking mode in VirtualBox.

A virtual machine with NAT enabled acts much like a real computer that connects to the Internet through a router. The «router», in this case, is the VirtualBox networking engine, which maps traffic from and to the virtual machine transparently. The disadvantage of NAT mode is that, much like a private network behind a router, the virtual machine is invisible and unreachable from the outside internet; you cannot run a server this way unless you set up port forwarding (described below).

The network frames sent out by the guest operating system are received by VirtualBox's NAT engine, which extracts the TCP/IP data and resends it using the host operating system. To an application on the host, or to another computer on the same network as the host, it looks like the data was sent by the VirtualBox application on the host, using an IP address belonging to the host. VirtualBox listens for replies to the packages sent, and repacks and resends them to the guest machine on its private network.

The virtual machine receives its network address and configuration on the private network from a DHCP server integrated into VirtualBox. The IP address thus assigned to the virtual machine is usually on a completely different network than the host. As more than one card of a virtual machine can be set up to use NAT, the first card is connected to the private network 10.0.2.0, the second card to the network 10.0.3.0 and so on. If you need to change the guest-assigned IP range for some reason, please refer to Section 9.10, “Fine-tuning the VirtualBox NAT engine”.

6.3.1. Configuring port forwarding with NAT As the virtual machine is connected to a private network internal to VirtualBox and invisible to the host, network services on the guest are not accessible to the host machine or to other computers on the same network. However, like a physical router, VirtualBox can make selected services available to the world outside the guest through port forwarding. This means that VirtualBox listens to certain ports on the host and resends all packets which arrive there to the guest, on the same or a different port.

To an application on the host or other physical (or virtual) machines on the network, it looks as though the service being proxied is actually running on the host. This also means that you cannot run the same service on the same ports on the host. However, you still gain the advantages of running the service in a virtual machine — for example, services on the host machine or on other virtual machines cannot be compromised or crashed by a vulnerability or a bug in the service, and the service can run in a different operating system than the host system.

You can set up a guest service which you wish to proxy using the command line tool VBoxManage; for details, please refer to Section 8.7, “VBoxManage modifyvm”.

You will need to know which ports on the guest the service uses and to decide which ports to use on the host (often but not always you will want to use the same ports on the guest and on the host). You can use any ports on the host which are not already in use by a service. For example, to set up incoming NAT connections to an ssh server in the guest, use the following command:

VBoxManage modifyvm «VM name» --natpf1 «guestssh,tcp,,2222,,22» With the above example, all TCP traffic arriving on port 2222 on any host interface will be forwarded to port 22 in the guest. The protocol name tcp is a mandatory attribute defining which protocol should be used for forwarding (udp could also be used). The name guestssh is purely descriptive and will be auto-generated if omitted. The number after --natpf denotes the network card, like in other parts of VBoxManage.

To remove this forwarding rule again, use the following command:

VBoxManage modifyvm «VM name» --natpf1 delete «guestssh» If for some reason the guest uses a static assigned IP address not leased from the built-in DHCP server, it is required to specify the guest IP when registering the forwarding rule:

VBoxManage modifyvm «VM name» --natpf1 «guestssh,tcp,,2222,10.0.2.19,22» This example is identical to the previous one, except that the NAT engine is being told that the guest can be found at the 10.0.2.19 address.

To forward all incoming traffic from a specific host interface to the guest, specify the IP of that host interface like this:

VBoxManage modifyvm «VM name» --natpf1 «guestssh,tcp,127.0.0.1,2222,,22» This forwards all TCP traffic arriving on the localhost interface (127.0.0.1) via port 2222 to port 22 in the guest.

It is not possible to configure incoming NAT connections while the VM is running. However, you can change the settings for a VM which is currently saved (or powered off at a snapshot).

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

нашел другой маршрутизатор, маршрут прописал:
- пинг не идет
- по ssh не коннектится к гостю
- по remote desktop не конннектится к гостю
- все гости доступ в интернет имеют

Утверждение «пинг не идет» в сочетании с «все гости доступ в интернет имеют» наводит на подозрения в состоянии iptables.

Если будет желание разобраться окончательно с проблемой, то хотелось бы увидеть следующее:

1. вывод команды iptables-save с хост-системы
2. вывод команды route -n с хост-системы
3. рекомендую отключить файрвол в гостевой Windows
4. с какого-нибудь третьего компьютера (не раутера, не хоста, не гостевой ОС) нажмите traceroute -n 192.168.122.252 (маршрут до гостевой ОС)

Просто у меня 4 инсталяции хост-систем (как QEMU-KVM, так и VirtualBox), куча VPN'ов между ними и выделеных под гостевые ОС подсетей, и проблем не возникает то есть у вас какая-то системная проблема, связанная с пониманием общих схем маршрутизации.

1. вывод команды iptables-save с хост-системы
[root@localhost ~]# iptables-save
# Generated by iptables-save v1.4.7 on Wed May 25 05:10:37 2011
*nat
:PREROUTING ACCEPT [301:33358]
:POSTROUTING ACCEPT [79:16162]
:OUTPUT ACCEPT [21:3280]
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT
# Completed on Wed May 25 05:10:37 2011
# Generated by iptables-save v1.4.7 on Wed May 25 05:10:37 2011
*mangle
:PREROUTING ACCEPT [932:136171]
:INPUT ACCEPT [729:82094]
:FORWARD ACCEPT [341:79827]
:OUTPUT ACCEPT [478:96449]
:POSTROUTING ACCEPT [845:183602]
COMMIT
# Completed on Wed May 25 05:10:37 2011
# Generated by iptables-save v1.4.7 on Wed May 25 05:10:37 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [476:96275]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 20 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 20 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 3388 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 3388 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 3389 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 3389 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 3390 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 3390 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5801 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 5801 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5900 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 5900 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5901 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 5901 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 6001 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 6001 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -d 192.168.2.0/24 -i eth0 -o virbr1 -j ACCEPT
-A FORWARD -s 192.168.2.0/24 -i virbr1 -o eth0 -j ACCEPT
-A FORWARD -i virbr1 -o virbr1 -j ACCEPT
-A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
/********************************/
/********************************/
/********************************/

2. вывод команды route -n с хост-системы
[root@localhost ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
/********************************/
/********************************/
/********************************/

3. рекомендую отключить файрвол в гостевой Windows
-отключен
-установил еще одну ВМ - Линукс -по ssh зайти тоже немогу

4. с какого-нибудь третьего компьютера (не раутера, не хоста, не гостевой ОС) нажмите traceroute -n 192.168.122.252 (маршрут до гостевой ОС)
C:\Users\kapelan>tracert 192.168.122.252

Tracing route to 192.168.122.252 over a maximum of 30 hops

1 1 ms 2 ms 2 ms 192.168.0.1
2 1 ms 2 ms 1 ms 192.168.1.1
3 2 ms 1 ms 1 ms 192.168.1.101
4 192.168.1.101 reports: Destination protocol unreachable.

Trace complete.


PS:
у хоста теперь адрес 192.168.1.101
на маршрутизаторе 192.168.1.1 установлен маршрут к 192.168.122.0 через 192.168.1.101

Да, проблема в iptables. На пальцах примерно так:

ping 192.168.122.252 попадает в цепочку FORWARD, интерфейсы (входящий и исходящий) iif=eth0, oif=virbr0.

-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT Под это правило он не попадает, поскольку статус NEW

-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT Под это тоже не попадает - интерфейсы другие

-A FORWARD -i virbr0 -o virbr0 -j ACCEPT Под это не попадает - iif не тот (входящий интерфейс)

-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable Под это попадает - но это REJECT.

Эти злосчастные несколько вредящих начальных правил вписывает libvirt, будь он неладен со своей манерой лезть в iptables. Не знаю какой дистрибутив у вас, увы, дальше описываю на своем примере:

В свое время в Fedora я с этим плюнула бороться и поступила примерно так - после запуска демона libvirt ждем примерно 10 секунд (чтобы libvirt поднял интерфейс и записал в iptables что хочет) и потом переустанавливаем правила iptables. Все это записала в rc.local:

$ cat /etc/rc.d/rc.local
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local

#
# Nasty was here...
#
sleep 10
service iptables restart

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

1. Прокатываем следующие команды:

iptables -F FORWARD
iptables -P FORWARD ACCEPT
iptables -F POSTROUTING -t nat

2. Сохраняем текущую удачную конфигурацию:

service iptables save

3. Делаем reboot, libvirt стартует и прписывает свои домыслы в iptables, но rc.local его перегружает настройки iptables, восстанавливая НАШИ настройки. Все что осталось - убеждиться, что цепочка nat/POSTROUTING у нас пустая, а filter/FORWARD тоже пустая и имеет политику ACCEPT:

iptables -L POSTROUTING -t nat
iptables -L FORWARD -t nat

спасибо большущее, Nastishka!
работает как часы ;)

Огромное вам спасибо! :-)