标题: Debian本机IP变成神秘的172.16.15.5

创建: 2018-07-19 11:46 更新: 2018-09-26 13:59 链接: https://scz.617.cn/unix/201807191146.txt

有台Debian 8.5虚拟机。

Guest的网卡使用桥接模式，直接使用Host的网卡。假设Guest的IP是192.168.34.20， Host的IP是192.168.34.2。从Debian 4开始就这样配置，这么多年一路升级，一直没出过大问题。小问题倒是有一个，有时Host的ARP表中Guest的条目是:

192.168.34.20 00-ba-db-ad-00-00 static

可我并未"arp -s"或"netsh interface ip add neighbors"增加这个静态Entry，它是凭空冒出来的。手工"arp -d 192.168.34.20"之后恢复正常。要说ARP Spoofing，那也得是动态Entry啊。这个小问题并不总是出现，不知根源何在，未深究。本文重点不是这个小问题，仅供有心人参考。

为了用Python3，对Guest手工升级，编辑sources.list，用了sid。内核、头文件、 GLIBC、编译器、VMmware Tools之类的都升了，不多说。

升完之后，初用一切正常。用得次数多了，发现有时SSH登录Guest失败，与ARP无关，此时操作VMware硬件配置，断开网卡、重新连接网卡，基本都能解决问题。这个现象时有时无，由于有前述临时解决方案，起初并未深究。

某天SSH登录Guest成功，执行"aptitude install"发现不能访问Internet，开始排查。 Guest可以ping通网关192.168.34.254，无法ping通DNS 192.168.x.1，DNS不在34网段，此时所有FQDN解析失败。前几天从Guest还能ping通192.168.x.1，因此第一反应是最近信息管理部调整了ACL，对192.168.34.20做了限制，但信管部的同事说没做限制。在Host上Wireshark抓包，发现由Guest发出的ICMP源IP是172.16.15.5。在Guest 中"ifconfig -a"，看到eth0的IP是172.16.15.5，而我从未手工配过这个网段，见鬼。更大的怪事出现了，SSH登录Guest时，使用的目标IP可是192.168.34.20，这个TCP连接、SSH会话仍在使用中。"ifconfig -a"看到172.16.15.5的同一时刻在Host上 "ping 192.168.34.20"，正常！用图形界面的nm-connection-editor查看此时的网络配置，只有192.168.34.20，没有172.16.15.5，后者仿佛鬼魂一般存在。若是别人描述这个现象给我听，我绝不相信，我会认定有什么低级错误存在其中。操作VMware硬件配置，断开并重新连接网卡，多数时候会导致"ifconfig -a"恢复正常，eth0的IP 恢复成192.168.34.20，但这招并不总灵。事后发现，SSH登录Guest失败，起因相同，只不过后果更恶化。

又一天，已经确保Guest源IP正常，也可以ping通192.168.x.1，但就是FQDN解析失败。检查/etc/resolv.conf，意外发现其中写着172.16.15.1，手工改回192.168.x.1， FQDN解析成功。这个现象与前两个现象的起因应该同源。操作VMware硬件配置，断开并重新连接网卡，有时只能恢复eth0的IP，并不自动恢复resolv.conf，有时又会恢复后者，最惨的时候，二者都得不到恢复。

Google for "VMware Debian 172.16.15.1"未能得到有效信息。

将此事当成八卦说与bluerust，他提到DHCP干挠的可能性，可Guest从未配置过DHCP，甚至与dhcpcd相关的包都没有装。他还建议动用audit子系统审计对resolv.conf的读写访问，看看谁在修改它。

eth0出现172.16.15.5时，可以在主控台手工配置IP:

ifconfig eth0 192.168.34.20 netmask 255.255.255.0 broadcast 192.168.34.255 up route add default gw 192.168.34.254

这三种怪现象发作越发频繁，搞得很烦躁。摸索出一种固定恢复套路:

1) 主控台登录 2) 断开VMware的网卡 3) ping 192.168.x.1 (DNS) 4) 连上VMware的网卡 5) ping 192.168.x.1 6) 检查ifconfig、resolv.conf，确保都正常

第3步看似不必要，实测会影响恢复效果。此时怀疑BUG与VMware Tools、网卡驱动等相关。

$ grep -r 192.168.34.20 /etc

找到这个文件

$ cat "/etc/NetworkManager/system-connections/Wired connection 1"

[connection] id=Wired connection 1 uuid=xxxxxxxx-0868-xxxx-xxxx-xxxxxxxxxxxx type=ethernet interface-name=eth0 permissions= timestamp=1531968922

[ethernet] mac-address=xx:xx:xx:xx:xx:xx mac-address-blacklist=

[ipv4] address1=192.168.34.20/24,192.168.34.254 dns=192.168.x.1; dns-search= ignore-auto-dns=true ignore-auto-routes=true method=manual

[ipv6] addr-gen-mode=stable-privacy dns-search= ip6-privacy=2 method=ignore

过去常用的/etc/network/interfaces里没有eth0的信息:

$ cat /etc/network/interfaces

auto lo iface lo inet loopback

与bluerust讨论后，怀疑是NetworkManager的BUG，决定升级几个相关包。

$ dpkg -S which nm-connection-editor network-manager-gnome: /usr/bin/nm-connection-editor

$ dpkg -S which gnome-control-center gnome-control-center: /usr/bin/gnome-control-center

$ dpkg -S /usr/lib/gvfs/gvfsd-network gvfs-backends: /usr/lib/gvfs/gvfsd-network

题外话，如果"dpkg -S"查不到包名，有可能目标只是一个符号链接，用ls确认后，直接查原始文件，比如awk就是这种情形。

同时升级这几个包:

apt-get update -u aptitude install gnome-control-center gvfs-backends network-manager-gnome network-manager

升完级，重启Guest，BUG依旧。

有两种图形界面查看网络配置，一种是:

$ nm-connection-editor

另一种是控制面板:

$ env XDG_CURRENT_DESKTOP=GNOME gnome-control-center

题外话，我的桌面不是gnome，而是轻量级的icewm，这种情况下使用gnome的控制面板，必须像上面那样指定环境变量启动，否则你看到的控制面板是空的。

在GUI中意外发现有两个网络接口，一个是预期中的"Wired connection 1"，它的IP 是显式配置过的192.168.34.20，另一个是凭空出现的"eth0"，它的IP是神秘的 172.16.15.5。升级NetworkManager相关包之前，GUI中只能看到第一个网络接口，升级之后看到了两个。此时在GUI中删除捣乱的"eth0"即可恢复正常，包括resolv.conf；相比操作VMware硬件配置，断开并重新连接网卡，前者恢复效果更可靠。

但我不想每次来GUI中删除捣乱的"eth0"，我想直接SSH登录Guest，为此做了很多尝试。

某次尝试，在GUI中先删除捣乱的"eth0"，再将"Wired connection 1"重命名成"eth0"，重启Guest，貌似BUG消失。当时很高兴，还备份了此刻的虚拟机。结果另一次重启后， BUG复现，用GUI一看，出现两个"eth0"，分别对应172.16.15.5、192.168.34.20。多次测试后确认，该BUG的触发存在竞争条件，时有时无。

既然BUG出现时总是伴随一个捣乱的"eth0"，脑洞大开地换了组搜索关键字:

Google for "Debian "nm-connection-editor" two eth0"

找到

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755202 https://fitzcarraldoblog.wordpress.com/2015/02/15/networkmanager-creates-a-new-connection-eth0-that-does-not-work/ https://fitzcarraldoblog.wordpress.com/2015/03/17/more-on-networkmanager-creating-a-new-connection-eth0%E2%80%B2-that-does-not-work/

发现很多人遭遇该BUG，与使用虚拟机无关，物理机同样会碰上，与NetworkManager 强相关，不只是Debian有。BUG的触发存在竞争条件，使得路人甲的临时解决方案很可能不适用于路人乙，更扯淡的是，reboot和冷启动都会有差别。该BUG目前没有终极解决方案，只能自己测出适用于自身环境的临时解决方案。

放狗时看到一些相关命令，记录备忘:

grep -i NetworkManager /var/log/messages service network-manager stop NetworkManager --no-daemon --debug NetworkManager --no-daemon --log-level=DEBUG --debug /etc/init.d/network-manager restart

差点想用IDA逆向nm-connection-editor，以找出如何命令行删除捣乱的"eth0"，旁白，这不吃撑了吗，这是Linux，不是Windows，开源了解一下。后来发现nmcli是命令行版的。

查看网络接口

nmcli connection show
nmcli c s

删除网络接口

nmcli connection delete eth0
nmcli c d eth0

在我这台虚拟机上反复测试后，采用如下临时解决方案解决BUG:

1)

确保"/etc/NetworkManager/system-connections/Wired connection 1"存在，不要将"Wired connection 1"重命名成"eth0"

2)

$ vi /etc/NetworkManager/NetworkManager.conf

原来是

[main] plugins=ifupdown,keyfile

[ifupdown] managed=false

改成

[main] plugins=ifupdown,keyfile no-auto-default=eth0

[ifupdown] managed=true

3)

$ vi /etc/rc.local

在其中增加一条命令

nmcli c d eth0

上述第2步，在我这里是必要的，可以确保BUG消失。假设只做了第1、3步，仍有一定机率出现神秘的172.16.15.5。

对于我来说，这个BUG就这样吧，说不定哪天升级发行版，就彻底消失了。

最初是个小BUG，临时解决方案虽然不完美但也能将就。某天觉得，即使是个不完美的临时解决方案，还是写个文档备忘，以免时间久了不记得摸索过的细节部分。然后当成八卦说给bluerust听，两人说着说着，有效信息渐渐多了一些，互相启发之下换了测试方案，进而导致Google搜索关键字变化，找到一批有难同当的人。虽然没有找到BUG的终极解决方案，但找到了适用于自身环境的相对完美的临时解决方案，学到一批NetworkManager相关知识点。整个过程再次表明，有收获时记得写文档，利人更利己。

小结一下:

1) 尽早使用Wireshark、ifconfig 2) 及时升级相关软件包 3) 积极调整Google搜索关键字 4) 与人讨论(八卦) 5) 写文档备忘

2018-09-26 13:59 scz

Debian的Network Manager实乃万恶之源，几千年都碰不上的幺蛾子，忍了这么久之后终于还是决定把它干掉。

禁用Network Manager

systemctl stop NetworkManager.service systemctl disable NetworkManager.service

之后用"/etc/network/interfaces"配置网络。如果是从低版本Debian一路升级上来，可能下面这些操作有助于减少干挠:

systemctl stop avahi-daemon systemctl disable avahi-daemon

aptitude install systemd aptitude install ifupdown