折腾 Debian 20+个小时,为何 ping curl wget 无法使用域名, nslookup, dig 却是好的?

Question

新装的debian 9.9.0 最简安装 只安装了ssh, 一切顺利~
使用ssh 登录后 使用 ping IP 都正常, 但是!!!!! 但是!!!!! 使用域名时返回

ping: baidu.com: Temporary failure in name resolution

我原以为只是小问题, 后面才发现这个问题带来的挫败感就像是被 定海神针暴了菊 ~ 混身无力 ~ 还有只猴子不停的在后面叫~大~大~大~~~~

好吧~反正也是被暴了,我就来讲讲被暴的过程吧~希望能碰到大神帮我拔了这棵针吧~~

我的环境是 Virtual Box 6.0 + Debian 9.9.0 , 网络使用桥接模式, 刚开始我还以为网络桥接有问题, 用 ubuntu live cd启动后确定网络没有问题, 那么问题应该就是在 debian 上了.

毫无鸡用的 resolv.conf

我首先填补 /etc/resolv.conf 文件里的 nameserver 114.114.114.114 但是还是不起作用, 查了查google 说需要安装
resolvconf 并把 nameserver 填到 /etc/resolvconf/resolv.conf.d/base 中. 当我照当单办完后, 才发现真的是毫无鸡用~~您别问我我是否重启 networking, 网卡, 系统之类.我就差把 VirtualBox 卸载重装了~

愧然不动的 nsswitch.conf

后来又在 google 查到说是需要调整 /etc/nsswitch.conf 识别顺序. 当我打开后发现, 这文件就和网上说的答案一致嘛,那还改个屁呀~~

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

请专业选手 nslookup 和 dig

没办法我只好把 DVD 挂载上来后安装 nslookup 和 dig

# nslookup baidu.com
Server:        114.114.114.114
Address:    114.114.114.114#53

Non-authoritative answer:
Name:    baidu.com
Address: 220.181.57.216
Name:    baidu.com
Address: 123.125.114.144

# dig @114.114.114.114 baidu.com

; <<>> DiG 9.10.3-P4-Debian <<>> @114.114.114.114 baidu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51693
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;baidu.com.            IN    A

;; ANSWER SECTION:
baidu.com.        331    IN    A    220.181.57.216
baidu.com.        331    IN    A    123.125.114.144

;; Query time: 58 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Sat May 18 17:20:33 HKT 2019
;; MSG SIZE  rcvd: 70

当我看到上面的结果时我觉得是不是我熬夜太多~出现幻觉了~~于是我再次使用 ping baidu.com 问题依旧~
此刻我隐隐觉得 Debian 绝对是猴子派来的帮手~我仿佛还听到~那猴子不但在叫大~还在叫~长~长~长~~

造孽的 ipv6 sysctl.conf

无意之间我发现我的 lo 和 enp0s3 网卡上居然启用了ipv6, 会不会是这个ipv6 搞的鬼啊~于是我在 /etc/sysctl.conf 中把ipv6 屏蔽了~

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

屏蔽之后我的网卡看起来是这样的~

#ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:e4:b2:23 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.144/24 brd 192.168.0.255 scope global enp0s3
       valid_lft forever preferred_lft forever

看样子ipv6 应该是关掉了~再次 ping baidu.com 发现也是有个鸟用~

漏网之鱼 gai.conf

此刻我已经分不清是到底是郁闷的胸口痛,还是真的被棒子顶到肺了~
搞到这里我已经奋战了将近6个小时了,难道是有漏网之鱼~又翻了将近 45 分钟的资料之后 我发现还有一个配置文件'/etc/gai.conf'`
stackoverflow上说是要降低 ipv6 的优先级. 好吧~~你说是什么就是什么了~于是我把 precedence ::ffff:0:0/96 100 这一行的封印打开了~

我想你也能猜到结局了,要不然你也看不到这里了~~

兴奋之余,莫名的快感

搞了这么久我心中萌生一念,会不会是这个版本有问题啊.于是我又找来了 Debian 9.2.1 依然按上面的排错法全都跑了一遍
呵呵 ~ ~
哈 哈 ~ ~ ~ 哈 哈 哈 ~
哈 ~ ~

说实话搞成这样我反而觉得好happy啊, 也不知道是不是被定海神针给暴爽了; 都说 Debian 稳定. 今天果然领教了,虽然我也不知道这个算不算 bug 但能如此~~~稳定,果然名不虚传啊.

最后的大招 strace

被暴将近 20 小时后我才想起用 strace ping -c 1 baidu.com 看看能不能加点润滑剂~最少不用这么干磨~

What ~ poll 居然超时了~~~

strace ping -c 1 baidu.com

.... 去掉无关紧要的

uname({sysname="Linux", nodename="dev", ...}) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("114.114.114.114")}, 16) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendmmsg(5, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\331\214\1\0\0\1\0\0\0\0\0\0\5baidu\3com\0\0\1\0\1", iov_len=27}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC|MSG_TRUNC|MSG_DONTWAIT|MSG_WAITALL|MSG_FIN|MSG_CONFIRM|MSG_NOSIGNAL|MSG_MORE|MSG_BATCH|MSG_CMSG_CLOEXEC|0x1a820010}, msg_len=27}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\2064\1\0\0\1\0\0\0\0\0\0\5baidu\3com\0\0\34\0\1", iov_len=27}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=27}], 2, MSG_NOSIGNAL) = 2
poll([{fd=5, events=POLLIN}], 1, 5000)  = 0 (Timeout)

Why ???????

最后~最后的大招~ tcpdump

使用 ping -c 1 baidu.com 基本上是肉包子打狗了~~

tcpdump -vv  port 53
tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes

tcpdump -vv  port 53
tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes

19:51:15.650227 IP (tos 0x0, ttl 64, id 49884, offset 0, flags [DF], proto UDP (17), length 74)
    192.168.0.144.36493 > public1.114dns.com.domain: [udp sum ok] 35780+ PTR? 114.114.114.114.in-addr.arpa. (46)
    
19:51:15.707260 IP (tos 0x0, ttl 153, id 0, offset 0, flags [none], proto UDP (17), length 106)
    public1.114dns.com.domain > 192.168.0.144.36493: [udp sum ok] 35780 q: PTR? 114.114.114.114.in-addr.arpa. 1/0/0 114.114.114.114.in-addr.arpa. PTR public1.114dns.com. (78)

19:51:15.707453 IP (tos 0x0, ttl 64, id 49894, offset 0, flags [DF], proto UDP (17), length 72)
    192.168.0.144.59603 > public1.114dns.com.domain: [udp sum ok] 60558+ PTR? 144.0.168.192.in-addr.arpa. (44)

19:51:15.761322 IP (tos 0x0, ttl 152, id 0, offset 0, flags [none], proto UDP (17), length 107)
    public1.114dns.com.domain > 192.168.0.144.59603: [udp sum ok] 60558 NXDomain* q: PTR? 144.0.168.192.in-addr.arpa. 0/1/0 ns: 168.192.in-addr.arpa. SOA 168.192.in-addr.arpa. . 0 28800 7200 604800 86400 (79)

19:51:16.509198 IP (tos 0x0, ttl 64, id 49993, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.0.144.42712 > public1.114dns.com.domain: [udp sum ok] 19260+ A? baidu.com. (27)

19:51:16.509393 IP (tos 0x0, ttl 64, id 49994, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.0.144.42712 > public1.114dns.com.domain: [udp sum ok] 63372+ AAAA? baidu.com. (27)

19:51:21.514959 IP (tos 0x0, ttl 64, id 50205, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.0.144.42712 > public1.114dns.com.domain: [udp sum ok] 19260+ A? baidu.com. (27)

19:51:21.515989 IP (tos 0x0, ttl 64, id 50206, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.0.144.42712 > public1.114dns.com.domain: [udp sum ok] 63372+ AAAA? baidu.com. (27)

19:51:26.523396 IP (tos 0x0, ttl 64, id 50696, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.0.144.49965 > public1.114dns.com.domain: [udp sum ok] 20751+ A? baidu.com. (27)

19:51:26.524106 IP (tos 0x0, ttl 64, id 50697, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.0.144.49965 > public1.114dns.com.domain: [udp sum ok] 11457+ AAAA? baidu.com. (27)

19:51:31.530035 IP (tos 0x0, ttl 64, id 51742, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.0.144.49965 > public1.114dns.com.domain: [udp sum ok] 20751+ A? baidu.com. (27)

19:51:31.530357 IP (tos 0x0, ttl 64, id 51743, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.0.144.49965 > public1.114dns.com.domain: [udp sum ok] 11457+ AAAA? baidu.com. (27)

使用 dig @114.114.114.114 baidu.com 抓到的包, 是能正常返回的.

tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
18:52:36.562523 IP (tos 0x0, ttl 64, id 6167, offset 0, flags [none], proto UDP (17), length 66)
    192.168.0.144.36898 > public1.114dns.com.domain: [udp sum ok] 34054+ [1au] A? baidu.com. ar: . OPT UDPsize=4096 (38)

18:52:36.619811 IP (tos 0x0, ttl 152, id 0, offset 0, flags [none], proto UDP (17), length 98)
    public1.114dns.com.domain > 192.168.0.144.36898: [udp sum ok] 34054 q: A? baidu.com. 2/0/1 baidu.com. A 123.125.114.144, baidu.com. A 220.181.57.216 ar: . OPT UDPsize=512 (70)

由于水平有限,只能一吐心疑惑了

1. 是为什么我已经停掉 ipv6了 为什么还会发启 AAAA 查询?
2. public1.114dns.com 查询返回的是 NXDomain ?
3. 对比dump 好像只有 flags 有点区别, 但我不太明白这个区别的意思?
4. 为什么 dig, nslookup 可以正常解析, 但是 ping , curl , wget 一类的都无法正常解析?

最后的~最后的~最后

经过整整2天不少于20个小时.我始终搞不定让 Debian 使用域名访问网络,此刻的百度我觉得好远~~~

特发此问,望各位老中医,救死扶伤~~~

Answer 1

前前后后 30 多个小时, 终于解决了. 太久没有自己装过Linux 都是用云服务器,开机就用~~导致很多东西脱节~还停留在CentOS 6的时代.