☰

解决方案和解释

tag-icon • tag-icon networking dns dhcp routing
解决方案和解释

我重新配置了家用路由器，使用 192.168.39.0 作为子网。之前是 192.168.0.0

我有一台 Ubuntu 22.04 机器，现在 DNS 和/或路由已损坏。我已经排除了硬件问题（从外部驱动器上的 ubuntu 22.04 启动它没有问题）。网络上的其他一切都很好，包括这台 ubuntu 22.10 笔记本电脑。

这台有问题的机器有两个有线接口和 wifi。全部连接到 LAN，但所有接口的 DNS 都坏了。可以 ping 通，例如 ping 8.8.8.8 可以，但第一次 ping 延迟很长（>2 秒）。

存在严重的路由问题。例如，尝试访问另一台主机：

# ping archimedes.local
PING archimedes.local (192.168.39.37) ....
From 192.168.39.1 icmp_seq=1 Destination Host Unreachable

但是

ping 192.168.39.37

作品

我无法 ssh 到任何机器：我收到密码提示，但密码未正确传送。

ping 8.8.8.8 有效，ping google.com 失败（名称或服务未知）。

resolvectl status

将损坏的 Ubuntu 与我正常工作的笔记本电脑进行比较，得出了相同的结果。

/etc/resolv.conf 也相同。

我也无法从我的笔记本电脑 ssh 进入有问题的主机。

我已将 DHCP 设置为开启，而不是固定 IP 租约。它可以顺利获取 IP 地址。

在正常工作的机器上，tracepath 如下所示：

root@yellow:/home/tim# tracepath 8.8.8.8
 1?: [LOCALHOST]                      pmtu 1500
 1:  ipfire.rumahtumi                                      8.979ms 
 1:  ipfire.rumahtumi                                      3.329ms 
 2:  loop119171560.bng.mel.aussiebb.net                   12.075ms 
 3:  ???                                                  13.824ms asymm  5 
 4:  10.241.4.142                                         20.187ms 
 5:  10.241.4.147                                         15.787ms asymm  3 
 6:  142.250.165.14                                       14.676ms asymm  5

ipfire.rumahtumi 是路由器

在坏掉的机器上，第 1 行是相同的，但以下几行是

无回复

没有提及 ipfire.rumahtumi

#路线-n

显示正确的网关。

编辑。问题机器的更多输出：

route -n 和 resolvectl status

root@indigo:/home/tim# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.39.1    0.0.0.0         UG    20100  0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 virbr1
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.39.0    0.0.0.0         255.255.255.0   U     0      0        0 virbr1
192.168.39.0    0.0.0.0         255.255.255.0   U     100    0        0 eth1
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0



root@indigo:/home/tim# resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth2)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (eth1)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.39.1
       DNS Servers: 192.168.39.1
        DNS Domain: rumahtumi

Link 4 (wlp6s0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (virbr1)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (virbr0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 8 (docker0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
root@indigo:/home/tim#

解决方案和解释

我这样做时，我注意到路由表中 virbr1 看起来有点奇怪。

我删除了该设备，连接已恢复。但是，每次启动时都会继续恢复。

... 我找到了原因。我安装了 minikube。它创建了一个在启动时自动启动的网桥。它选择 192.168.39.0 作为其子网。只是运气不好。

可以使用以下方式 /etc/libvirt/qemu/networks/autostart 编辑子网virsh net-edit mk-minikube

相关内容