Perguntas[linux-networking](server)

Gostaria de saber se alguém tem dados para me dar suporte. Estou configurando um lote de mini PCs com placa RTL 8125 2.5 Gb/s e, de fábrica, parece estar funcionando bem usando o driver Ubuntu stock r8169.

No entanto, só consegui testá-lo com um switch de 1000 Mb/s, e pesquisas mostram que há problemas de estabilidade quando a velocidade negociada é, na verdade, 2,5.

Alguém tem experiência usando RTL 8125 em um switch de 2,5 Gb/s via r8169 (fornecido com o Ubuntu 22) e exemplos reais de problemas que podem ocorrer?

Entre os servidores, windows-in-Finland <-> linux-in-Germanyestou enfrentando um upload 100x mais lento que o download ( windows -> linuxé 100x mais lento que windows <- linux).

Detalhes e pesquisas existentes

Inicialmente, observei esse problema com clientes Windows em todo o mundo e percebi que também posso reproduzi-lo em ambientes de data center controlados.

Para reproduzir o problema, estou usando o provedor de datacenter Hetzner, com a Windowsmáquina na Finlândia (servidor dedicado, Windows Server 2019), fazendo upload para ambos:

• Linux Hetzner dedicado Alemanha: lento
• Linux Hetzner Cloud VM Alemanha: rápido

Ambos estão no mesmo parque de datacenter e, portanto, ambos têm 37 ms pingda máquina Windows. Enquanto a conexão entre a Finlândia e a Alemanha geralmente está na rede privada da Hetzner, ela está atualmente sendo redirecionada por meio de rotas públicas de Internet devido à interrupção do cabo submarino C-LION1 2024 do Mar Báltico ( mensagem de status da Hetzner sobre isso ), então a conexão "simula" o uso de rotas e peerings normais de Internet pública.

Estou medindo com iperf3, windows <- linux:

C:\Users\Administrator\Downloads\iperf3.17.1_64\iperf3.17.1_64>iperf3.exe -c linux-germany-dedicated.examle.com

Connecting to host linux-germany-dedicated.examle.com, port 5201
[  5] local 192.0.2.1 port 62234 connected to 192.0.2.2 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  15.8 MBytes   132 Mbits/sec
[  5]   1.00-2.00   sec  1.88 MBytes  15.7 Mbits/sec
[  5]   2.00-3.00   sec  1.38 MBytes  11.5 Mbits/sec
[  5]   3.00-4.00   sec  1.75 MBytes  14.7 Mbits/sec
[  5]   4.00-5.00   sec  2.25 MBytes  18.9 Mbits/sec
[  5]   5.00-6.00   sec  2.88 MBytes  24.1 Mbits/sec
[  5]   6.00-7.00   sec  3.25 MBytes  27.3 Mbits/sec
[  5]   7.00-8.00   sec  3.38 MBytes  28.3 Mbits/sec
[  5]   8.00-9.00   sec  2.75 MBytes  23.1 Mbits/sec
[  5]   9.00-10.00  sec  1.25 MBytes  10.5 Mbits/sec

Mais iperf3observações:

• A outra direção (adicionando -R) iperf3é muito mais rápida, a ~900 Mbit/s. (Observe que os lados do Linux estão usando o controle de congestionamento BBR, o que provavelmente ajuda nessa direção.)
• Ao fazer download com 30 conexões ( iperf3com -P 30), a conexão de 1 Gbit/s é atingida no máximo, sugerindo que o problema é a taxa de transferência de upload de uma única conexão de upload TCP .
• Ao substituir a máquina Windows por uma Linux na Finlândia, ambas as direções atingem o máximo de 1 Gbit/s de conexão. Isso me leva a concluir que o envolvimento do Windows é a falha .
• Observe que há um artigo da Microsoft alegando que iperf3é o melhor para medições de alto desempenho no Windows. Isso não é relevante para esta questão porque se aplica apenas a conexões >= ~10 Gbit/s, e o fato de que iperf3 em várias máquinas Windows/Linux no mesmo datacenter prova que a velocidade de 1 Gbit/s é facilmente atingível iperf3em ambas as direções.

Em 2021, o Dropbox lançou um artigo Aumentando a velocidade de upload do Dropbox e melhorando a pilha TCP do Windows , que aponta o tratamento incorreto (incompleto) do Windows de retransmissões TCP; a Microsoft publicou Melhorias algorítmicas aumentam o desempenho do TCP na Internet junto com isso.

Isso parece explicar em grande parte, e o Wireguard lento, mas apenas para upload do Windows, mostra uma solução potencial, ou seja, alterar o número de filas RSS ( Receive Side Scaling ) para 1:

ethtool -L eth0 combined 1

Isso muda de 16(16 threads no meu servidor Linux dedicado) para 1 e aumenta a velocidade de upload do iperf3 convergente de 10.5para 330Mbit/s .

Isso é bom, mas deveria ser 1000 Mbit/s.

Especialmente estranho: Ao testar windows -> linux-Hetzner-Cloudem vez de windows -> Hetzner-dedicated, observo velocidades de upload perfeitas:

C:\Users\Administrator\Downloads\iperf3.17.1_64\iperf3.17.1_64>iperf3.exe -c linux-germany-hcloud.example.com

Connecting to host linux-germany-hcloud.example.com, port 5201
[  5] local 192.0.2.1 port 55615 connected to 192.0.2.3 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   108 MBytes   903 Mbits/sec
[  5]   1.00-2.00   sec   112 MBytes   942 Mbits/sec
...
[  5]   9.00-10.00  sec   112 MBytes   942 Mbits/sec

Isso é estranho, porque a máquina de nuvem tem especificações muito mais baixas. Ela tem 8 núcleos virtuais, mas sua ethtool -lsaída já é padrão Combined: 1porque, sendo uma VM, ela não suporta RSS de forma alguma:

root@linux-germany-hcloud ~ # ethtool -x enp1s0

RX flow hash indirection table for enp1s0 with 1 RX ring(s):
Operation not supported
RSS hash key:
Operation not supported
RSS hash function:
    toeplitz: on
    xor: off
    crc32: off

Então, de alguma forma, a máquina mais fraca não tem o problema. Talvez haja alguma coisa inteligente de hardware NIC acontecendo na máquina dedicada que cria o problema? O que poderia ser?

Eu já tentei desabilitar o TCP Segment Offloading ( ethtool -K eth0 tso off), mas isso não afeta os resultados. O recurso que causou o problema no artigo do Dropbox ( flow-director-atr) não está disponível na minha NIC, então não pode ser isso.

Pergunta

O que pode explicar o gargalo adicional de 3x no upload entre os dois servidores Linux?

Como posso obter uploads rápidos apenas do Windows?

Mais informações sobre o meio ambiente

• Ambas as máquinas Linux usam a mesma versão Linux 6.6.33 x86_64e os mesmos sysctls (garantidos via NixOS), que são:

  net.core.default_qdisc=fq
  net.core.rmem_max=1073741824
  net.core.wmem_max=1073741824
  net.ipv4.conf.all.forwarding=0
  net.ipv4.conf.net0.proxy_arp=0
  net.ipv4.ping_group_range=0 2147483647
  net.ipv4.tcp_congestion_control=bbr
  net.ipv4.tcp_rmem=4096 87380 1073741824
  net.ipv4.tcp_wmem=4096 87380 1073741824
  

• Servidor Windows 2019Version 1809 (OS Build 17763.6293)

Editar 1

Descobri que consigo upload de 950 Mbit/s do Windows para outras máquinas dedicadas da Hetzner. As máquinas dedicadas para as quais o upload é lento têm em comum o fato de terem placas de rede Intel de 10 Gbit/s; de lspci:

01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

lsmod | grep ixgbesugere que o ixgbedriver seja usado aqui. ixgbetambém é mencionado no artigo do Dropbox acima . O artigo "Por que o Flow Director causa reordenação de pacotes?" que eles vinculam menciona Intel 82599especificamente. Também encontrei este tópico e1000-devel onde alguém menciona o problema em 2011, mas nenhuma solução é apresentada.

Ao usar o cartão de 1 Gbit Intel Corporation I210 Gigabit Network Connection (rev 03)presente no mesmo modelo de servidor, o problema desaparece e obtenho 950 Mbit/s.

Então parece haver algo específico sobre 82599ES/ ixgbeque causa o problema.

Edição 2: Intel Flow Directore tentar fora da árvoreixgbe

Uma pesquisa no Google intel disable flowdirectorproduz https://access.redhat.com/solutions/528603 mencionando Intel 82599.

Ajuda:

O Intel Flow Director é um recurso de driver e NIC da Intel que fornece direção inteligente e programável de tráfego de rede semelhante (ou seja, um "fluxo") para filas de recebimento específicas.

Por padrão, o Flow Director opera no modo ATR (Application Targeted Receive). Isso executa hash regular no estilo RSS quando tráfego não visto anteriormente é recebido. No entanto, quando o tráfego é transmitido, a tupla (ou "fluxo") desse tráfego é inserida na tabela de hash de recebimento. O tráfego futuro recebido na mesma tupla será recebido no núcleo que o transmitiu. O processo de envio e recebimento pode então ser fixado no mesmo núcleo que a fila de recebimento para melhor afinidade de cache da CPU.

Observe que a pesquisa da comunidade mostrou que o ATR pode causar tráfego TCP Out-of-Order quando processos são migrados entre CPUs . É melhor fixar explicitamente processos em CPUs ao usar o modo ATR.

O FlowDirector é mencionado no artigo do Dropbox, assim como o ATR.

A "pesquisa comunitária" mencionada é o mesmo artigo "Por que o Flow Director causa reordenação de pacotes?" ao qual o Dropbox se refere.

Fazendo o sugerido

ethtool -K net0 ntuple on

melhora a velocidade de 20 Mbit/s para 130 Mbit/s (com o padrão ethtool -L net0 combined 16). Executá-lo por mais tempo ( iperf3 --time 30) faz com que ele caia para 80 Mbit/s após 16 segundos. Usar ntuple onjunto com combined 16não melhora mais.

Portanto, esta não é uma solução completa.

Testando a options ixgbe FdirMode=0abordagem em seguida.

Sobre ram256g-1:

rmmod ixgbe; modprobe ixgbe FdirMode=0; sleep 2; ifconfig net0 94.130.221.7/26 ; ip route add 192.0.2.2 dev net0 proto static scope link ; ip route add default via 192.0.2.2 dev net0 proto static ; echo done

dmesgmostra

ixgbe: unknown parameter 'FdirMode' ignored

Isso apesar de https://www.kernel.org/doc/Documentation/networking/ixgbe.txt documentá-lo:

FdirMode
--------
Valid Range: 0-2 (0=off, 1=ATR, 2=Perfect filter mode)
Default Value: 1

  Flow Director filtering modes.

Então 0=offparece ainda mais desejável que os outros dois, que supostamente são os que ntuple on/offalternam entre eles.

https://access.redhat.com/solutions/330503 diz

A Intel optou por expor algumas configurações como um parâmetro de módulo em seu driver SourceForge, no entanto, o kernel Linux upstream tem uma política de não expor um recurso como uma opção de módulo quando ele pode ser configurado de maneiras já disponíveis, então você só verá alguns parâmetros de módulo em drivers Intel fora da árvore do kernel Linux upstream.

A Red Hat segue os métodos do kernel upstream, então essas opções não estarão na versão RHEL do driver, mas a mesma coisa pode ser feita com ethtool(e sem) uma recarga de módulo.

Isso sugere que isso 0=offnão é realmente possível.

Ou talvez funcione com modprobe.dopções, mas não com o modprobecomando?

Código relevante:

• Kernel antigo com a FdirModeopção:
  • https://github.com/spotify/linux/blob/6eb782fc88d11b9f40f3d1d714531f22c57b39f9/drivers/net/ixgbe/ixgbe_param.c#L285C24-L285C37
  • https://github.com/spotify/linux/blob/6eb782fc88d11b9f40f3d1d714531f22c57b39f9/drivers/net/ixgbe/ixgbe_param.c#L1034-L1040
• Novo kernel sem:
  • https://github.com/torvalds/linux/blob/b86545e02e8c22fb89218f29d381fa8e8b91d815/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c#L648
    • Sugere que o Flow Director só seja habilitado se o comprimento da fila RSS for> 1
    • Então provavelmente definir o comprimento da fila como 1 com ethtool -L(que é --set-channels) já deve resolver isso.

Mas parece que https://github.com/intel/ethernet-linux-ixgbe ainda está sendo desenvolvido ativamente e suporta todas as opções antigas. Também suporta FdirPballoco que nunca existiu em torvalds/linux. Isso é descrito em: https://forum.proxmox.com/threads/pve-kernel-4-10-17-1-wrong-ixgbe-driver.35868/#post-175787 Também relacionado: https://www.phoronix.com/news/Intel-IGB-IXGBE-Firmware-Update Talvez eu deva tentar construir e carregar isso?

Desse driver, FDirModetambém foi removido:

• https://github.com/intel/ethernet-linux-ixgbe/commit/a9a37a529704c584838169b4cc1f877a38442d36
• https://github.com/intel/ethernet-linux-ixgbe/commit/a72af2b2247c8f6bb599d30e1763ff88a1a0a57a

De https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20160919/006629.html :

ethtool -K ethX ntuple on

Isso habilitará o modo "filtro perfeito", mas ainda não há filtros, então os pacotes recebidos retornarão ao RSS.

Testado

ethtool -K net0 ntuple on
ethtool --config-ntuple net0 flow-type tcp4 src-ip 192.0.2.1 action 1

Não melhorou a velocidade.

Também descobri que a velocidade no Linux 6.3.1parece ser de 90 Mbit/s, enquanto no 6.11.3.

Compilando o out-of-tree ethernet-linux-ixgbeno Hetzner Rescue System Linux (old)que tem 6.3.1(ainda não há lançamento para Linux 6.11):

wget https://github.com/intel/ethernet-linux-ixgbe/releases/download/v5.21.5/ixgbe-5.21.5.tar.gz
tar xaf *.tar.gz
cd ixgbe-*/src && make -j

# because disconnecting the ethernet below will hang all commands
# from the Rescue Mode's NFS mount if not already loaded into RAM
ethtool --help
timeout 1 iperf3 -s
dmesg | grep -i fdir

modinfo /root/ixgbe-*/src/ixgbe.ko  # shows all desired options

rmmod ixgbe; insmod /root/ixgbe-*/src/ixgbe.ko; sleep 2; ifconfig eth1 94.130.221.7/26 ; ip route add 192.0.2.2 dev eth1 scope link ; ip route add default via 192.0.2.2 dev eth1 ; echo done

iperf3 -s

Este driver fornece 450 Mbit/s mais sólidos imediatamente.

rmmod ixgbe; insmod /root/ixgbe-*/src/ixgbe.ko FdirPballoc=3; sleep 2; ifconfig eth1 94.130.221.7/26 ; ip route add 192.0.2.2 dev eth1 scope link ; ip route add default via 192.0.2.2 dev eth1 ; echo done

dmesg | grep -i fdir

iperf3 -s

Não traz nenhuma melhoria.

Experimente também:

AtrSampleRate

Um valor de 0 indica que o ATR deve ser desabilitado e nenhuma amostra será coletada.

rmmod ixgbe; insmod /root/ixgbe-*/src/ixgbe.ko AtrSampleRate=0; sleep 2; ifconfig eth1 94.130.221.7/26 ; ip route add 192.0.2.2 dev eth1 scope link ; ip route add default via 192.0.2.2 dev eth1 ; echo done

dmesg | grep -i atrsample

iperf3 -s

Não traz nenhuma melhoria.

ethtool -L net0 combined 1aqui também não traz nenhuma melhoria, e

ethtool -K eth1 ntuple on
ethtool -L eth1 combined 12  # needed, otherwise the out-of-tree ixgbe driver complains with `rmgr: Cannot insert RX class rule: Invalid argument` when `combined 1` is set
ethtool --config-ntuple eth1 flow-type tcp4 src-ip 192.0.2.1 action 1

também não traz nenhuma melhoria.

Edição 3: NIC alterado

Alterei a NIC do servidor Linux de Intel 82599ES para Intel X710, que usa o i40edriver Linux.

O problema persistiu.

Suspeito que seja porque o X710 também suporta o Intel Flow Director.

A mitigação parcial ethtool -L eth0 combined 1tem o mesmo efeito que para o 82599ES.

O comando

ethtool --set-priv-flags eth0 flow-director-atr off

(o que é possível i40e, mas não ixgbe) mencionado pelo Dropbox como solução alternativa só alcançou a mesma aceleração que ethtool -L eth0 combined 1(em torno de 400 Mbit/s).

Curiosamente, Hetzner relatou que as máquinas Hetzner Cloud também são equipadas com Intel X710 , mas não apresentam o problema.

Recebi 4 endereços IP estáticos do meu ISP em um plano de negócios que devem ser usados ​​em um roteador com Linux e configurados por meio do ipcomando. Meu ISP anterior me deu 4/32 endereços IP que simplesmente exigiam serem adicionados à interface WAN e funcionariam independentemente um do outro; no entanto, meu novo ISP me deu um bloco /30 "roteado" de 4 endereços IP.

Não consegui descobrir como adicionar esses endereços IP quando recebo error: nexthop has invalid gatewayou os endereços IP são adicionados, mas não consigo resolver nenhum endereço IP externo ou host de destino.

A configuração de rede do meu novo ISP é a seguinte:

• WAN: 1.1.1.2/30
• Portal: 1.1.1.1/30
• Roteado: 1.1.1.4/30

Meu ISP afirma que o endereço do gateway pode não ser necessário e usar o endereço WAN como upstream. Meu roteador possui 2 NICs; 1 para LAN e 1 para WAN. Também estou usando iptablespara configurar o firewall.

Como esta configuração é configurada corretamente em um sistema Linux por meio do ipcomando?

Quero que uma determinada placa de rede se comporte como se fosse uma placa de rede mais lenta. Como se a interface 1G do meu laptop fosse na verdade uma interface de 100M ou 10M. Uma maneira de fazer isso é desenterrar meu antigo hub de 10 bits e usá-lo para essa finalidade.

Tenho certeza de que existe uma "solução de software" para isso. E, de fato, parece que o tccomando e o tbfrecurso são capazes de fazer isso.

Infelizmente, não compreendo totalmente o conceito para alcançar o que escrevi acima. Parece que há alguma matemática envolvida para levar em consideração a velocidade do link assumida /sys/class/net/*/speed, provavelmente o MTU de /sys/class/net/*/mtue a taxa de tick do sistema. Não tenho certeza se o último ainda é necessário atualmente com os kernels de distribuição "atuais" (eu tenho CONFIG_NO_HZ=ye CONFIG_HZ_300=ypor exemplo).

Como seria um script de shell para tornar esse recurso mais genérico? Comobash link-bandhwidth.sh <interface> 10m|100m|1G|2.5G|10G

Editar:

Conforme sugerido por @vidarlo, alterar a velocidade do link realmente funciona. Consegui alterar a lista de velocidades anunciadas para portas individuais no switch. Tive resultados mistos com o uso do ethtool, mesmo em placas mlx5 que ofereciam várias velocidades diferentes.

Eu também tenho uma placa mlx4 que suporta apenas uma velocidade. Aqui tentei o nccomando sugerido, mas incompleto. Daí a questão de como gerar programaticamente os valores ideais. Esta parte permanece sem resposta, até agora. Para mim, um comando como este funcionou em um link 10G de velocidade fixa:

tc qdisc add dev $interface root tbf rate 2000mbit latency 1ms burst 2000mbit

Isso se comporta como uma placa 2G hipotética, mas provavelmente os valores de latência e burst têm espaço para melhorias. Também tentei 1000mbite 100mbitcom os resultados esperados.

Sou novo no conceito de construção de seu servidor e estava lendo sobre hipervisores. Aprendi que o KVM é um hipervisor tipo 1 e pode ser instalado diretamente no servidor sem sistema operacional. Mas o que me confundiu é que para instalar o módulo KVM você precisa do kernel Linux. Então, como você cria uma unidade inicializável com hipervisor e KVM instalados e sem necessidade de instalar uma distribuição Linux primeiro. Não foi possível encontrar nenhum artigo que explique esse conceito ou talvez meu entendimento não esteja correto.

Eu tenho um manual do Ansible que uso para configurar novas VMs Linux. Recentemente, estava construindo uma nova VM com Ubuntu 22.04. O manual escreverá alguns arquivos de configuração relacionados à rede e outros enfeites, e então a etapa final do processo é usar o Ansibles ansible.builtin.packagepara instalar todas as atualizações de pacotes.

- name: "Install updates"
  become: true
  ansible.builtin.package:
    upgrade: "dist"
  register: res_pkg_updates
  notify: "reboot system"
  tags: [ never, updates ]

Minha VM foi criada a partir de um modelo que fiz há alguns meses, então o sistema operacional Ubuntu tinha alguns pacotes desatualizados, o que não é inesperado. O problema é que um dos pacotes deve suportar ou fornecer funcionalidade de rede. Portanto, quando os packagemódulos iniciam a VM no caminho de instalação das atualizações, o daemon de rede é reiniciado e a VM obtém o novo IP que foi configurado anteriormente em meu manual. Isso faz com que a tarefa do Ansible seja interrompida, aguardando uma reconexão com uma máquina que agora está em um IP diferente.

Quero saber como configurar minha ansible.builtin.packagetarefa para instalar atualizações de pacotes, mas não reiniciar nenhum serviço, especialmente rede.

Estou tentando inicializar um túnel IPsec entre uma VM Ubuntu no Google Cloud e um site remoto.

A conexão foi estabelecida corretamente, mas na máquina Ubuntu no Google Cloud não consigo acessar um host na rede remota (172.17.20.25).

Gcloud:

IP público: 50.50.50.50

IP privado: 10.132.0.63/32

Local remoto:

IP público: 100.100.100.100

Rede privada remota: 172.17.20.0/16

ipsec.conf

config setup
        charondebug="all"
        uniqueids=yes
conn intacloud-to-tper
        type=tunnel
        auto=start
        keyexchange=ikev2
        authby=secret
        leftid=50.50.50.50
        leftsubnet=10.132.0.62/32
        right=100.100.100.100
        rightsubnet=172.17.20.0/16 
        ike=aes-sha1-modp2048
        esp=aes-sha1
        aggressive=no
        keyingtries=%forever
        ikelifetime=28800s
        lifetime=3600s
        dpddelay=30s
        dpdtimeout=120s
        dpdaction=restart

tabela de exibição de rota ip 220

172.17.0.0/16 via 10.132.0.1 dev ens4 proto static src 10.132.0.62

status ipsec tudo

    Status of IKE charon daemon (strongSwan 5.9.5, Linux 6.2.0-1019-gcp, x86_64):
  uptime: 2 hours, since Jan 24 17:36:07 2024
  malloc: sbrk 3100672, mmap 0, used 1403424, free 1697248
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  10.132.0.62
Connections:
site-to-site:  %any...100.100.100.100  IKEv2, dpddelay=30s
site-to-site:   local:  [50.50.50.50] uses pre-shared key authentication
site-to-site:   remote: [100.100.100.100] uses pre-shared key authentication
site-to-site:   child:  10.132.0.62/32 === 172.17.0.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
site-to-site[1]: ESTABLISHED 2 hours ago, 10.132.0.62[50.50.50.50]...100.100.100.100[100.100.100.100]
site-to-site[1]: IKEv2 SPIs: -, pre-shared key reauthentication in 5 hours
site-to-site[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
site-to-site{4}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cb5b6fdd_i 932ca574_o
site-to-site{4}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 27 minutes
site-to-site{4}:   10.132.0.62/32 === 172.17.0.0/16

política ip xfrm

src 10.132.0.63/32 dst 172.17.0.0/16 
    dir out priority 375423 ptype main 
    tmpl src 10.132.0.63 dst 100.100.100.100
        proto esp spi 0xbb44a532 reqid 1 mode tunnel
src 172.17.0.0/16 dst 10.132.0.63/32 
    dir fwd priority 375423 ptype main 
    tmpl src 100.100.100.100 dst 10.132.0.63
        proto esp reqid 1 mode tunnel

Não consigo entender se pode haver um problema de configuração ou se o problema pode estar na configuração do site remoto

Estou tentando aprender a configurar o Wireguard corretamente (não apenas copiando e colando). Encontrei esta linha na página de início rápido :

ip address add dev wg0 192.168.2.1/24

Lendo a página de manual do ip, parece que address addatribui o endereço fornecido ao dispositivo fornecido. Isso faz sentido, exceto que o endereço de exemplo inclui uma máscara CIDR. Estou lutando para entender o que isso significa e meu google-fu está falhando.

Estamos dizendo que queremos que o endereço seja 192.168.2.0, ou... nem sei. O que mais isso poderia significar?

EDIT: Espere, acabei de perceber que esta poderia ser uma forma de especificar a sub-rede. Talvez isso seja óbvio para o pessoal do Linux, mas eu sou um cara do Windows e na GUI do Windows você especifica a máscara de sub-rede separadamente para o IP. Vou deixar essa pergunta aqui caso eu esteja errado.

Estou executando dnsmasqinstalado como um NetworkManagerplugin na minha máquina Fedora 39 local. Tudo que preciso dnsmasqé basicamente suporte para hostsarquivos adicionais que posso organizar por tópicos.

Minhas configurações são:

1. /etc/dnsmasql.conf:

user=dnsmasq
group=dnsmasq
interface=lo
bind-interfaces
conf-dir=/etc/NetworkManager/dnsmasq.d,*.conf
conf-dir=/etc/dnsmasq.d,.rpmnew,.rpmsave,.rpmorig

2. /etc/NetworkManager/conf.d/00-use-dnsmasq.conf

[main]
dns=dnsmasq

3. /etc/NetworkManager/dnsmasq.d/00-add-hosts.conf

log-queries
no-hosts
addn-hosts=/etc/hosts.d
address=/development/127.0.0.1

4. /etc/hosts.dé um diretório com os arquivos hosts que contêm entradas que desejo "sinkhole":

0.0.0.0 1.example.com
0.0.0.0 2.example.com
...

dnsmasqestá instalado e funcionando, vejo o daemon em meus processos:

ps aux | grep dnsmasq

dnsmasq    61161  0.4  0.0 228096  4480 ?        S    16:08   0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/NetworkManager/dnsmasq.pid --listen-address=127.0.0.1 --cache-size=400 --clear-on-reload --conf-file=/dev/null --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d

Também vejo nos dnsmasqlogs de depuração que os arquivos dos hosts /etc/hosts.dtambém são lidos:

Dec 30 16:18:40 fedora dnsmasq[61823]: chown of PID file /run/NetworkManager/dnsmasq.pid failed: Operation not permitted
Dec 30 16:18:40 fedora dnsmasq[61823]: DBus support enabled: connected to system bus
Dec 30 16:18:40 fedora dnsmasq[61823]: warning: no upstream servers configured
Dec 30 16:18:40 fedora dnsmasq[61823]: read /etc/hosts.d/private - 10 names
Dec 30 16:18:40 fedora dnsmasq[61823]: setting upstream servers from DBus
Dec 30 16:18:40 fedora dnsmasq[61823]: using nameserver 192.168.0.1#53(via wlp2s0)

Mas quando tento acessar domínios dos addn-hostsarquivos hosts, eles não são resolvidos 0.0.0.0como eu esperava. Esses arquivos hosts parecem ser ignorados.

Por outro lado, tudo o que eu adiciono ao sistema /etc/hostsfunciona conforme o esperado. Mesmo que eu tenha usado no-hostsopções explicitamente na dnsmasqconfiguração e vejo que elas foram adicionadas à invocação do daemon.

Também vejo que dnsmasqconfig é usado, porque a address=/development/127.0.0.1linha funciona conforme o esperado:

$ ping -c 3 anything.development
PING anything.development (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.175 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.200 ms

É addn-hostsque isso é ignorado de alguma forma.

Aqui está o meu /etc/resolv.conf:

# Generated by NetworkManager
nameserver 127.0.0.1
options edns0 trust-ad

Anteriormente eu pensava que era isso systemd-resolved.serviceque estava atrapalhando (pois anteriormente adicionou 127.0.0.53 ao meu resolv.conf arquivo), mas agora que desabilitei o serviço:

systemctl status systemd-resolved.service
○ systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)

Não tenho certeza do que há de errado com minhas configurações.

Estou tentando baixar um arquivo de um servidor FTP (uma versão do depurador do Insight, da web oficial ( https://sourceware.org/insight/downloads.php )). O URL do FTP é: ftp://sourceware.org/pub/insight/releases

Se eu clicar nele no navegador do meu linux (ou no meu Mac), ele apenas pede permissão para abrir o Dolphin ou o Finder e após escolher "convidado", mostra o conteúdo como se fosse uma pasta local normal no meu computador.

Acontece que quero fazer isso na linha de comando, usando o ftpcomando. Quando tento, isso acontece:

$ ftp ftp://sourceware.org/pub/insight/releases
Connected to sourceware.org.
220 Welcome to sourceware FTP service.
331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Switching to Binary mode.
250 Directory successfully changed.
250 Directory successfully changed.
local: releases remote: releases
229 Entering Extended Passive Mode (|||36594|)
550 Failed to open file.
221 Goodbye.
                                                                              
$