远程访问双层嵌套Openstack云下的Windows虚机(by 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