Dos direcciones en una NIC, la actualización de Ubuntu de hoy la ha roto

Dos direcciones en una NIC, la actualización de Ubuntu de hoy la ha roto

Estoy ejecutando Ubuntu 16.04 en un NUC para administrar mis redes domésticas y laborales. A la NIC única en el NUC se le asignan dos direcciones IP, una en cada red, mediante las siguientes líneas en /etc/network/interfaces:

auto lo
iface lo inet loopback
#1st is home
auto enp3s0
iface enp3s0 inet static
  address 192.168.0.1
  netmask 255.255.255.0
  gateway 192.168.0.254 # huawei modem
  dns-search homenet
#2nd is work vpn
auto enp3s0:1
iface enp3s0:1 inet static
  address 172.16.9.1
  netmask 255.255.255.240
  gateway 172.16.9.1
  dns-search xx.yy.xx.com

ifconfigSolía ​​mostrarme ambas direcciones inet 192.168.0.1y 172.16.9.1, pero desde que ejecuté las actualizaciones de Ubuntu ofrecidas hoy, ahora solo muestra la primera. Las máquinas en la subred de trabajo no pueden verse entre sí ni a la red exterior porque 172.16.9.1no se puede acceder a la dirección IP.

Algo debe haber cambiado pero no sé qué ni cómo solucionarlo.

Esta máquina se está ejecutando isc-dhcp-serverpara asignar direcciones IP tanto en la red doméstica como en la laboral, y bind9para realizar búsquedas de DNS para la red doméstica. Cuando funciona correctamente, la VPN administra el DNS para las máquinas de trabajo.

No estoy usando el administrador de red gráfico.

¿Alguna idea de qué podría mirar para que esto funcione nuevamente?

ACTUALIZAR: Posteriormente vi una línea boot.logque no estaba allí en el pasado:

Failed to start Raise network interfaces.
See 'systemctl status networking.service' for details.

Entonces hice eso. y puedo ver el siguiente mensaje 4 veces:

ifup[670]: Another app is currently holding the xtables lock.
   Perhaps you want to use the -w option?

Dentro /etc/networktengo un if-pre-up.d/iptablesscript que llama al iptablescomando del sistema cinco veces. Supongo que de aquí proviene el error, pero ha funcionado de manera confiable hasta la actualización de hoy. Si bien podría exponer -wtodas estas líneas, sospecho que estaría tratando un síntoma en lugar de abordar la causa real, que aún no he identificado.

ACTUALIZACIÓN 2: Originalmente pensé que las cinco llamadas a iptablesen mi guión habían producido cuatro xtables lockerrores. Lo que descubrí es que mi script en realidad se llama cuatro veces: una para cada interfaz ( lo, enp3s0y enp3s0:1) y una vez con un $IFACEvalor de --all. Las invocaciones para --ally enp3s0se ejecutan simultáneamente y una bloquea a la otra.

No puedo encontrar nada en los registros de cambios, pero me atrevería a suponer que ejecutar este script para IFACE=--all es quizás la causa subyacente del problema que estoy teniendo.

gracias de antemano

Saludos, T.

información relacionada