Featured image of post Ubuntu Server 20.04以上版本的网络故障排查
运维笔记

Ubuntu Server 20.04以上版本的网络故障排查

对netplan等进行网络故障排查

Ubuntu 20.04在使用时会出现网络不通的情况。由于网络上大量指南教程相互抄袭，让各位排查桌面版本用的NetworkManager。我这里写一个用于18.04以上版本的Server系统网络故障排查指南。

服务器版Ubuntu使用netplan来管理网络！

netplan可靠性并没有想象中那么完美！

Ubuntu可靠性达不到我能接受的程度！

CentOS已经完蛋了！

RedHat上手有一定的学习成本而且要花钱买！

综上！

你需要学会排查Ubuntu网络问题。

问题现象

192.168.4.33无法访问网络

  1. Minio所在9001端口无法访问
  2. SSH无法登录

初步判断

我们进行了跨网段的业务访问，中间经历了

graph TB 192.168.10.191 --> 192.168.10.1 192.168.10.1 --> 192.168.4.1 192.168.4.1 -->|故障排查点1| 192.168.4.33[192.168.4.33] 192.168.4.33[192.168.4.33内部转换到172.24.0.1] -->|故障排查点2| 172.24.0.2

由于访问其他192.168.4.0/24的业务都是正常的，所以我们初步估计的排查点包含上面两个位置。

推荐排查方向

我们将从排查点1进行排查，首先确定机器内外是否正常通信，再判断机器内部是否出现故障。

故障排查点1检查

  1. 机器硬盘、内存、CPU占用排查

    如果业务无法访问，最大的可能是资源被打爆了

    1
2
3
4
5
6

    # 检查磁盘占用
df -h
# 检查内存占用
free -h
# 检查CPU占用
top

    磁盘占用可以使用du -sh *一层层排查占用最高的文件夹，手动去调整。

    内存占用则需要ps aux | head -1;ps aux |grep -v PID |sort -rn -k +4 | head -20查看占用前20的进程，可以针对性的KILL掉。

    CPU占用则直接根据top显示情况KILL进程。

  2. 检查VPN或SDN是否正常

    如果你在云上有机器但需要连接到本地局域网络的需求，会用到这个。

    常见的开源实现包括OpenVPN、WireGuard、ZeroTier等，如果你有这些网络工具，请根据对应工具手册进行排查。

  3. ping检测

    1

    ping 192.168.4.33

    确保ICMP协议没有被阻拦，检查能否ping通。

  4. 路由排查

    1

    ip route show

    检查路由是否正常，是否设置网关，是否存在阻断等。如果存在路由问题，请编辑路由，或根据日志排查出路由被编辑的原因。

  5. 临时关闭防火墙

    1
2
3
4

    # 查看当前ufw状态
ufw status
# 关闭ufw
ufw disable

    临时关闭防火墙，再次访问故障业务端口，检查是否能够正常访问，这一步排除防火墙的影响。

    如果使用了Docker等容器产品，可能ufw已经被这些产品关闭，注意在关闭防火墙前检查一下ufw status，确保关闭防火墙前的状态，不要影响到其他产品的状态。

  6. 使用Python HTTP服务器测试其他端口是否能够正常访问

    1

    python3 -m http.server --bind 0.0.0.0 10001

    10001端口如果被占用可以使用其他未被占用的端口。

    防火墙应当仍处于关闭状态。 这一步和第一步排查的区别在于：

    • ICMP 属于网络层协议,工作在IP数据报层。
    • TCP/UDP 属于传输层协议,工作在IP层之上。
    • ICMP 常用于网络层核心功能。
    • TCP/UDP 用于应用层程序间通信。

    在公网环境中，有可能存在某些中间设备禁止ICMP报文的情况，为了适应这种情况，我们一般会多检查一次应用层。

  7. 检查网卡配置问题

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

    user@archive-deployments:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:03:41:10 brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.33/24 brd 192.168.4.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe03:4110/64 scope link 
       valid_lft forever preferred_lft forever
3: br-95073cd31fb9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:91:58:9c:d0 brd ff:ff:ff:ff:ff:ff
    inet 172.24.0.1/16 brd 172.24.255.255 scope global br-95073cd31fb9
       valid_lft forever preferred_lft forever
    inet6 fe80::42:91ff:fe58:9cd0/64 scope link 
       valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:5d:ff:24:62 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:5dff:feff:2462/64 scope link 
       valid_lft forever preferred_lft forever
6: veth423d5b3@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-95073cd31fb9 state UP group default 
    link/ether b2:e5:1e:12:c2:cb brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::b0e5:1eff:fe12:c2cb/64 scope link 
       valid_lft forever preferred_lft forever
10: veth1e84c8b@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default 
    link/ether 4e:56:51:b2:c2:c2 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::4c56:51ff:feb2:c2c2/64 scope link 
       valid_lft forever preferred_lft forever

    这里注意观察eth0网卡的IP地址、MAC地址、网关和子网掩码，确保没有错误。

    如果机器是虚拟机，请在宿主机或者管理平台检查对应的网卡IP地址、MAC地址、VLAN等是否存在差异。

    动态IP的情况

    对于动态IP的情况，我在其他集群环境里遇到过IP丢失的问题。这种情况一般需要重启netplan或者重新配置netplan配置文件。

    配置路径在/etc/netplan/00-installer-config.yaml里，注意这里的文件名可能不同。

    修改完配置重启netplan，重新执行netplan apply。

    另外，需要检查dhclient是否正常。

    网卡eth0丢失的情况

    如果机器是虚拟机，请检查宿主机的网卡是否正确挂载

    如果机器是实体机，请更换网卡确保PCIE接口没有问题，同时将换下来的卡插在其他设备上测试确保网卡正常

    如果上述排查没有问题，继续检查netplan

    参考Ubuntu18.04实例重启后网络不通 (aliyun.com)

故障排查点2检查

一般情况下问题都出现在故障点1，经过上面的排查就可以基本解决问题了，但如果系统内部经常有访问

当对外排查正常无误时，一般需要排查应用是否正常。

能访问的理由只能是配置无误，但故障的理由却是各有各的不同，这里我只能提供一些最基础的排查方案，后续则可以根据基础排查的现象和结果进行进一步筛查。

  1. 检查端口占用

    1

    lsof -i:端口号

​ 如果业务对外的端口占用没有输出或输出的IP不对，请检查

  1. 应用是否正确绑定了网卡

  2. 进程是否仍然在运行。一些可能的情况是在开发时错误的绑定了127.0.0.1:端口号，或者绑定到了其他端口号上，具体情况需要根据日志和配置文件进行详细检查。

  3. 如果使用Docker，请仔细检查内部的监听端口和外部的暴漏端口是否能够正确对应，以及对外暴漏端口绑定的网卡是否正确。

  4. 容器内的业务是否绑定到机器名或域名上，但对应机器名或域名没有在DNS上绑定到外部IP。

    一般常见于WEB业务，比较明显的现象是浏览器跳转到了某一个特殊的域名，并且这个域名无法访问。

  5. 应用出现错误

    例如之前在某台机器上使用Docker部署Atlassian Jira和Atlassian Confluence，跑一周左右，Docker后台进程会出现无响应状态，通过外部端口管理该Docker或通过内部Socket管理该Docker均提示Docker操作超时。这种情况需要考虑重启Docker以及内部的容器业务来解决。

其他可能的情况

  1. 驱动问题。查看dmesg日志,试着更新驱动版本。
  2. 网卡工作模式不正确。某些虚拟网卡需要设置为bridge模式才能通信。
  3. selinux。可以使用setenforce 0设置临时关闭selinux测试。
  4. 其他内核参数问题,如禁用了ICMP重定向等。
  5. 与虚拟化环境相关的网络配置问题。

排查时先检查网卡硬件状态,然后确认IP和路由配置,最后可以查看日志获得更多信息。