标题: 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