openstack中使用GRE后,外部网络无法ssh到虚拟机的解决办法
tenant network : vxlantenant1 : 172.10.10.1/24 dhcp enabled vm1 : 172.10.10.3 tenant2 : 193.160.15.1/24 dhcp disabled vm2 : 193.160.15.2 external network : flat 10.0.0.0/24给vm2分
tenant network : vxlan
tenant1 : 172.10.10.1/24 dhcp enabled vm1 : 172.10.10.3
tenant2 : 193.160.15.1/24 dhcp disabled vm2 : 193.160.15.2
external network : flat 10.0.0.0/24
给vm2分配了floating IP : 10.0.0.102
场景如下:
1. 从外网ping vm2:正常
[root@centos192 ~]# ping 10.0.0.102
PING 10.0.0.102 (10.0.0.102) 56(84) bytes of data.
64 bytes from 10.0.0.102: icmp_seq=1 ttl=63 time=3.74 ms
2. 从外网ssh vm2: 阻塞
[root@centos192 ~]# ssh 10.0.0.102
3. 查询被阻塞的地方
[root@centos192 ~]# ssh -v 10.0.0.102
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to 10.0.0.102 [10.0.0.102] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
4. google说是因为MTU问题。修改vm2的mtu
# ifconfig eth0 mtu 1400 (默认值为1500,现在临时改成1400。如果要永久修改,在配置文件中添加MTU=1400)
5. 重新ssh发现可以正常登录
[root@centos192 ~]# ssh 10.0.0.102
root@10.0.0.102's password:
Last login: Thu Mar 17 07:16:55 2016 from 10.0.0.101
但是,继续调查发现,从外网可以直接访问vm1(vm1也被赋予floating IP)。
查询openstack 文档,发现dnsmasq配置文件中会设置mtu:
[root@centos193 ~]# cat /etc/neutron/dnsmasq-neutron.conf
dhcp-option-force=26,1400 ---> 1400就是MTU的值
vm1的网卡MTU也确实是1400。但是VM2是1500。
后来想起,vm2所在的tenant网络的dhcp功能被关闭,所以mtu值无法被dnsmasq设置。
继续深究下:发现其实就是SSH2_MSG_KEXINIT 这个步骤 无法通过 1500 + 80(gre封装增加的头)。
所以如果在外部网络把MTU改成1420,也能访问vm2
[root@centos80 ~]# ifconfig enp7s0 mtu 1400
[root@centos80 ~]# ssh 10.0.0.102
The authenticity of host '10.0.0.102 (10.0.0.102)' can't be established.
ECDSA key fingerprint is 9d:84:7b:15:3b:20:f6:fa:86:b5:22:88:5d:df:3f:f2.
Are you sure you want to continue connecting (yes/no)?
思维拓展
如果我自定义一个mtu,那么只有我晓得对应的mtu才能正常登录,是否可以作为一种安全辅助机制呢?
更多推荐
所有评论(0)