Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Cyberbob 05. 02. 2024, 17:16:21
-
Zdravím. Provozuji Ubuntu 22.04.3 LTS a pokaždé, když restartuji router, DHCP přidělí Ubuntu řádně IP, ale z Ubuntu se nikam nedostanu, ani nepingnu. Dokud samotné Ubuntu nerestartuji, poté vše funguje zase korektně. Už nevím, na co bych se měl zaměřit.
-
Je třeba se v tom špatném stavu podívat na nastavení sítě:
# ip a (ukáže adresy na rozhraních)
# ip r (ukáže směrovací tabulku)
# resolvectl status (ukáže nastaveni DNS resolveru)
Co přesně znamená „nikam se nedostanu“? Nedá se ani poslat ping na IP adresu routeru?
-
Pokusy jsem prozatím zjistil, že po tom restartu router pingnu, ale třeba 8.8.8.8 nikoli. Při pokusu o ping 8.8.8.8 mi to hlásí chybu, že nelze nalézt cestu přes adresu 169.254.167.203, což je adresa nějakého "veth064735d" interface. Předpokládám, že se jedná o nějaký virtuální iface. Přitom ta adresa, kterou má přidělenou je nesmysl.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul t 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: enp3s0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:1b:22:81:42:f3 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.8/24 brd 192.168.1.255 scope global enp3s0
valid_lft forever preferred_lft forever
inet6 fe80::21b:22ff:fe81:42f3/64 scope link
valid_lft forever preferred_lft forever
3: br-809ae510f097: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue sta te UP group default
link/ether 02:42:de:57:cb:4a brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-809ae510f097
valid_lft forever preferred_lft forever
inet6 fe80::42:deff:fe57:cb4a/64 scope link
valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP gr oup default
link/ether 02:42:49:88:fa:b0 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:49ff:fe88:fab0/64 scope link
valid_lft forever preferred_lft forever
6: veth064735d@if5: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc noq ueue master br-809ae510f097 state UP group default
link/ether 56:3e:93:95:cf:8c brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet 169.254.167.203/16 brd 169.254.255.255 scope global veth064735d
valid_lft forever preferred_lft forever
inet6 fe80::543e:93ff:fe95:cf8c/64 scope link
valid_lft forever preferred_lft forever
8: vethe870bd6@if7: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc noq ueue master docker0 state UP group default
link/ether aa:61:7e:c3:2e:43 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 169.254.78.121/16 brd 169.254.255.255 scope global vethe870bd6
valid_lft forever preferred_lft forever
inet6 fe80::a861:7eff:fec3:2e43/64 scope link
valid_lft forever preferred_lft forever
-
vyzera ze ti nejde DHCP...
https://datatracker.ietf.org/doc/html/rfc3927.html
To participate in wide-area IP networking, a host needs to be
configured with IP addresses for its interfaces, either manually by
the user or automatically from a source on the network such as a
Dynamic Host Configuration Protocol (DHCP) server. Unfortunately,
such address configuration information may not always be available.
It is therefore beneficial for a host to be able to depend on a
useful subset of IP networking functions even when no address
configuration is available. This document describes how a host may
automatically configure an interface with an IPv4 address within the
169.254/16 prefix that is valid for communication with other devices
connected to the same physical (or logical) link.
otazka je ci na strane routera alebo ubuntu hostu?
-
ale na enp3s0 mas dobru ip. co povie route?
-
Ta adresa na veth není nesmysl, adresy z rozsahu 169.254.0.0/16 definuje RFC 3927 (https://datatracker.ietf.org/doc/html/rfc3927) a jde o automaticky konfigurované adresy, jejichž použití nevyžaduje DHCP.
Potřebujeme vědět, jak vypadá směrování z toho stroje, takže potřebujeme znát výstup příkazu
# ip r
Prosím vložte ho do bloku [ code] a [ /code] (bez mezer za závorkami), aby se to tak ošklivě nerozpadlo, jako prve.
-
Standardní stav:
default via 192.168.1.1 dev enp3s0
default via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.8 metric 100
147.228.57.10 via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.8 metric 100
169.254.0.0/16 dev veth064735d proto kernel scope link src 169.254.167.203
169.254.0.0/16 dev vethe870bd6 proto kernel scope link src 169.254.78.121
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-809ae510f097 proto kernel scope link src 172.18.0.1
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.8 metric 100
192.168.1.1 dev enp3s0 scope link
192.168.1.1 dev enp3s0 proto dhcp scope link src 192.168.1.8 metric 100
195.113.144.201 via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.8 metric 100
195.113.144.238 via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.8 metric 100
Po výpadku:
default dev veth064735d scope link
default via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.8 metric 100
147.228.57.10 via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.8 metric 100
169.254.0.0/16 dev veth064735d proto kernel scope link src 169.254.167.203
169.254.0.0/16 dev vethe870bd6 proto kernel scope link src 169.254.78.121
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-809ae510f097 proto kernel scope link src 172.18.0.1
192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.8
192.168.1.1 dev enp3s0 scope link
192.168.1.1 dev enp3s0 proto dhcp scope link src 192.168.1.8 metric 100
195.113.144.201 via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.8 metric 100
195.113.144.238 via 192.168.1.1 dev enp3s0 proto dhcp src 192.168.1.8 metric 100
-
Vyřešeno. Netplan si v podstatě dělal co chtěl. V YAML jsem nastavil statické adresy. To fungovalo, ale DHCP mu stejně přidělil ještě jednu i když bylo v configu:
dhcp4: no
Už jsem na to neměl nervy. Tak jsem se vykašlal na CLI, vlezl do Ubuntu Desktop přes RDP a tam v Connman vypnul u těch veth Autoconnect a je klid, vše funguje, jak má.