Doug Smythies提出的问题 -ubuntu

Doug Smythies

Asked: 2021-04-24 08:40:05 +0800 CST

Rede em ponte em pacotes endereçados por LAN KVM/Qemu descartados

3

Resumo: Em uma configuração KVM/QEMU com ponte, os pacotes de rede destinados à VM convidada não chegam lá.

Configuração: O host é um servidor Ubuntu 20.04.2 LTS atualizado; O convidado é qualquer uma das 3 VMs, um servidor Ubuntu 16.04 muito antigo, um desktop Ubuntu 20.04 antigo e um desktop Ubuntu 21.04 novinho em folha. As primeiras 2 VMs estão sendo convertidas de não em ponte, NAT'd, e a 3ª foi criada especificando a rede em ponte. Em última análise, as VMs obterão seus endereços IP da LAN principal, via DHCP, mas por enquanto e para obter melhores informações de depuração, elas estão usando endereços IP estáticos.

A definição da ponte do host, /etc/netplan/01-netcfg.yaml, (esta é uma das muitas tentativas):

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: no
  bridges:
    br0:
#      interfaces: [ enp3s0 ]
      dhcp4: yes
#      dhcp6: no
#      link-local: [ ]
      interfaces:
        - enp3s0
#      parameters:
#        stp: true
#        forward-delay: 4

O material virtual, /etc/libvirt/qemu/networks/br0.xml:

<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit br0
or other application using the libvirt API.
-->

<network>
  <name>br0</name>
  <uuid>40a8752c-d074-4802-bae8-b0aef95d9c99</uuid>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

Notas: muitas versões de arquivos .xml de ponte foram testadas, incluindo nomes diferentes, e referências diferentes usam técnicas diferentes. O Ubuntu Serverguide faz referência a isso , que diz que o nome e o nome da ponte devem ser os mesmos, mas outras referências não os possuem. Uma vez que o arquivo bare foi criado com nano, estes comandos:

virsh net-define br0.xml
virsh net-autostart br0
virsh net-start br0

foram usados para adicioná-lo e configurá-lo. A maneira padrão, NAT'd, foi desvinculada, do diretório de inicialização automática, para não ser. Eventualmente, foi indefinido. O resultado:

$ virsh net-list --all
 Name      State      Autostart   Persistent
----------------------------------------------
 br0       active     yes         yes

Neste ponto, não há nenhuma regra do iptables após a reinicialização. No entanto, as VMs não têm acesso à rede. Observe que algumas referências mencionam regras especiais do iptables e atributos especiais para o módulo br_netfilter, todos os quais foram testados. Esta questão já é longa o suficiente sem entrar em todos os detalhes das variações tentadas aqui.

Detalhes de depuração: Não importa a variante de configuração, o problema básico é sempre o mesmo, os pacotes destinados à VM parecem não chegar ao host, pelo menos como visto pelo tcpdump. No entanto, os pacotes do tipo broadcast chegam e chegam à VM cliente.

Este exemplo usará 192.168.111.59 (MAC: 52:54:00:60:ea:0e), a VM do servidor 16.04 e 192.168.111.132, um raspberry-pi, na LAN. O servidor host 20.04 está em 192.168.111.136. A máscara de rede é de 24 bits, 255.255.255.0. O gateway e servidor DHCP é um servidor Debian (no qual VMs convidadas em ponte funcionam bem, a propósito).

Primeiro tpcudmp visto do raspberry-pi durante o ping:

doug@rpi2:~ $ sudo tcpdump -n -tttt -i eth0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 08:33:19.363553 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:19.487239 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 14, length 64
2021-04-23 08:33:20.363542 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:20.527250 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 15, length 64
2021-04-23 08:33:21.567215 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 16, length 64
2021-04-23 08:33:22.607228 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 17, length 64
2021-04-23 08:33:23.372351 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:23.647228 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 18, length 64
2021-04-23 08:33:24.371431 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46

Observe que a VM está enviando pacotes muito bem, conforme visto em toda a atividade ARP. No entanto, nunca responde a nada. Agora vamos observar a mesma atividade do host, observando que a saída do tcpdump é a mesma para qualquer uma das interfaces br0 ou enp3s0 ou vnet0.

$ sudo tcpdump -n -tttt -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 08:40:38.837608 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:39.837159 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:40.837122 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:43.842985 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:44.840895 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:45.840991 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:48.848508 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:49.848895 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:50.848871 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:51.514011 ARP, Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 08:40:52.928400 ARP, Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 08:40:53.853881 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:54.852472 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28

Observe que de vez em quando a VM responde, mas mais tarde veremos que é para um pacote de broadcast. Também parece que um problema é que 192.168.111.1 não está respondendo. É, e por qualquer motivo, que os pacotes não são vistos aqui no nível tcpdump. Observe também nenhum pacote ICMP do raspberry-pi. Agora, mostre o gateway respondendo (este é "br0" em um computador diferente. EDIT: substituído por um exemplo de captura melhor, daí os diferentes timestamps):

$ sudo tcpdump -n -tttt -e -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
2021-04-23 22:25:17.434415 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:17.434432 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:20.440843 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:20.440859 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:21.438316 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:21.438332 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:22.438266 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:22.438283 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:25.446312 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:25.446329 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:26.446195 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:26.446211 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28

Observe os pacotes de saída da VM e o ARP é concluído. Não consigo descobrir como copiar e colar da VM, com a qual me comunico via VNC, mas mostra algumas entradas ARP concluídas, mas obsoletas em resposta ao ip neighcomando e o tcpdump mostra alguns pacotes ARP e broadcast da LAN.

Outras informações (MACs não relevantes para esta pergunta foram ocultados):

$ brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.3c7c3f0d9983       no              enp3s0
                                                        vnet0
$ brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     xx:xx:xx:xx:xx:xx       no                 0.00
  1     3c:7c:3f:0d:99:83       yes                0.00
  1     3c:7c:3f:0d:99:83       yes                0.00
  2     52:54:00:60:ea:0e       no                 1.68
  1     xx:xx:xx:xx:xx:xx       no                 2.14
  1     xx:xx:xx:xx:xx:xx       no                36.84
  1     xx:xx:xx:xx:xx:xx       no                89.57
  1     xx:xx:xx:xx:xx:xx       no               226.51
  1     xx:xx:xx:xx:xx:xx       no                13.28
  1     xx:xx:xx:xx:xx:xx       no               165.68
  1     xx:xx:xx:xx:xx:xx       no               165.68
  1     xx:xx:xx:xx:xx:xx       no               265.02
  1     xx:xx:xx:xx:xx:xx       no                27.62
  2     fe:54:00:60:ea:0e       yes                0.00
  2     fe:54:00:60:ea:0e       yes                0.00

$ 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
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 3c:7c:3f:0d:99:83 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:7c:3f:0d:99:83 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.136/24 brd 192.168.111.255 scope global dynamic br0
       valid_lft 51547sec preferred_lft 51547sec
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:60:ea:0e brd ff:ff:ff:ff:ff:ff

EDIT: curiosamente, todos os pacotes ARP do meu Roteador Gigabit Wi-Fi D-Link AC2600, configurado como um switch, sempre aparecem no host e chegam à VM e são respondidos:

$ sudo tcpdump -n -tttt -e -i br0 ether host aa:aa:aa:aa:aa:aa
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 22:45:51.463524 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:45:51.463631 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:46:51.466955 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:46:51.467030 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:47:51.466889 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:47:51.466965 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:48:51.479096 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:48:51.479178 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28

EDIT 3 - Novo teste de configuração: Na tentativa de reduzir o número de variáveis foi feito o seguinte:

Um servidor Ubuntu 16.04 prestes a ser aposentado foi ligado, fornecendo uma nova LAN isolada.
o servidor host Ubuntu 20.04 foi conectado diretamente à NIC do lado da LAN do servidor 16.04. Nenhum switch estava envolvido, apenas um longo cabo Ethernet.
As coisas foram testadas e pareciam funcionar bem. O acesso a tudo era via ssh da minha LAN principal através do meu IP estático principal da WAN e de volta através do meu IP estático da WAN de teste para o antigo servidor 16.04. Em seguida, uma sessão ssh encadeada de lá para o servidor host 20.04.
O cliente VM Ubuntu 16.04 foi iniciado no host.
"ping" foi tentado do antigo servidor de gateway 16.04 para o cliente.
Os resultados foram os mesmos da configuração original.

tcpdump no servidor 16.04 antigo do gateway:

doug@DOUG-64:~$ sudo tcpdump -n -tttt -e -i enp2s0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-26 15:10:00.701941 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:00.701965 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:01.699156 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:01.699169 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:02.699141 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:02.699154 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:05.707404 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:05.707417 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:06.707097 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:06.707110 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:07.707094 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:07.707107 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28

tcpdump no servidor host 20.04:

doug@s19:~$ sudo tcpdump -n -tttt -e -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-26 15:11:35.801771 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:36.800497 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:37.800491 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:40.807062 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:41.804469 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:42.804444 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:45.812553 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:46.812405 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:47.812398 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28

Como uma observação lateral: da minha sessão ssh encadeada para o servidor host 20.04, posso encadear novamente e ssh para o cliente VM muito bem.

Conclusão: Algo está errado na camada de link no servidor Ubuntu 20.04, de modo que os pacotes recebidos nem são "vistos" pelo tcpdump, nem chegam ao convidado da VM. Diagrama .

EDIT 4: Comparando com as informações fornecidas por Christian Ehrhardt, uma diferença potencial no meu sistema é que a lista br0 MAC pode estar incorreta, com o primeiro byte substituído. Nota: MAC não relevante excluído, 3 VMs em execução:

doug@s19:~$ brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     3c:7c:3f:0d:99:83       yes                0.00  <<< enp3s0, br0
  1     3c:7c:3f:0d:99:83       yes                0.00  <<< enp3s0, br0
  4     52:54:00:22:2f:dc       no                 5.15  <<< VM 3
  2     52:54:00:60:ea:0e       no                 3.29  <<< VM 1
  3     52:54:00:60:ea:3e       no                12.67  <<< VM 2
  4     fe:54:00:22:2f:dc       yes                0.00  <<< vnet2
  4     fe:54:00:22:2f:dc       yes                0.00  <<< vnet2
  2     fe:54:00:60:ea:0e       yes                0.00  <<< vnet0
  2     fe:54:00:60:ea:0e       yes                0.00  <<< vnet0
  3     fe:54:00:60:ea:3e       yes                0.00  <<< vnet1
  3     fe:54:00:60:ea:3e       yes                0.00  <<< vnet1

Por alguma razão Christian não mostra uma vnet, ou seja lá o que for chamado em seu sistema, conexão com a ponte (não sei se é relevante ou não):

$ brctl showmacs br0
port no mac addr        is local?   ageing timer
  2 52:54:00:48:40:69   no         2.36   <- Guest
  1 52:54:00:95:e4:2a   no         0.00   <- outside system
  1 52:54:00:9b:9b:0e   yes        0.00   <- Host
  1 52:54:00:9b:9b:0e   yes        0.00   <- Host

EDIT 5: Dados semelhantes ao EDIT 4, mas do Debian Server com 2 VMs em execução, que está funcionando corretamente:

doug@s15:~$ sudo brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     52:54:00:22:2f:dc       no                17.85
  2     52:54:00:27:1b:5e       no                18.48  <<< VM 1
  3     52:54:00:27:1b:ae       no                 2.14  <<< VM 2
  1     f4:8c:eb:c8:08:a0       no                18.48
  2     fe:71:fa:75:16:93       yes                0.00  <<< tap0 (VM1)
  2     fe:71:fa:75:16:93       yes                0.00  <<< tap0
  3     fe:e1:c5:2a:c7:e3       yes                0.00  <<< tap1 (VM2)
  3     fe:e1:c5:2a:c7:e3       yes                0.00  <<< tap1

EDIT 6: informações de networkctl, o que deve ser observado é que o servidor Debian mostra "Master: br0", enquanto o servidor Ubuntu não:

Ubuntu:

doug@s19:~$ networkctl
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp3s0 ether    enslaved    configured
  3 br0    bridge   routable    configured
  4 vnet0  ether    carrier     unmanaged

4 links listed.
doug@s19:~$ man networkctl
doug@s19:~$ networkctl^Cnetworkctl
doug@s19:~$ networkctl status vnet0
● 4: vnet0
             Link File: /usr/lib/systemd/network/99-default.link
          Network File: n/a
                  Type: ether
                 State: carrier (unmanaged)
                Driver: tun
            HW Address: fe:54:00:60:ea:0e
                   MTU: 1500 (min: 68, max: 65521)
  Queue Length (Tx/Rx): 1/1
      Auto negotiation: no
                 Speed: 10Mbps
                Duplex: full
                  Port: tp

Apr 30 07:40:51 s19 systemd-networkd[530]: vnet0: Link UP
Apr 30 07:40:51 s19 systemd-networkd[530]: vnet0: Gained carrier

Debian:

doug@s15:~$ networkctl
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp3s0 ether    enslaved    configured
  3 enp1s0 ether    routable    configured
  4 br0    bridge   routable    configured
 10 tap0   ether    carrier     unmanaged

5 links listed.
doug@s15:~$ networkctl status tap0
● 10: tap0
             Link File: /usr/lib/systemd/network/99-default.link
          Network File: n/a
                  Type: ether
                 State: carrier (unmanaged)
                Driver: tun
            HW Address: fe:8a:6a:ce:18:9c
                   MTU: 1500 (min: 68, max: 65521)
                 QDisc: pfifo_fast
                Master: br0   <<<<< Different than Ubuntu
  Queue Length (Tx/Rx): 1/1
      Auto negotiation: no
                 Speed: 10Mbps
                Duplex: full
                  Port: tp

Pergunta: O que está errado e como posso fazer com que as VMs em ponte funcionem corretamente?

Doug Smythies

Asked: 2020-04-24 06:53:30 +0800 CST

Apache RedirectMatch em help.ubuntu.com não redirecionando em todos os casos

1

Para 20.04, o guia do servidor Ubuntu foi movido para um novo local. Redirecionamentos foram adicionados ao arquivo .htaccess. No entanto, eles não estão funcionando para todos os URLs.

Observe que as partes relacionadas de help.ubuntu.com são publicadas a partir do branch master launchpad apenas uma vez por dia. O objetivo é acertar, como eu obviamente não fiz ontem.

Exemplo de trabalho:

https://help.ubuntu.com/20.04/serverguide/remote-administration.html.fr

vai para:

https://ubuntu.com/server/docs

Não funciona exemplo:

https://help.ubuntu.com/20.04/serverguide/remote-administration.html

retorna 404 Não encontrado.

A parte relevante do arquivo .htaccess:

# For 20.04, and likely onwards, the serveguide has moved.
# Don't try to be too clever, just force the base page and drop the rest.
#
RedirectMatch permanent ^/(stable|lts|20\.04)/(serverguide/.+\.html)\..* https://ubuntu.com/server/docs
RedirectMatch permanent ^/(stable|lts|20\.04)/(serverguide/.+\.pdf)\..* https://assets.ubuntu.com/ubuntu-server-guide

Parece precisar da extensão de idioma para funcionar. Isso vai funcionar?

RedirectMatch permanent ^/(stable|lts|20\.04)/(serverguide/.+\.html) https://ubuntu.com/server/docs
RedirectMatch permanent ^/(stable|lts|20\.04)/(serverguide/.+\.pdf) https://assets.ubuntu.com/ubuntu-server-guide

Não tenho como testar isso no meu servidor de teste, e gostaria de acertar na próxima publicação.

EDIT: Ao excluir a parte "início da linha" da expressão, acontece que posso depurar isso no meu servidor de teste, onde o local está em vários subdiretórios. Com os testes de Muru com a resposta e meus próprios testes, há é a confiança na solução.

Referências:
https://help.ubuntu.com/
https://code.launchpad.net/~ubuntu-core-doc/help.ubuntu.com/help.ubuntu.com
https://bazaar.launchpad.net/ ~ubuntu-core-doc/help.ubuntu.com/help.ubuntu.com/view/head:/.htaccess
servidor web Apache - como remover extensões de linguagem

Doug Smythies

Asked: 2019-06-21 13:39:52 +0800 CST

Servidor web Apache - como remover extensões de idioma

2

Esta pergunta se refere à publicação do Ubuntu Serverguide em help.ubuntu.com. Para o ciclo 20.04 LTS, haverá (OK pode) mudanças significativas no fluxo de trabalho do código-fonte para o Ubuntu Serverguide. Atualmente, as traduções não estão sendo consideradas para essa migração. Nosso melhor feedback foi que os administradores de servidor preferem o inglês, mesmo que não seja seu primeiro idioma. Antes que a decisão se torne irreversível, queremos testá-la fazendo o próximo lançamento pontual do Ubuntu Serverguide 18.04 apenas em inglês dos EUA. Tudo está pronto, exceto por um problema:

Sabemos com certeza que existem muitos links, favoritos, etc. com a extensão de idioma. Exemplo:

https://help.ubuntu.com/lts/serverguide/networking.html.en-CA

E queremos que esse cenário retorne esta página:

https://help.ubuntu.com/lts/serverguide/networking.html

porque as versões específicas do idioma não existirão mais, mas retornar um erro 404 Not Found é indesejável.

A versão atual de um arquivo .htaccess, com tentativas anteriores comentadas, é:

# unable to make below method work.
#RedirectMatch permanent ^(*\.html)\.*$ $1
#
# enable rewriting
RewriteEngine on
#RewriteRule ^(*\.html)\.*$ $1 [R=301, L]
#RewriteRule ^(*\.html)\.*$ $1
RewriteRule ^(*\.html)\.*$ $1 [PT]
#RewriteRule ^(*.html).*$ $1

Resultando em:

500 Internal Server Error

para o cliente, e isso nos logs do servidor de teste:

[Thu Jun 20 11:57:07.647838 2019] [core:alert] [pid 16079] [client 192.168.111.101:62992] /home/doug/public_html/linux/ubuntu-docs/help.ubuntu.com/dev/lts/serverguide/.htaccess: RewriteRule: cannot compile regular expression '^(*\\.html)\\.*$', referer: http://my-test-website/~doug/linux/ubuntu-docs/help.ubuntu.com/dev/index.html
[Thu Jun 20 14:19:27.360334 2019] [core:alert] [pid 16079] [client 192.168.111.101:63908] /home/doug/public_html/linux/ubuntu-docs/help.ubuntu.com/dev/lts/serverguide/.htaccess: RewriteRule: cannot compile regular expression '^(*\\.html)\\.*$', referer: http://my-test-website/~doug/linux/ubuntu-docs/help.ubuntu.com/dev/index.html

Observe que as tentativas atuais estão com um curinga para a extensão do idioma. Se isso não for possível, a lista de idiomas é:

ace ar ast be bg bn bs ca cs da de el en en_AU en_CA en_GB eo es et eu fa fi fr gl gu he hr hu id is it ja km ko ku lo lt lv mk ms nb nl oc pl ps pt_BR pt ro ru sk sl sq sr sv th tl tr ug uk ur vi zh_CN zh_TW

Alguém pode ajudar com isso?

Rede em ponte em pacotes endereçados por LAN KVM/Qemu descartados

Apache RedirectMatch em help.ubuntu.com não redirecionando em todos os casos

Servidor web Apache - como remover extensões de idioma

Existe um comando para listar todos os usuários? Também para adicionar, excluir, modificar usuários, no terminal?

Como excluir um diretório não vazio no Terminal?

Como descompactar um arquivo zip do Terminal?

Como instalo um arquivo .deb por meio da linha de comando?

Como instalo um arquivo .tar.gz (ou .tar.bz2)?

Como listar todos os pacotes instalados

Doug Smythies's questions