Solución de problemas de rutas netplan en el servidor 22.04.2

Solución de problemas de rutas netplan en el servidor 22.04.2

Estoy buscando orientación sobre la forma correcta de configurar esta red. Tengo una instancia del servidor ubuntu 22.04.2 ejecutándose en proxmox. Se conectan dos interfaces a la máquina virtual y proxmox maneja el etiquetado de vlan.

Tengo dos VLAN en uso. Ens18 está en 100 y ens19 está en 300. En mis intentos iniciales utilicé netplan con la siguiente configuración.

network:  version: 2
  renderer: networkd
  ethernets:
    ens18:
      dhcp4: true
      dhcp4-overrides:
        route-metric: 100
    ens19:
      dhcp4: true
      dhcp4-overrides:
        route-metric: 200

ruta -n

Kernel IP routing tableDestination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.86.1    0.0.0.0         UG    100    0        0 ens18
0.0.0.0         192.168.254.1   0.0.0.0         UG    200    0        0 ens19
192.168.86.0    0.0.0.0         255.255.255.0   U     100    0        0 ens18
192.168.86.1    0.0.0.0         255.255.255.255 UH    100    0        0 ens18
192.168.86.16   0.0.0.0         255.255.255.255 UH    100    0        0 ens18
192.168.254.0   0.0.0.0         255.255.255.0   U     200    0        0 ens19
192.168.254.1   0.0.0.0         255.255.255.255 UH    200    0        0 ens19

ifconfig

ens18: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500        inet 192.168.86.28  netmask 255.255.255.0  broadcast 192.168.86.255
        inet6 fe80::ecc6:d9ff:fe43:6711  prefixlen 64  scopeid 0x20<link>
        ether ee:c6:d9:43:67:11  txqueuelen 1000  (Ethernet)
        RX packets 930  bytes 149307 (149.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 427  bytes 62104 (62.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


ens19: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.254.35  netmask 255.255.255.0  broadcast 192.168.254.255
        inet6 fe80::443a:61ff:fedc:4864  prefixlen 64  scopeid 0x20<link>
        ether 46:3a:61:dc:48:64  txqueuelen 1000  (Ethernet)
        RX packets 295  bytes 32942 (32.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16  bytes 1736 (1.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 84  bytes 6368 (6.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84  bytes 6368 (6.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Si bien esto funciona y el enrutador asigna las direcciones IP, existe un problema con lo que parece ser un enrutamiento asimétrico. Desde mi computadora en la vlan 100, si inicio una sesión SSH en la dirección IP en la vlan 300, el tiempo de espera expirará después de aproximadamente un minuto. Según lo que encontré después de buscar en Google, tengo entendido (limitado) que el servidor está tomando el camino más corto de regreso a mi computadora, ya que tiene una interfaz presente en la subred vlan 100.

La lectura continua me llevó a establecer rutas estáticas a través de netplan. Seguí la guía de netplan.io y usé esta configuración.

network:  version: 2
  renderer: networkd
  ethernets:
      ens18:
          addresses:
            - 192.168.86.28/24
          nameservers:
            addresses: [8.8.8.8]
          dhcp4: no
          routes:
            - to: default
              via: 192.168.86.1
            - to: 192.168.86.0/24
              via: 192.168.86.1
              table: 101
          routing-policy:
            - from: 192.168.86.0/24
              table: 101
      ens19:
          addresses:
            - 192.168.254.35/24
          nameservers:
            addresses: [8.8.8.8]
          dhcp4: no
          routes:
            - to: 192.168.254.0/24
              via: 192.168.254.1
              table: 102
          routing-policy:
            - from: 192.168.254.0/24
              table: 102

ruta -n

Kernel IP routing tableDestination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.86.1    0.0.0.0         UG    0      0        0 ens18
192.168.86.0    0.0.0.0         255.255.255.0   U     0      0        0 ens18
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 ens19

ifconfig

ens18: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500        
        inet 192.168.86.28  netmask 255.255.255.0  broadcast 192.168.86.255
        inet6 fe80::ecc6:d9ff:fe43:6711  prefixlen 64  scopeid 0x20<link>
        ether ee:c6:d9:43:67:11  txqueuelen 1000  (Ethernet)
        RX packets 566  bytes 98730 (98.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 101  bytes 12613 (12.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


ens19: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.254.35  netmask 255.255.255.0  broadcast 192.168.254.255
        inet6 fe80::443a:61ff:fedc:4864  prefixlen 64  scopeid 0x20<link>
        ether 46:3a:61:dc:48:64  txqueuelen 1000  (Ethernet)
        RX packets 40  bytes 4812 (4.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14  bytes 964 (964.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 86  bytes 6566 (6.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 86  bytes 6566 (6.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Sigo teniendo el mismo comportamiento en el que las sesiones ssh fallarán después de uno o dos minutos. También probé esto con una instancia de node-red en la VM y veo el mismo comportamiento después de aproximadamente un minuto. Parece ser un problema similar con el tráfico TCP. Aquí hay una toma de un rastro de Wirehark. Puedo proporcionar detalles adicionales de este registro si es útil.

https://i.stack.imgur.com/GYgjq.jpg

editar 27/03/23: Probé un experimento similar usando una computadora portátil física con dos interfaces físicas para ver si el problema tenía algo que ver con la virtualización del servidor. Usando el mismo netplan terminé con los mismos resultados. En este punto, el problema no parece estar relacionado con el lado de la máquina virtual.

Mis preguntas son:

¿Es correcta mi configuración de netplan? No estoy seguro de si estos son los resultados esperados de la configuración y si el enrutamiento parece correcto. Si no es correcto ¿dónde debo hacer ajustes?

Si es correcto, ¿cuál sería el siguiente lugar para investigar este problema? Intenté bajar a una interfaz única en la máquina virtual que solo accede a vlan 300 y no hay problemas. Solo se convierte en un problema cuando se atraviesa la VLAN y con ambas interfaces activas. Si hay alguna otra información útil que pueda proporcionar, hágamelo saber.

Gracias de antemano.

información relacionada