Início / unix / 问题

All perguntas(unix)

Martin Hope
Helios5584
Asked: 2025-03-10 12:11:48 +0800 CST
  • 5

SO: Nobara Linux 41 (atualizado)

Procurei nos fóruns possíveis soluções para esse problema, mas ainda não consigo fazer funcionar.

Tenho um serviço criado pelo usuário que estou tentando executar na inicialização, mas ele não está sendo executado na inicialização. O serviço funciona bem quando executado manualmente.

Este é o serviço:

[Unit]
Description=CPU Performance Mode

[Service]
Type=oneshot
ExecStart=bash -c 'cpupower -c all frequency-set -g performance'
Restart=on-failure

[Install]
WantedBy=default.target

O objetivo deste serviço é definir os núcleos da minha CPU para o modo de desempenho com cpupower.

Ao executar systemctl status cpuperformance.service(o nome do serviço), obtenho:

     Loaded: loaded (/etc/systemd/system/cpuperformance.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf, 50-keep-warm.conf
     Active: inactive (dead) since Sun 2025-03-09 22:38:28 CDT; 12min ago
 Invocation: 7c187bdfd07c49c48fd6e94ccc34a0e3
   Main PID: 1442 (code=exited, status=0/SUCCESS)
   Mem peak: 1.3M
        CPU: 6ms

Mar 09 22:38:28 HynixPC bash[1442]: Setting cpu: 16
Mar 09 22:38:28 HynixPC bash[1442]: Setting cpu: 17
Mar 09 22:38:28 HynixPC bash[1442]: Setting cpu: 18
Mar 09 22:38:28 HynixPC bash[1442]: Setting cpu: 19
Mar 09 22:38:28 HynixPC bash[1442]: Setting cpu: 20
Mar 09 22:38:28 HynixPC bash[1442]: Setting cpu: 21
Mar 09 22:38:28 HynixPC bash[1442]: Setting cpu: 22
Mar 09 22:38:28 HynixPC bash[1442]: Setting cpu: 23
Mar 09 22:38:28 HynixPC systemd[1]: cpuperformance.service: Deactivated successfully.
Mar 09 22:38:28 HynixPC systemd[1]: Finished cpuperformance.service - CPU Performance Mode.

Parece que o serviço foi executado com sucesso na inicialização, porém se eu cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor, obtenho:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave

Isso mostra que os núcleos da CPU estão usando o regulador de economia de energia e não o regulador de desempenho, como deveriam estar após a inicialização com este serviço.

Testei diferentes alvos "WantedBy", incluindo basic.target e multi-user.target. Ambos têm o mesmo problema. Toda vez que faço uma alteração no serviço, executo sudo systemctl disable cpuperformance.service-> sudo systemctl daemon-reload-> sudo systemctl enable cpuperformance.service.

O resultado da ativação do serviço é: Created symlink '/etc/systemd/system/default.target.wants/cpuperformance.service' → '/etc/systemd/system/cpuperformance.service'.Depois disso, o serviço ainda não consegue iniciar na inicialização.

Encontrei uma pista que pode mostrar por que isso não está funcionando. Executando systemctl --user list-dependencies default.target, obtenho a seguinte saída:

default.target
○ ├─drkonqi-coredump-cleanup.service
● ├─drkonqi-sentry-postman.path
● ├─unity-gtk-module.service
● └─basic.target
●   ├─systemd-tmpfiles-setup.service
●   ├─paths.target
●   ├─sockets.target
●   │ ├─dbus.socket
●   │ ├─drkonqi-coredump-launcher.socket
●   │ ├─pipewire-pulse.socket
●   │ └─pipewire.socket
●   └─timers.target
○     ├─drkonqi-coredump-cleanup.timer
○     ├─drkonqi-sentry-postman.timer
●     ├─grub-boot-success.timer
●     └─systemd-tmpfiles-clean.timer

Isso mostra que meu cpuperformance.service personalizado não é desejado por default.target, o que não entendo, já que meu serviço especificamente tem isso listado.

Alguém tem alguma ideia sobre isso? Estou quebrando a cabeça com isso há horas. Qualquer ajuda é bem-vinda!

services
Martin Hope
Rafael Mora
Asked: 2025-03-10 10:17:12 +0800 CST
  • 5

Informações do cluster:

kubectl version
Client Version: v1.29.14
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.14
Cloud being used: bare-metal
Installation method:
Host OS: AlmaLinux 8
CNI and version: Flannel ver: 0.26.4
CRI and version: cri-dockerd ver: 0.3.16

Tenho um nó mestre e criei meu primeiro nó de trabalho. Antes de executar o comando kubeadm join no trabalho, eu conseguia fazer ping do trabalho para o mestre e vice-versa sem problemas. Agora que executei o kubeadm join ... comando, não consigo mais fazer ping entre eles e recebo este erro:

[root@worker-1 ~]# kubectl get nodes -o wide
E0308 19:38:31.027307   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
E0308 19:38:32.051145   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
E0308 19:38:33.075350   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
E0308 19:38:34.099160   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
E0308 19:38:35.123011   59324 memcache.go:265] couldn't get current server API group list: Get "https://198.58.126.88:6443/api?timeout=32s": dial tcp 198.58.126.88:6443: connect: connection refused
The connection to the server 198.58.126.88:6443 was refused - did you specify the right host or port?

Ping do nó de trabalho para o nó mestre:

[root@worker-1 ~]# ping 198.58.126.88
PING 198.58.126.88 (198.58.126.88) 56(84) bytes of data.
From 198.58.126.88 icmp_seq=1 Destination Port Unreachable
From 198.58.126.88 icmp_seq=2 Destination Port Unreachable
From 198.58.126.88 icmp_seq=3 Destination Port Unreachable

Se eu executar isto:

[root@worker-1 ~]# iptables -F && sudo iptables -t nat -F && sudo iptables -t mangle -F && sudo iptables -X

O comando ping começa a funcionar:

[root@worker-1 ~]# ping 198.58.126.88
PING 198.58.126.88 (198.58.126.88) 56(84) bytes of data.
64 bytes from 198.58.126.88: icmp_seq=1 ttl=64 time=0.030 ms
64 bytes from 198.58.126.88: icmp_seq=2 ttl=64 time=0.025 ms

(O comando ping funciona com o endereço IPv6, mas falha com o endereço IPv4) Mas depois de cerca de um minuto ele é bloqueado novamente:

[root@worker-1 ~]# ping 198.58.126.88
PING 198.58.126.88 (198.58.126.88) 56(84) bytes of data.
From 198.58.126.88 icmp_seq=1 Destination Port Unreachable
From 198.58.126.88 icmp_seq=2 Destination Port Unreachable

[root@worker-1 ~]# cat /etc/sysctl.conf
# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1

[root@worker-1 ~]# cd /etc/systctl.d/
-bash: cd: /etc/systctl.d/: No such file or directory

A porta 6443/TCPestá fechada no nó de trabalho e tentei abri-la sem sucesso:

nmap 172.235.135.144 -p 6443                                                                                            ✔  2.7.4   06:19:47
Starting Nmap 7.95 ( https://nmap.org ) at 2025-03-11 16:22 -05
Nmap scan report for 172-235-135-144.ip.linodeusercontent.com (172.235.135.144)
Host is up (0.072s latency).

PORT     STATE  SERVICE
6443/tcp closed sun-sr-https

Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds

nó mestre:

[root@master ~]# iptables -nvL
Chain INPUT (policy ACCEPT 1312K packets, 202M bytes)
 pkts bytes target     prot opt in     out     source               destination
1301K  201M KUBE-FIREWALL  all  --  *      *       0.0.0.0/0            0.0.0.0/0
1311K  202M KUBE-IPVS-FILTER  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes ipvs access filter */
1311K  202M KUBE-PROXY-FIREWALL  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-proxy firewall rules */
1311K  202M KUBE-NODE-PORT  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes health check rules */
   40  3520 ACCEPT     icmp --  *      *       198.58.126.88        0.0.0.0/0
    0     0 ACCEPT     icmp --  *      *       172.233.172.101      0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  950  181K KUBE-PROXY-FIREWALL  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-proxy firewall rules */
  950  181K KUBE-FORWARD  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding rules */
  212 12626 DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  212 12626 DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      br-09363fc9af47  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
   20  1068 DOCKER     all  --  *      br-09363fc9af47  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br-09363fc9af47 !br-09363fc9af47  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br-09363fc9af47 br-09363fc9af47  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      br-05a2ea8c281b  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    4   184 DOCKER     all  --  *      br-05a2ea8c281b  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br-05a2ea8c281b !br-05a2ea8c281b  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br-05a2ea8c281b br-05a2ea8c281b  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      br-032fd1b78367  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      br-032fd1b78367  0.0.0.0/0            0.0.0.0/0
    9   504 ACCEPT     all  --  br-032fd1b78367 !br-032fd1b78367  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br-032fd1b78367 br-032fd1b78367  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      br-ae1997e801f3  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      br-ae1997e801f3  0.0.0.0/0            0.0.0.0/0
  132  7920 ACCEPT     all  --  br-ae1997e801f3 !br-ae1997e801f3  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br-ae1997e801f3 br-ae1997e801f3  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      br-9f6d34f7e48a  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
   14   824 DOCKER     all  --  *      br-9f6d34f7e48a  0.0.0.0/0            0.0.0.0/0
    4   240 ACCEPT     all  --  br-9f6d34f7e48a !br-9f6d34f7e48a  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br-9f6d34f7e48a br-9f6d34f7e48a  0.0.0.0/0            0.0.0.0/0
   29  1886 FLANNEL-FWD  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* flanneld forward */

Chain OUTPUT (policy ACCEPT 1309K packets, 288M bytes)
 pkts bytes target     prot opt in     out     source               destination
1298K  286M KUBE-FIREWALL  all  --  *      *       0.0.0.0/0            0.0.0.0/0
1308K  288M KUBE-IPVS-OUT-FILTER  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes ipvs access filter */

Chain DOCKER (6 references)
 pkts bytes target     prot opt in     out     source               destination
   14   824 ACCEPT     tcp  --  !br-9f6d34f7e48a br-9f6d34f7e48a  0.0.0.0/0            172.24.0.2           tcp dpt:3001
    0     0 ACCEPT     tcp  --  !br-ae1997e801f3 br-ae1997e801f3  0.0.0.0/0            172.21.0.2           tcp dpt:3000
    4   184 ACCEPT     tcp  --  !br-05a2ea8c281b br-05a2ea8c281b  0.0.0.0/0            172.22.0.2           tcp dpt:4443
   12   700 ACCEPT     tcp  --  !br-09363fc9af47 br-09363fc9af47  0.0.0.0/0            172.19.0.2           tcp dpt:4443
    8   368 ACCEPT     tcp  --  !br-09363fc9af47 br-09363fc9af47  0.0.0.0/0            172.19.0.3           tcp dpt:443

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination
  212 12626 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FLANNEL-FWD (1 references)
 pkts bytes target     prot opt in     out     source               destination
   29  1886 ACCEPT     all  --  *      *       10.244.0.0/16        0.0.0.0/0            /* flanneld forward */
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            10.244.0.0/16        /* flanneld forward */

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination
  212 12626 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain KUBE-FORWARD (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding rules */
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding conntrack rule */ ctstate RELATED,ESTABLISHED

Chain KUBE-NODE-PORT (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* Kubernetes health check node port */ match-set KUBE-HEALTH-CHECK-NODE-PORT dst

Chain KUBE-PROXY-FIREWALL (2 references)
 pkts bytes target     prot opt in     out     source               destination

Chain KUBE-SOURCE-RANGES-FIREWALL (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain KUBE-IPVS-FILTER (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-LOAD-BALANCER dst,dst
    2   104 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-EXTERNAL-IP dst,dst
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-EXTERNAL-IP-LOCAL dst,dst
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-HEALTH-CHECK-NODE-PORT dst
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate NEW match-set KUBE-IPVS-IPS dst reject-with icmp-port-unreachable

Chain KUBE-IPVS-OUT-FILTER (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain KUBE-FIREWALL (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *      !127.0.0.0/8          127.0.0.0/8          /* block incoming localnet connections */ ! ctstate RELATED,ESTABLISHED,DNAT

Chain KUBE-KUBELET-CANARY (0 references)
 pkts bytes target     prot opt in     out     source               destination

nó trabalhador:

[root@worker-1 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
18469 1430K KUBE-IPVS-FILTER  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes ipvs access filter */
10534  954K KUBE-PROXY-FIREWALL  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-proxy firewall rules */
10534  954K KUBE-NODE-PORT  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes health check rules */
10767 1115K KUBE-FIREWALL  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 KUBE-PROXY-FIREWALL  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-proxy firewall rules */
    0     0 KUBE-FORWARD  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding rules */
    0     0 DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
18359 1696K KUBE-IPVS-OUT-FILTER  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes ipvs access filter */
18605 1739K KUBE-FIREWALL  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain KUBE-FIREWALL (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *      !127.0.0.0/8          127.0.0.0/8          /* block incoming localnet connections */ ! ctstate RELATED,ESTABLISHED,DNAT

Chain KUBE-KUBELET-CANARY (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain KUBE-FORWARD (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding rules */
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding conntrack rule */ ctstate RELATED,ESTABLISHED

Chain KUBE-NODE-PORT (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* Kubernetes health check node port */ match-set KUBE-HEALTH-CHECK-NODE-PORT dst

Chain KUBE-PROXY-FIREWALL (2 references)
 pkts bytes target     prot opt in     out     source               destination

Chain KUBE-SOURCE-RANGES-FIREWALL (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain KUBE-IPVS-FILTER (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-LOAD-BALANCER dst,dst
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-EXTERNAL-IP dst,dst
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-EXTERNAL-IP-LOCAL dst,dst
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set KUBE-HEALTH-CHECK-NODE-PORT dst
   45  2700 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate NEW match-set KUBE-IPVS-IPS dst reject-with icmp-port-unreachable

Chain KUBE-IPVS-OUT-FILTER (1 references)
 pkts bytes target     prot opt in     out     source               destination

Se eu executar iptables -F INPUTo worker, o comando ping começa a funcionar novamente:

[root@worker-1 ~]# iptables -F INPUT
[root@worker-1 ~]# ping 198.58.126.88
PING 198.58.126.88 (198.58.126.88) 56(84) bytes of data.
64 bytes from 198.58.126.88: icmp_seq=1 ttl=64 time=0.054 ms
64 bytes from 198.58.126.88: icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from 198.58.126.88: icmp_seq=3 ttl=64 time=0.037 ms
64 bytes from 198.58.126.88: icmp_seq=4 ttl=64 time=0.039 ms
64 bytes from 198.58.126.88: icmp_seq=5 ttl=64 time=0.023 ms
64 bytes from 198.58.126.88: icmp_seq=6 ttl=64 time=0.022 ms
64 bytes from 198.58.126.88: icmp_seq=7 ttl=64 time=0.070 ms
64 bytes from 198.58.126.88: icmp_seq=8 ttl=64 time=0.072 ms
^C
--- 198.58.126.88 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7197ms
rtt min/avg/max/mdev = 0.022/0.045/0.072/0.017 ms

comando strace do trabalhador:

[root@worker-1 ~]# iptables -F INPUT
[root@worker-1 ~]# strace -eopenat kubectl version
openat(AT_FDCWD, "/sys/kernel/mm/transparent_hugepage/hpage_pmd_size", O_RDONLY) = 3
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
openat(AT_FDCWD, "/usr/bin/kubectl", O_RDONLY|O_CLOEXEC) = 3
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=20723, si_uid=0} ---
openat(AT_FDCWD, "/usr/local/sbin", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/local/bin", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/sbin", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/bin", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/root/bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/root/.kube/config", O_RDONLY|O_CLOEXEC) = 3
Client Version: v1.29.14
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
The connection to the server 198.58.126.88:6443 was refused - did you specify the right host or port?
+++ exited with 1 +++

nftables antes e depois de executar o comando kubeadm join no worker insira a descrição da imagem aqui

Chain KUBE-IPVS-FILTER (0 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere             match-set KUBE-LOAD-BALANCER dst,dst
RETURN     all  --  anywhere             anywhere             match-set KUBE-CLUSTER-IP dst,dst
RETURN     all  --  anywhere             anywhere             match-set KUBE-EXTERNAL-IP dst,dst
RETURN     all  --  anywhere             anywhere             match-set KUBE-EXTERNAL-IP-LOCAL dst,dst
RETURN     all  --  anywhere             anywhere             match-set KUBE-HEALTH-CHECK-NODE-PORT dst
REJECT     all  --  anywhere             anywhere             ctstate NEW match-set KUBE-IPVS-IPS dst reject-with icmp-port-unreachable

[root@worker-1 ~]# sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N KUBE-FIREWALL
-N KUBE-KUBELET-CANARY
-N KUBE-FORWARD
-N KUBE-NODE-PORT
-N KUBE-PROXY-FIREWALL
-N KUBE-SOURCE-RANGES-FIREWALL
-N KUBE-IPVS-FILTER
-N KUBE-IPVS-OUT-FILTER
-A INPUT -m comment --comment "kubernetes ipvs access filter" -j KUBE-IPVS-FILTER
-A INPUT -m comment --comment "kube-proxy firewall rules" -j KUBE-PROXY-FIREWALL
-A INPUT -m comment --comment "kubernetes health check rules" -j KUBE-NODE-PORT
-A FORWARD -m comment --comment "kube-proxy firewall rules" -j KUBE-PROXY-FIREWALL
-A FORWARD -m comment --comment "kubernetes forwarding rules" -j KUBE-FORWARD
-A OUTPUT -m comment --comment "kubernetes ipvs access filter" -j KUBE-IPVS-OUT-FILTER
-A OUTPUT -j KUBE-FIREWALL
-A KUBE-FIREWALL ! -s 127.0.0.0/8 -d 127.0.0.0/8 -m comment --comment "block incoming localnet connections" -m conntrack ! --ctstate RELATED,ESTABLISHED,DNAT -j DROP
-A KUBE-FORWARD -m comment --comment "kubernetes forwarding rules" -j ACCEPT
-A KUBE-FORWARD -m comment --comment "kubernetes forwarding conntrack rule" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A KUBE-NODE-PORT -m comment --comment "Kubernetes health check node port" -m set --match-set KUBE-HEALTH-CHECK-NODE-PORT dst -j ACCEPT
-A KUBE-SOURCE-RANGES-FIREWALL -j DROP
-A KUBE-IPVS-FILTER -m set --match-set KUBE-LOAD-BALANCER dst,dst -j RETURN
-A KUBE-IPVS-FILTER -m set --match-set KUBE-CLUSTER-IP dst,dst -j RETURN
-A KUBE-IPVS-FILTER -m set --match-set KUBE-EXTERNAL-IP dst,dst -j RETURN
-A KUBE-IPVS-FILTER -m set --match-set KUBE-EXTERNAL-IP-LOCAL dst,dst -j RETURN
-A KUBE-IPVS-FILTER -m set --match-set KUBE-HEALTH-CHECK-NODE-PORT dst -j RETURN
-A KUBE-IPVS-FILTER -m conntrack --ctstate NEW -m set --match-set KUBE-IPVS-IPS dst -j REJECT --reject-with icmp-port-unreachable

A conexão bloqueada do worker para o master começa a acontecer assim que o serviço kubelet está em execução; se o serviço kubelet for interrompido, posso fazer ping de volta do worker para o master.

O que pode estar causando esse bloqueio no nó do trabalhador? Obrigado.

kubernetes
Martin Hope
ancoling67
Asked: 2025-03-10 03:56:00 +0800 CST
  • 5

Existe uma maneira de passar mais de uma opção ao executar um script?

Meu script tem este caso:

case "$1" in
 b)
 backup_start $1
 ;;

 h)
 _usage
 ;;

 *)
 echo 'Invalid option, -h for help'
 ;;
esac

Eu executo meu script com:

myscript -b backupname

Mas às vezes eu gostaria de executar o script com uma opção com outro argumento... que eu usarei então dentro do script:

myscript -b backupname -t mynewarg
bash
Martin Hope
Alemayhu Semenh
Asked: 2025-03-09 22:59:46 +0800 CST
  • 4

Existe uma maneira de executar systemctl daemon-reload no modo de recuperação. (Debian) Se sim, como?

Eu estava tentando mudar o ponto de montagem de uma das minhas unidades, então editei meu arquivo fstab para o local desejado. Então, tentei executar systemctl daemon-reload, mas não funcionou. Não consigo lembrar do erro que ele me deu, mas imaginei que se eu reiniciasse meu computador ele se consertaria sozinho...

GRANDE PROBLEMA

Depois que reiniciei, não consegui passar da tela de inicialização. A verificação do sistema de arquivos falharia naquela unidade, então eu ficaria preso em uma tela repetida. Entrei no modo de recuperação para descobrir qual é o problema e, pelo que entendi, simplesmente preciso executar o daemon-reload, mas como a única maneira de usar meu sistema é pelo modo de recuperação, não consigo executar o comando. Pelo que entendi, ele não será executado no modo de recuperação porque 1. Estou pedindo para ele reiniciar sozinho e ele não consegue fazer isso, ou 2. O systemd não está sendo executado no modo de recuperação.

2 é improvável para mim porque por que ele não estaria em execução, mas recebo o seguinte erro que me faz pensar que ele não está em execução.

Executando em chroot, ignorando o comando 'daemon-reload'

Então com sudo eu consigo um melhor

não é possível alocar pty: nenhum dispositivo desse tipo

Estou assumindo que o pty não existe no modo de recuperação, daí 2.

Meu entendimento do problema está correto? Alguém tem alguma sugestão sobre o que eu posso tentar fazer para executar o daemon-reload?

storage
Martin Hope
finefoot
Asked: 2025-03-09 21:34:27 +0800 CST
  • 9
mkfifo foo
printf %s\\n bar | tee foo &
tr -s '[:lower:]' '[:upper:]' <foo
wait
rm foo

Este é um script de shell POSIX funcional do que eu quero fazer:

  • printf %s\\n baré simbólico para um programa externo que produz stdout
  • tr -s '[:lower:]' '[:upper:]'é simbólico para outro comando que deve receber o stdout e fazer algo com ele
  • teeduplica stdout para pipe nomeado foo

E a saída é como esperado:

bar
BAR

Agora eu gostaria de arrumar o código para que ele se torne external_program | my_function. Algo assim:

f() (
  mkfifo foo
  tee foo &
  tr -s '[:lower:]' '[:upper:]' <foo
  wait
  rm foo
)
printf %s\\n bar | f

Mas agora não há saída alguma.

shell-script
Martin Hope
MiB_Coder
Asked: 2025-03-09 17:59:14 +0800 CST
  • 5

Tenho uma configuração com um volume lógico lvvm dentro de um grupo de volume vgsata. O lvvm foi criado com a opção thin -T:

sudo lvcreate -L 925G -T vgsata/lvvm

lsblk
...
sdc                     8:32   0 931,5G  0 disk  
└─sdc1                  8:33   0 931,5G  0 part  
  ├─vgsata-lvvm_tmeta 252:0    0   116M  0 lvm   
  │ └─vgsata-lvvm     252:2    0   925G  0 lvm   
  └─vgsata-lvvm_tdata 252:1    0   925G  0 lvm   
    └─vgsata-lvvm     252:2    0   925G  0 lvm

Quando o sistema é iniciado, posso montar o volume pelo terminal sem problemas:

sudo mount /dev/vgsata/lvvm /VM

Mas quando tento fazer isso com o fstab, adicionando a linha

/dev/mapper/vgsata-lvvm /VM ext4    defaults    0   2

O processo de inicialização agora leva 1-2 minutos a mais sem montar o volume. Em boot.logencontro alguns problemas relacionados a timeout:

[ TIME ] Timed out waiting for device dev-m…m.device - /dev/mapper/vgsata-lvvm.
[DEPEND] Dependency failed for systemd-fsck…m Check on /dev/mapper/vgsata-lvvm.
[DEPEND] Dependency failed for VM.mount - /VM.
[DEPEND] Dependency failed for local-fs.target - Local File Systems.

Também tentei usar UUIDs, mas, apesar de essa não parecer ser a maneira recomendada para LVM, o problema não foi resolvido.

Então qual seria a melhor maneira de montar um volume lógico durante o boot? Ou eu cometi um erro ao criar o volume fino?

linux-mint
Martin Hope
Hauke Laging
Asked: 2025-03-09 08:04:23 +0800 CST
  • 5

Este comando funciona como esperado se eu executá-lo na tmuxlinha de comando:

list-panes -a -F "pane ID: #{p3:pane_id}  TTY: #{p11:pane_tty}"

Saída:

pane ID: %1   TTY: /dev/pts/35
pane ID: %2   TTY: /dev/pts/36
pane ID: %3   TTY: /dev/pts/37
pane ID: %4   TTY: /dev/pts/38

Mas falho em fazê-los funcionar dentro de display-menu. O problema parece óbvio (pelo menos da minha perspectiva de shell): Um nível adicional de aspas é necessário para que list-panesveja a string de formato e não seu valor resolvido. Mas obviamente estou fazendo errado:

bind-key C-t display-menu -T 'Test' \
    'List panes with tty' '' "list-panes -a -F 'pane ID: \#\{p3:pane_id\}  TTY: \#{p11:pane_tty}"

bind-key C-t display-menu -T 'Test' \
    'List panes with tty' '' {
        list-panes -a -F 'pane ID: #{p3:pane_id}  TTY: #{p11:pane_tty}'
    }

Saída:

pane ID: %1   TTY: /dev/pts/35
pane ID: %1   TTY: /dev/pts/35
pane ID: %1   TTY: /dev/pts/35
pane ID: %1   TTY: /dev/pts/35
tmux
Martin Hope
Andrey Pro
Asked: 2025-03-09 05:52:39 +0800 CST
  • 7

Como posso descobrir desde qual versão do Linux uma função/macro da API do kernel está disponível ou sofreu alterações significativas (foi removida, houve alteração no tipo ou número de argumentos)?

Por exemplo, ao olhar a versão recente do , scatterlist.hme deparei com sg_alloc_table_from_pages_segment, que tem exatamente a funcionalidade necessária para meu módulo do kernel (driver). No entanto, a função, para minha decepção, ainda não está disponível na versão 5.10 para a qual o módulo do kernel foi desenvolvido, e terei que encontrar uma solução alternativa. Ainda assim, desejo oferecer suporte a futuras versões do kernel, caso realizemos uma atualização.

Normalmente, esses casos são tratados com cercas de pré-processador

#if LINUX_VERSION_CODE >= KERNEL_VERSION(...)
/*Version-specific implementation*/
#endif

Mas para aplicar esse padrão, preciso encontrar a versão do kernel na qual a função foi adicionada. Escanear manualmente todas as versões intermediárias do arquivo de cabeçalho seria uma tarefa de Sísifo.

linux-kernel
Martin Hope
Headbank
Asked: 2025-03-08 23:26:47 +0800 CST
  • 5

Tenho uma rede de máquinas Linux que são todas, para os propósitos do que estou fazendo, clones umas das outras. Há um nó "mestre" do qual todos os outros sincronizam um diretório em intervalos regulares usando rsync(revezando-se, não simultaneamente). Cada máquina tem seu rsyncdpróprio rsyncd.conf.

Minha rotina de sincronização faz com que cada nó cliente chame o rsynccliente assim:

$ rsync -a --delete masternode::syncdir/ /path/to/local/syncdir/

Observe que esta é uma conexão direta com o mestre rsyncd, não usando ssh.

Minha pergunta é: como já estou rsyncdexecutando em cada cliente, a operação de sincronização repetida seria mais eficiente invocando a instância local em vez de um caminho de arquivo como o argumento de destino? Ou seja

$ rsync -a --delete masternode::syncdir/ localhost::syncdir/

Nunca vi um exemplo de rsyncuso assim entre duas rsyncdinstâncias; não há nada que indique que não seja permitido/suportado, mas não tenho certeza de como (ou se) funcionaria nessa configuração de dois servidores mais um cliente mediando a operação entre eles.

Presumo que o tráfego ainda passe pelo processo do cliente (não que isso importe quando o servidor de destino é local), mas ambos os servidores " veem " um servidor na outra extremidade e fazem alguma eficiência de acordo, como aproveitar metadados de arquivo que eles podem ter armazenado em cache de execuções anteriores? (Ou isso acontece de qualquer maneira, independentemente de eles " saberem " que estão falando com outra instância do servidor?)

Esperando por uma resposta que possa aprofundar o " como ".

linux
Martin Hope
verified_tinker
Asked: 2025-03-08 14:22:44 +0800 CST
  • 8

Vi outras respostas neste site, li um artigo e assisti a um vídeo sobre o assunto, mas ainda não consigo conectar meu namespace de rede ao mundo externo.

Configurar

Criei um namespace chamado "foo" e um par de vethinterfaces e movi uma para o namespace.

ip netns add foo
ip link add veth-foo type veth peer name veth-out
ip link set dev veth-foo netns foo

Atribuí um endereço IP a cada interface e verifiquei se ambas estavam ativas.

ip -n foo addr add 192.168.15.1 dev veth-foo
ip addr add 192.168.15.2 dev veth-out
ip -n foo link set dev veth-foo up
ip link set dev veth-out up

# Just in case, I made sure the loopback interfaces, too, are up, though they still show "UNKNOWN".
ip link set dev lo up
ip -n foo link set dev lo up

Adicionei entradas às tabelas de roteamento dos namespaces global e "foo", para que eles possam se comunicar entre si.

ip route add 192.168.15.1 via 192.168.15.2
ip -n foo route add default via 192.168.15.1

Agora, posso alcançar "foo" do namespace global e o namespace global de "foo".

$ traceroute -n 192.168.15.1
traceroute to 192.168.15.1 (192.168.15.1), 30 hops max, 60 byte packets
 1  192.168.15.1  0.257 ms  0.209 ms  0.194 ms

$ ip netns exec foo traceroute -n 192.168.15.2
traceroute to 192.168.15.2 (192.168.15.2), 30 hops max, 60 byte packets
 1  192.168.15.2  0.046 ms  0.009 ms  0.008 ms

Também posso acessar a interface Ethernet que conecta a VM ao mundo externo de dentro de "foo".

# I ran this after I finished setting up IP forwarding, packet forwarding,
# and IP masquerading, so I'm not sure if it would work at this stage.
$ ip netns exec foo traceroute -n 10.0.2.15
traceroute to 10.0.2.15 (10.0.2.15), 30 hops max, 60 byte packets
 1  10.0.2.15  0.065 ms  0.010 ms  0.008 ms

Por fim, configurei o encaminhamento de IP, o encaminhamento de pacotes e o mascaramento de IP.

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -o enp1s0 -i veth-out -j ACCEPT
iptables -A FORWARD -i enp1s0 -o veth-out -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.15.1/24 -o enp1s0 -j MASQUERADE

Como resultado, meu sistema fica assim:

$ sysctl -a | grep ip_forward
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0

$ iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 102 packets, 6816 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  any    enp1s0  192.168.15.0/24      anywhere

$ 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 noprefixroute 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:c3:cd:ac brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute enp1s0
       valid_lft 83383sec preferred_lft 83383sec
    inet6 fec0::11b8:4b3b:59ba:bae4/64 scope site dynamic noprefixroute 
       valid_lft 86026sec preferred_lft 14026sec
    inet6 fe80::f3fd:90f2:d15f:d570/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: veth-out@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether da:a2:13:05:c4:f5 brd ff:ff:ff:ff:ff:ff link-netns foo
    inet 192.168.15.2/32 scope global veth-out
       valid_lft forever preferred_lft forever
    inet6 fe80::d8a2:13ff:fe05:c4f5/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

$ ip -n foo 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 proto kernel_lo 
       valid_lft forever preferred_lft forever
4: veth-foo@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 7e:84:e6:16:92:8e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.15.1/32 scope global veth-foo
       valid_lft forever preferred_lft forever
    inet6 fe80::7c84:e6ff:fe16:928e/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

$ ip route
default via 10.0.2.2 dev enp1s0 proto dhcp src 10.0.2.15 metric 100 
10.0.2.0/24 dev enp1s0 proto kernel scope link src 10.0.2.15 metric 100 
192.168.15.1 via 192.168.15.2 dev veth-out

$ ip -n foo route
default via 192.168.15.1 dev veth-foo

Testando

Neste ponto, espero conseguir alcançar o mundo exterior, mas não.

$ ip netns exec foo traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.15.1  3067.680 ms !H  3067.655 ms !H  3067.650 ms !H

$ sudo ip netns exec foo ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.15.1 icmp_seq=1 Destination Host Unreachable
From 192.168.15.1 icmp_seq=2 Destination Host Unreachable
From 192.168.15.1 icmp_seq=3 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2077ms

É claro que a própria VM está conectada à Internet.

$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.0.2.2  0.719 ms  0.691 ms  0.676 ms
 2  192.168.100.1  1.913 ms  2.593 ms  5.264 ms
 3  31.146.255.37  18.493 ms  18.740 ms  19.041 ms
 4  188.123.128.85  19.384 ms  19.658 ms  19.925 ms
 5  188.123.128.96  20.275 ms  21.787 ms 188.123.128.84  21.773 ms
 6  192.178.69.213  47.953 ms  53.145 ms  53.127 ms
 7  192.178.69.212  53.116 ms  51.893 ms 188.123.128.33  51.293 ms
 8  192.178.107.87  48.513 ms 192.178.107.135  43.582 ms 192.178.107.203  43.391 ms
 9  72.14.237.137  43.195 ms 8.8.8.8  43.207 ms  43.200 ms

$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=40.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=37.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=255 time=38.0 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 37.859/38.698/40.205/1.067 ms

Tcpdump

Aqui está a saída de tcpdump -n -i veth-out icmp. Ele capturou pacotes quando eu mirei 192.168.15.2& 10.0.2.15, mas não obteve nada quando eu mirei 8.8.8.8.

listening on veth-out, link-type EN10MB (Ethernet), snapshot length 262144 bytes

# This is the output when I ran `traceroute -n 192.168.15.2` (the address
# of "veth-out") in another terminal window (from inside "foo", of course).
12:44:19.172007 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port traceroute unreachable, length 68
12:44:19.172029 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port mtrace unreachable, length 68
12:44:19.172046 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33436 unreachable, length 68
12:44:19.172063 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33437 unreachable, length 68
12:44:19.172102 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33438 unreachable, length 68
12:44:19.172119 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33439 unreachable, length 68

# And this is when I ran the same command but addressed 10.0.2.15 (the
# ethernet interface to the outside world).
12:44:35.305689 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port traceroute unreachable, length 68
12:44:35.305715 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port mtrace unreachable, length 68
12:44:35.305733 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33436 unreachable, length 68
12:44:35.305750 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33437 unreachable, length 68
12:44:35.305766 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33438 unreachable, length 68
12:44:35.305783 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33439 unreachable, length 68
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

Nem capturou tcpdump -n -i lo icmpnenhum tcpdump -n -i enp1s0 icmppacote, independentemente do alvo de traceroute—sim, mesmo quando "foo" alcançou com sucesso a interface "enp1s0" (endereçada 10.0.2.15).

Informações do sistema

Isso foi feito dentro de uma VM (GNOME Boxes), no Fedora 41, versão do kernel 6.11.4-301.fc41.x86_64.

Minha máquina host também está executando o Fedora 41, embora o kernel esteja na versão 6.13.5-200.fc41.x86_64.

Edição: Só para garantir que isso fosse um problema do Fedora, testei em uma VM Mint e aconteceu exatamente a mesma coisa.

networking
Prev
Próximo