远程访问双层嵌套Openstack云下的Windows虚机(by quqi99)

版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明 (http://blog.csdn.net/quqi99)

问题

遇到这么一个奇葩组合问题，一个Bug只在Windows虚机上出现，实验环境是远程OpenStack云上再嵌套OpenStack云上提供的一个Windows虚机，两个OpenStack云都采用内网IP，现在的问题是如何远程登录到Windows虚机中。环境如下：

• Bastion中转机，是由Underlying OpenStack提供的一台虚机，它的floating ip是10.230.65.8，可通过VPN连接到该IP。众所周知的原因，VPN连接是容易断的。所以平时是先ssh连接到VPS，再在VPS启动VPN连接这台机器的。由于平时都是使用命令行所以没遇到问题，但是现在是采用RDP图形化界面连接Windows虚机的，那么网速就跟不上了。无奈，只能继续将VPN创建在本机上。
• Tenant OpenStack - 最上层的OpenStack是由Underlying OpenStack提供的虚机创建的。上层Tenant OpenStack的为这台Windows虚机提供的浮动IP是10.5.150.2
• 如果我们将Windows虚机创建在Underlying OpenStack上，那么它可以分到10.230网段的IP，那么问题就简化了，登录VPN打通网络后直接通过remmina远程连接即可。但由于Underlying OpenStack我无权限控制，Windows虚机创建在Tenant OpenStack上，那样问题就复杂化了。

First, glance charm need to add: constraints: "mem=1G root-disk=70G"

source ~/novarc && glance image-download --file windows2012R2_virtio.raw --progress 31dd4e9f-ccd3-4c57-b10e-6b5e99366240
source novarc && glance image-create --name windows2012R2 --file /bak/windows2012R2_virtio.raw --visibility public --progress --container-format bare --disk-format raw
nova keypair-add --pub-key ~/.ssh/id_rsa.pub mykey
nova flavor-create myflavor auto 3200 45 1 
openstack server create --wait --image windows2012R2 --flavor myflavor --key-name mykey --nic net-id=dd269a94-5b76-4e24-8046-4d377fa3be5f --min 1 --max 1 i1
nova floating-ip-create
nova floating-ip-associate i1 10.5.150.2
./tools/sec_groups.sh

访问Tenant OpenStack的Horizon界面

这个简单，登录VPN后，再在本机运行sshuttle命令即可访问horizon界面。

sshuttle -D -r ubuntu@10.230.65.8 10.5.0.0/24
http://10.5.0.52/horizon

通过noVNC访问Tenant OpenStack提供的Linux虚机

Linux虚机要是通过命令行来访问，那就没这些问题了。若要图形化访问，可以采用novnc方案。
1， 在控制节点上安装下列四个组件。计算节点不需要安装包。

sudo apt-get install nova-consoleauth novnc python-novnc nova-novncproxy
sudo service nova-consoleauth restart
sudo service nova-novncproxy restart
sudo service libvirt-bin restart

2， 在控制节点和计算节点上同时配置：

vnc_enabled = True
novnc_enabled = True
vncserver_proxyclient_address=10.5.0.49
vncserver_listen=0.0.0.0
novncproxy_base_url=http://10.5.0.43:6080/vnc_auto.html

3, 通过下列命令就可以获得novnc连接并访问了：

nova get-vnc-console i1 novnc
sshuttle -D -r ubuntu@10.230.65.8 10.5.0.0/24

上面命令相当于手动打开虚机的vnc支持：

sudo virsh edit i1
   <graphics type='vnc' port='-1' autoport='yes' listen='192.168.99.124' passwd='password' keymap='en-us'/>
sudo virsh shutdown i1 && sudo virsh start i1
#sudo virsh -c qemu+ssh://hua@node1/system vncdisplay i1
sudo virsh vncdisplay i1
vncviewer 192.168.99.124:1

如果本机开了VPN后通过’ssh -X’远程连接中转机，再通过上面的vncviewer也是可以连接Linux虚机的。
但是该Windows虚机不支持VNC，但它默认启动了RDP。同理，我们也可以本机开了VPN后通过’ssh -X’远程连接中转机，再通过remmina访问(或者采用rdesktop命令行方式 )，但是这种方式奇慢无比，于是有了本文的探讨。

通过tunnel+remmina访问Tenant OpenStack提供的Windows虚机

设想的方案是通过如果的ssh正向隧道方式，本机上执行如下命令，本机的13389端口通过ssh server 10.230.65.8映射到远程的10.5.150.2:3389上。

ssh -p 22 -L localhost:13389:10.5.150.2:3389 ubuntu@10.230.65.8 -N -v
#sudo rdesktop 127.0.0.1:13389
sudo rdesktop -z -r sound:local -g workarea -D -K -a 16 -u Administrator -p password 127.0.0.1:13389

但是发现不好使，原因在于在中转机10.230.65.8上都无法运行telnet 10.5.150.2 3389’命令。
VNC的5900-5910这些端口与RDP的3389端口似乎还有点不一样，5900-5910是运行虚机的物理机上的端口，而3389是Windows虚机的端口。

所以第一步，应该将Windows虚机所在的物理机的Security group规则打开，这个得在Tenant OpenStack环境中执行如下命令：

nova secgroup-add-rule default tcp 3389 3389 0.0.0.0/0
nova secgroup-add-rule default udp 3389 3389 0.0.0.0/0
#secgroup=${1:-`openstack security group list --project admin| grep default| awk '{print $2}'`}
#openstack security group rule create $secgroup --protocol tcp --remote-ip 0.0.0.0/0 --dst-port 3389 --project admin

#计算节点上通过下列命令验证：
$ sudo iptables-save |grep 3389
-A neutron-openvswi-i2f32d9bf-6 -p tcp -m tcp --dport 3389 -j RETURN
-A neutron-openvswi-i2f32d9bf-6 -p udp -m udp --dport 3389 -j RETURN

#网络节点上继续通过下列命令验证通过：
sudo ip netns exec qrouter-d07093c5-f8b3-49c4-9f35-2f43a618b588 telnet 192.168.21.2 3389

第二步，要想通过192.168.21.2的floating ip (10.5.150.2)访问，还得将Tenant OpenStack的FWaaS服务中的3389端口打开。

neutron firewall-rule-create --protocol tcp --destination-port 80 --action allow --name tcp_3389
neutron firewall-rule-create --protocol udp --destination-port 80 --action allow --name udp_3389
neutron firewall-policy-create --firewall-rules "tcp_3389 udp_3389" policy_3389
neutron firewall-create policy_3389 --name myfirewall
sudo ip netns exec qrouter-d07093c5-f8b3-49c4-9f35-2f43a618b588 iptables-save |grep 3389

#也可以通过下列命令直接手动添加：
sudo ip netns exec qrouter-d07093c5-f8b3-49c4-9f35-2f43a618b588 iptables -A neutron-vpn-agen-iv49ecd7359 -p tcp -m tcp --dport 3389 -j ACCEPT
sudo ip netns exec qrouter-d07093c5-f8b3-49c4-9f35-2f43a618b588 iptables -A neutron-vpn-agen-iv49ecd7359 -p udp -m udp --dport 3389 -j ACCEPT
sudo ip netns exec qrouter-d07093c5-f8b3-49c4-9f35-2f43a618b588 iptables -A neutron-vpn-agen-ov49ecd7359 -p tcp -m tcp --dport 3389 -j ACCEPT
sudo ip netns exec qrouter-d07093c5-f8b3-49c4-9f35-2f43a618b588 iptables -A neutron-vpn-agen-ov49ecd7359 -p udp -m udp --dport 3389 -j ACCEPT

#添加成功后在网络节点上通过下列命令验证成功：
telnet 10.5.150.2 3389

第三步，要想在中断机上也能成功运行’telnet 10.5.150.2 3389’, 由于中断机和Tenant OpenStack的网络节点都是由Underlying OpenStack提供的虚机，所以还需要在Underlying OpenStack中的Security Group设置3389支持。具体命令可以参考第一步，但由于我没有Underlying OpenStack的权限，所以这步做不了，此路不通，做罢，但理论应该是对的。

通过端口映射的方案访问Tenant OpenStack提供的Windows虚机

理论上也可以在中转机上将3389端口映射到Windows虚机的3389端口解决，但同样由于我没有Underlying OpenStack的权限无法解决在中转机上’telent 10.5.150.2 3389’，所以此方案也无法测试。

iptables -t nat -A PREROUTING -p tcp --dport 3389 -j DNAT --to-destination 10.10.10.7:3389
iptables -A FORWARD -p tcp --dport 3389 -j ACCEPT

最后的方案

没了Underlying OpenStack的权限，这个实验似乎做不下去了，还剩下两个手段：

• 一个使用Underlying OpenStack环境的tenant用户为Tenant OpenStack的网络节点再分配一个10.230打头的floating ip （如10.230.65.118)，因为Tenant Network上的网络节点上是可以运行’telent 10.5.150.2 3389’的，同时，10.230的IP也可以在登录VPN后直接访问。但是10.230.65.118代表的网络节点是由Tenant OpenStack提供的，所以从本机登录时应该从中转机拷贝~/.local/share/juju/ssh/juju_id_rsa。这种方式目前已经测试成功。

scp ubuntu@10.230.65.8:/home/ubuntu/.local/share/juju/ssh/juju_id_rsa /home/hua/.ssh/
#ssh -i ~/.ssh/juju_id_rsa ubuntu@10.230.65.118
ssh -i ~/.ssh/juju_id_rsa -p 22 -L localhost:13389:10.5.150.2:3389 ubuntu@10.230.65.118 -N -v
#sudo rdesktop 127.0.0.1:13389
sudo rdesktop -z -r sound:local -g workarea -D -K -a 16 -u Administrator -p password 127.0.0.1:13389

-在Windows虚机中通过下列命令打开Powershell Remote, 再通过pywinrm库(https://github.com/diyan/pywinrm)通过命令行或程序(https://gist.github.com/vtapia/c4a87289298c73b9f75afcf36ed6a89b)操作Windows，这种方式蛮麻烦。

Set-ExecutionPolicy -ExecutionPolicy Bypass -Force
Enable-PSRemoting -force
Set-Item WSMan:\localhost\Client\TrustedHosts * -force
winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
restart-Service winrm