Ubuntu 18.04 3 сетевых интерфейса в netplan, два работают, третий нет, почему?

Question

[emellstornn]

Добрый день. Имеется следующая штука: ес2 на амазоне, к нему подключено 3 сетевых интерфейса, прикручено 12 статических ip-адресов (по 4 на каждый интерфейс)
Согласно амазоновским манам по данному вопросу был создан yaml-файл следующего содержания:

network:
  version: 2
  ethernets:
    ens6:
      addresses:
       - 172.31.24.254/20
       - 172.31.23.41/20
       - 172.31.23.226/20
       - 172.31.19.241/20
      dhcp4: no
      routes:
       - to: 0.0.0.0/0
         via: 172.31.16.1 # Default gateway
         table: 1000
       - to: 172.31.24.254
         via: 0.0.0.0
         scope: link
         table: 1000
       - to: 172.31.23.41
         via: 0.0.0.0
         scope: link
         table: 1000
       - to: 172.31.23.226
         via: 0.0.0.0
         scope: link
         table: 1000
       - to: 172.31.19.241
         via: 0.0.0.0
         scope: link
         table: 1000

      routing-policy:
        - from: 172.31.24.254
          table: 1000
        - from: 172.31.23.41
          table: 1000
        - from: 172.31.23.226
          table: 1000
        - from: 172.31.19.241
          table: 1000

    ens7:
      addresses:
       - 172.31.18.160/20
       - 172.31.24.120/20
       - 172.31.22.168/20
       - 172.31.28.164/20
      dhcp4: no
      routes:
       - to: 0.0.0.0/0
         via: 172.31.16.1 # Default gateway
         table: 1000
       - to: 172.31.18.160
         via: 0.0.0.0
         scope: link
         table: 1000
       - to: 172.31.24.120
         via: 0.0.0.0
         scope: link
         table: 1000
       - to: 172.31.22.168
         via: 0.0.0.0
         scope: link
         table: 1000
      - to: 172.31.28.164
        via: 0.0.0.0
         scope: link
         table: 1000

      routing-policy:
        - from: 172.31.18.160
          table: 1000
       - from: 172.31.24.120
          table: 1000
        - from: 172.31.22.168
          table: 1000
        - from: 172.31.28.164
          table: 1000

Интерфейс ens6 функционирует полностью, пингуется извне. Ens7 пингуется только с самого сервера, извне не пингуется. Где собака зарыта?
Спасибо!

P.S. Вывод ip addr

ubuntu@ip-172-31-17-117:~$ 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
       valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0e:80:69:25:ae:58 brd ff:ff:ff:ff:ff:ff
    inet 172.31.17.117/20 brd 172.31.31.255 scope global dynamic ens5
       valid_lft 3593sec preferred_lft 3593sec
    inet6 fe80::c80:69ff:fe25:ae58/64 scope link
       valid_lft forever preferred_lft forever
3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 0e:6b:0a:32:91:7a brd ff:ff:ff:ff:ff:ff
    inet 172.31.24.254/20 brd 172.31.31.255 scope global ens6
       valid_lft forever preferred_lft forever
    inet 172.31.23.41/20 brd 172.31.31.255 scope global secondary ens6
       valid_lft forever preferred_lft forever
    inet 172.31.23.226/20 brd 172.31.31.255 scope global secondary ens6
       valid_lft forever preferred_lft forever
    inet 172.31.19.241/20 brd 172.31.31.255 scope global secondary ens6
       valid_lft forever preferred_lft forever
    inet6 fe80::c6b:aff:fe32:917a/64 scope link
       valid_lft forever preferred_lft forever
4: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0e:29:4b:8f:d2:b2 brd ff:ff:ff:ff:ff:ff
    inet 172.31.18.160/20 brd 172.31.31.255 scope global dynamic ens7
       valid_lft 322sec preferred_lft 322sec
    inet 172.31.22.168/20 brd 172.31.31.255 scope global secondary ens7
       valid_lft forever preferred_lft forever
    inet 172.31.28.164/20 brd 172.31.31.255 scope global secondary ens7
       valid_lft forever preferred_lft forever
    inet 172.31.24.120/20 brd 172.31.31.255 scope global secondary ens7
       valid_lft forever preferred_lft forever
    inet6 fe80::c29:4bff:fe8f:d2b2/64 scope link
       valid_lft forever preferred_lft forever

Comments

[hint000]

Было бы неплохо, если бы вы описали чего вы хотите получить в результате такой странной настройки. Два интерфейса в одной подсети, при этом нет bond. В чём цель такого чудо-юдо-конфига?

Согласно амазоновским манам

А можно ссылку на маны?

[emellstornn]

hint000, задача такая:
Есть Х адресов, в моем случае 12, потом будет больше. Есть сервер, на который я вешаю эти адреса. На нем стоит софтина, которая делает запросы на один ресурс. Нужно, чтобы она эти запросы делала с разных, но строго определенных адресов.
Проблема в том, что на один сетевой интерфейс Амазон не даёт вешать больше 4 адресов, причем адреса привязаны к интерфейсу через их веб-морду. То есть сперва я получаю соответствие адресов и интерфейсов, и только потом могу выпускать из наружу.
Мануал скину через час, сейчас с телефона. Спасибо.

[hint000]

софтина, которая делает запросы на один ресурс. Нужно, чтобы она эти запросы делала с разных, но строго определенных адресов

Дык вам нужны разные внешние адреса (белые), очевидно. А вы пытаетесь прописать кучу серых, это вам никак не поможет, потому что наружу (в интернет) все они могут (и будут, скорее всего) выходить с одного и того же белого адреса через NAT. Т.е. "ресурс" все запросы будет получать с одного адреса (его нет в этом конфиге; грубо говоря, он где-то там, в самом Амазоне). Вашу задачу можно решить с помощью пачки проксей или пачки VPN.

Я так понимаю, для какой-то накрутки (или наоборот, для слива) из-под виртуальных аккаунтов... :-]

[Ruslan-Strannik]

ens6 функционирует полностью, пингуется извне.

и по какому адресу он пингуется?

[emellstornn]

hint000, ман с амазона:
https://aws.amazon.com/ru/premiumsupport/knowledge...
Я знаю, что мне нужны белые адреса. И именно их я и получаю. Вы, похоже, никогда не работали с aws.amazon и их механикой elactic IP? Каждому адресу типа "172.31.22.168" сопоставлен соответствующий белый адрес. Полностью весь их роутинг мне абсолютно непрозрачен.
Для восьми IP-адресов мой конфиг работает, мне кажется, я вполне доступно это описал. То есть, еще раз:
два сетевых интерфейса, 8 серых адресов, 8 белых адресов, сопоставленных амазоном с серыми, которые прописываю я. С этих 8 адресов я могу выходить в мир, эти 8 адресов пингуются из мира. Добавляю третий сетевой интерфейс с аналогичным конфигом - и он не имеет выхода наружу, хотя внутри сети амазона все это пингуется прекрасно.
Нет, не накрутка (не слив). Для накрутки или слива городить такой огород нет смысла. Нет, прокси или впн не вариант.
Ruslan-Strannik а вам это зачем? Пингуется по всем четырем белым адресам, сопоставленным серым адресам, которые можно увидеть в приведенном выводе Ip addr.

Answer 1

[emellstornn]

UPD: В итоге, решением проблемы оказалась ассиметричная маршрутизация.

Выровнял, проверил. Теперь я понимаю еще меньше.
У меня заработал один из четырех адресов для третьего интерфейса (действительно, пробелы). Но:
а) не из тех, где не хватало пробелов
б) раньше статус гейта для третьего интерфейса был STALE, для остальных - REACHABLE, и я думал, что это основная причина. Ну, раз внутри амазона пингуются все 12 адресов, снаружи - только 8, и с 4 остальных наружу тоже не пробиться - дело в гейте, вроде логично. Но теперь для третьего интерфейса гейт тоже стал REACHABLE!
За подсказку спасибо, в любом случае прогресс, теперь у меня 9 адресов. Завтра продолжу мучать конфиг дальше.
P.S. Найти бы маны, для дилетантов, где описан процесс добавления трех сетевых интерфейсов, да не нашел, все заканчиваются на двух.

Answer 2

[hint000]

Как минимум, конфиг не удовлетворяет требованиям официальной спецификации YAML. Парсер мог не распарсить часть конфига, результат применения трудно предсказать.
https://yaml.org/spec/1.2/spec.html#id2777534

Each node must be indented further than its parent node. All sibling nodes must use the exact same indentation level.

в строках, помеченных звёздочкой, не хватает пробелов:

routes:
       - to: 0.0.0.0/0
         via: 172.31.16.1 # Default gateway
         table: 1000
       - to: 172.31.18.160
         via: 0.0.0.0
         scope: link
         table: 1000
       - to: 172.31.24.120
         via: 0.0.0.0
         scope: link
         table: 1000
       - to: 172.31.22.168
         via: 0.0.0.0
         scope: link
         table: 1000
*     - to: 172.31.28.164
*       via: 0.0.0.0
         scope: link
         table: 1000

      routing-policy:
        - from: 172.31.18.160
          table: 1000
*      - from: 172.31.24.120
          table: 1000
        - from: 172.31.22.168
          table: 1000
        - from: 172.31.28.164
          table: 1000

Выровняйте и проверьте, а вдруг заработает.