Работа с параметрами контекстуализации

Параметры контекстуализации, указанные в шаблоне ВМ, определяют начальную конфигурацию ВМ. Для настройки VNF существуют специфичные наборы параметров для каждой из функций виртуальной сети. Параметры должны быть указаны в разделе CONTEXT шаблона ВМ.

Если параметры поддерживают указание нескольких значений, эти значения могут быть разделены пробелами (x y), запятыми (x,y) или точками с запятой (x;y).

У каждой функции VNF есть параметр контекстуализации, который определяет, на каких сетевых интерфейсах подключенная функция будет активна, а на каких нет. Если не указывать эти параметры, то подключенная функция VNF прослушивает все доступные интерфейсы (за исключением loopback-интерфейса и интерфейса управления).

При указании в параметрах сетевых интерфейсов всегда необходимо использовать имена интерфейсов вида eth, за которыми следует индекс, начинающийся с 0, т.е. eth0 для первой сетевой карты, eth4 для пятой сетевой карты. Например, чтобы включить функцию DNS VNF только на 3-м и 4-м сетевых интерфейсах, параметр контекстуализации должен выглядеть следующим образом: 

ONEAPP_VNF_DNS_INTERFACES="eth2 eth3"

Высокая доступность (keepalived)

Keepalived — это служба обеспечивающая высокую доступность VNF на основе протокола VRRP и специального сервиса, отслеживающего состояние экземпляра ВМ виртуального маршрутизатора и его сетевых функций.. В случае инцидента (недоступности сервиса VNF) сервис перенесет все плавающие IP-адреса и сетевые функции на другой экземпляр виртуального маршрутизатора с минимальным временем простоя.

Для работы keepalived должен быть настроен хотя бы один VNF и один плавающий IP-адрес. Также должен быть указан параметр ONEAPP_VNF_KEEPALIVED_VRID, уникальный для подсетей. В противном случае разные ВМ с одинаковым идентификатором могут безуспешно пытаться объединиться в один и тот же кластер.

Многократная быстрая последовательная реконфигурация ВМ или виртуального маршрутизатора (например, горячее подключение нескольких сетевых адаптеров) может привести к сбою в работе кластера Keepalived. При реконфигурации всегда необходимо проверять, находится ли экземпляр в нужном состоянии после каждого изменения.

Переход между состояниями BACKUP/MASTER и инициализацию других VNF функций можно отследить в журнале сервиса выполнив команду:

sudo journalctl -u keepalived

Основные параметры контекстуализации

Расширенные параметры контекстуализации

ROUTER4

Сервис VNF обеспечивает функциональность маршрутизации между различными сетями и позволяет ВМ из разных виртуальных сетей взаимодействовать друг с другом. Если включить функцию маршрутизации (параметр ONEAPP_VNF_ROUTER4_ENABLED="YES"), то по умолчанию маршрутизация будет выполняться между всеми подключенными интерфейсами (кроме интерфейса управления). Для выбора определенных интерфейсов для маршрутизации необходимо указать значение параметра ONEAPP_VNF_ROUTER4_INTERFACES. 

Функция ROUTER4 обеспечивает только маршрутизацию. Например, для того чтобы предоставить ВМ частной сети доступ к общедоступным интернет-сервисам, эту функцию необходимо использовать вместе с NAT4.

Функция ROUTER4 использует стандартные возможности IP-стека Linux по маршрутизации транзитных IP-пакетов (IP forwarding).

Основные параметры контекстуализации

DHCP4

VNF предоставляет сервис протокола динамической настройки узла (DHCPv4), реализованный с помощью DHCP-сервера ISC Kea версии 2.2.0.

При настройке DHCPv4 всегда необходимо указывать список интерфейсов в параметре ONEAPP_VNF_DHCP4_INTERFACES. В противном случае работа службы будет распространятся на все интерфейсы (несвязанные с управлением) и все настроенные подсети.

По умолчанию, сервис предоставляет сетевую конфигурацию для DHCP-клиентов основываясь на конфигурации интерфейсов, включенных параметром ONEAPP_VNF_DHCP4_INTERFACES. Конфигурация создается на основе заданных постоянных параметров контекста виртуальных сетей (например, ETH0_GATEWAY), а не из действующей конфигурации конкретных сетевых интерфейсов. Настройки могут быть предопределены параметрами контекстуализации DHCP VNF, с указанием сетевого интерфейса или псевдонима, например:

CONTEXT=[
    ONEAPP_VNF_DHCP4_ETHx="<CIDR>:<start IP>-<end IP>",
    ONEAPP_VNF_DHCP4_ETHx_DNS="<IP> ...",
    ONEAPP_VNF_DHCP4_ETHx_GATEWAY="<IP> ...",
    ONEAPP_VNF_DHCP4_ETHx_MTU="<number>",
    ONEAPP_VNF_DHCP4_ETHx_ALIASy="<CIDR>:<start IP>-<end IP>",
    ONEAPP_VNF_DHCP4_ETHx_ALIASy_DNS="<IP> ...",
    ONEAPP_VNF_DHCP4_ETHx_ALIASy_GATEWAY="<IP> ...",
    ONEAPP_VNF_DHCP4_ETHx_ALIASy_MTU="<number>",
    ...
]

Параметры контекстуализации для псевдонимов сетевых интерфейсов применяются только в том случае, если подсеть псевдонима уникальна (т.е. ни один другой интерфейс не использует ту же подсеть). В противном случае конкретная конфигурация псевдонима сетевого адаптера игнорируется. Контекстуализация основных (без псевдонимов) интерфейсов всегда имеет приоритет над псевдонимами сетевых интерфейсов для одной и той же подсети.

Пример

В ВМ настроены интерфейс и его псевдонимом — eth0: 192.168.0.1/255.255.0.0 и eth0 alias 0: 192.168.1.100/255.255.0.0, и следующая контекстуализация DHCP4 VNF:

CONTEXT=[
     ONEAPP_VNF_DHCP4_ETH0_DNS="8.8.8.8",
     ONEAPP_VNF_DHCP4_ETH0_ALIAS0_DNS="4.4.4.4",
     ONEAPP_VNF_DHCP4_ETH0_ALIAS0="192.168.0.0/16:192.168.100.100-192.168.200.250",
     ...
]

CODE

В этом примере интерфейс eth0 и его псевдоним используют одну подсеть, но имеются два разных параметра, переопределяющих настройки сервера имен и пула IP-адресов (по-умолчанию и конкретно заданные). Таким образом, когда VNF пытается создать конфигурацию DHCP4, он встречает конфликт пулов адресов и параметров (DNS, GATEWAY, и MTU). Именно по этому переменные сетевого интерфейса (ONEAPP_VNF_DHCP4_ETH0) всегда главнее в таких сценариях (ONEAPP_VNF_DHCP4_ETH0_ALIAS0 и ONEAPP_VNF_DHCP4_ETH0_ALIAS0_DNS будут проигнорированы).

Конечная сгенерированная конфигурации из этого примера:

...
"subnet4": [
{
  "subnet": "192.168.0.0/16",
  "pools": [ { "pool": "192.168.0.2-192.168.255.254" } ],
  "option-data": [
    { "name": "domain-name-servers", "data": "8.8.8.8" },
    { "name": "routers", "data": "192.168.0.1" }
  ],
  "reservations": [
    { "flex-id": "'DO-NOT-LEASE-192.168.101.1'", "ip-address": "192.168.0.1" },
    { "flex-id": "'DO-NOT-LEASE-192.168.101.100'", "ip-address": "192.168.1.100" }
  ],
  "reservation-mode": "all"
},

CODE

Для более тонкой настройки конфигурации подсетей можно напрямую передать параметры DHCP-сервера с помощью параметра ONEAPP_VNF_DHCP4_SUB. Значением параметра должна являться корректная JSON-конфигурация для ISC Kea ( раздел subnet4 section), закодированная в Base64. Так же может быть указано больше переменных конфигурации, и они должны оканчивать на числовые индексы (например, ONEAPP_VNF_DHCP4_SUBNET0). Определения подсетей такими контекстными параметрами всегда имеет приоритет над другими интерфейс-специфичными параметрами (например, заданный параметр ONEAPP_VNF_DHCP4_SUBNET отключает любую контекстуализацию, основанную на конфигурации интерфейса). 

Так же возможна живая переконфигурация и адаптирование к контексту по мере внесения изменений. Возможным последствием может являться то, что некоторые прежде назначенные переменные могут оставаться активными даже после их удаления! Для примера, проблема может возникнуть, если переменные вида ONEAPP_VNF_DHCP4_SUBNET были заданы, но теперь вы желаете использовать переменные интерфейсов (вида ONEAPP_VNF_DHCP4_ETHx), удаляете первую переменную, но она все еще продолжает существовать в рамках контекста. Обходным решением является назначение переменным пустого контекста, вместо их удаления (для примера, ONEAPP_VNF_DHCP4_SUBNET0="").

Не рекомендуется удалять ранее использованные параметры контекстуализации, вместо этого необходимо задать пустую строку в качестве значения. Далее можно безопасно их удалить после повторной контекстуализации или перезагрузки виртуального маршрутизатора.

Трансляция MAC-адреса в IPv4 

В ПК СВ существует прямая корреляция между MAC и IPv4 адресами, выделенными сетевым интерфейсам виртуальных машин. MAC-адреса сетевых интерфейсов формируются из:

• 2-байтового префикса (по умолчанию 02:00). Он может быть назначен переменной MAC_PREFIX в oned.conf;
• шестнадцатеричного представления назначенного IPv4-адреса (например, 01:02:03:04 для адреса 1.2.3.4).

К службе DHCP сервера дополнительно подключен модуль (hook) для реализации функции назначения IPv4 адреса на основе MAC-адреса виртуальной машины. Это позволяет ВМ получать с помощью DHCP такой же адрес, какой она бы получила при обычном использовании виртуальных сетей (параметры которых передаются через статичный контекст ВМ). Это позволяет подключать к виртуальной сети ВМ, не использующие настройку через контекстуализацию (т.е. без установленного пакета one-context).

Функция трансляции MAC-адреса в IPv4 работает полностью автономно, без обращения к серверу управления. Функция включена по умолчанию и может быть отключена переменной ONEAPP_VNF_DHCP4_MAC2IP_ENABLED.

Трансляция может быть настроена на работу только в определенных подсетях с помощью параметра ONEAPP_VNF_DHCP4_MAC2IP_SUBNETS, который принимает в качестве значения список диапазонов в формате CIDR. Для оставшихся сетей, не определенных в этом параметре, применяются обычные правила выделения адресов DHCP-сервером.. Отсутствующий или пустой параметр включает работу трансляции MAC в IPv4 во всех подсетях..

При включенной трансляции MAC-адреса в IPv4 запросы с MAC-адресов, которые не могут быть преобразованы в подходящий IP-адрес, игнорируются.

При настройке DHCP для ВМ, не находящихся под управлением ПК СВ, необходимо задать значение параметра ONEAPP_VNF_DHCP4_MAC2IP_SUBNETS или полностью отключить функцию трансляции MAC-адреса в IPv4 (ONEAPP_VNF_DHCP4_MAC2IP_ENABLED="NO").В противном случае может возникнуть проблема неработоспособности DHCP.

Основные параметры контекстуализации

Расширенные параметры контекстуализации

Параметры ONEAPP_VNF_DHCP4_ETHx_DNS/GATEWAY/MTU применяются только при наличии хотя бы одного диапазона, указанного в параметре ONEAPP_VNF_DHCP4_ETHx. Аналогично, параметры ONEAPP_VNF_DHCP4_ETHx_ALIASy_DNS/GATEWAY/MTU активны при указании хотя бы одного диапазона в ONEAPP_VNF_DHCP4_ETHx_ALIASy.

DNS

Сервис VNF предоставляет службу DNS, которая может делегировать запросы вышестоящим серверам (на основе параметров контекста сети) или напрямую разрешать DNS-запросы самостоятельно.

По умолчанию VNF использует корневые серверы DNS (из dns-root-data от Astra Linux) для самостоятельного разрешения запросов. DNS также может перенаправлять запросы (в случае использования  ONEAPP_VNF_DNS_USE_ROOTSERVERS="NO") на другие настроенные DNS-серверы, указанные в ONEAPP_VNF_DNS_NAMESERVERS или автоматически настроенные из параметров виртуальных сетей.

В режиме перенаправления запросов автоматическая настройка параметров обычно нежелательна, поэтому следует явно указать вышестоящие DNS-сервера, например:

CONTEXT=[
    ONEAPP_VNF_DNS_NAMESERVERS="8.8.8.8, 8.8.4.4",
    ...
]

Сервис может быть ограничен только для обслуживания определенных сетевых интерфейсах через ONEAPP_VNF_DNS_INTERFACES. Помимо описанного выше синтаксиса для перечисления интерфейсов, для которых необходимо включить или выключить функцию (ethX, !ethX), в случае DNS также можно задать дополнительный IP-адрес для прослушивания и порт для конкретного интерфейса (ethX/IP[@port]), например:

CONTEXT=[
    ONEAPP_VNF_DNS_INTERFACES="eth0, eth1/10.0.0.1, eth2/192.168.0.1@53",
    ...
]

Функция DNS может быть отключена для протокола TCP (через ONEAPP_VNF_DNS_TCP_DISABLED="YES") или UDP (через ONEAPP_VNF_DNS_UDP_DISABLED="YES").

Не рекомендуется отключать протокол UDP, поскольку многие общедоступные серверы DNS используют только протокол UDP.

Для полного контроля над DNS VNF можно использовать возможность указания полного конфигурационного файла для DNS-сервера Unbound (ONEAPP_VNF_DNS_CONFIG). Значением должна быть строка в кодировке Base64 с корректным содержимым unbound.conf.

Основные параметры контекстуализации

Расширенные параметры контекстуализации

NAT4

Сервис VNF предоставляет функцию транслирования IPv4 адресов (Network Address Translation, маскарадинг) для подключенных сетевых интерфейсов через указанные выходные интерфейсы.

Выходной интерфейс всегда должен быть указан в параметре ONEAPP_VNF_NAT4_INTERFACES_OUT.

Без указания выходного интерфейса функция NAT4 не сможет быть запущена.

Основные параметры

SDNAT4

Для работы функции SDNAT4 необходимо настроить ПК СВ для использования службы сервера OneGate.

Функция SDNAT4 схожа с функцией NAT4, поскольку реализована при помощи двустороннего NAT: SNAT (исходящий NAT) и DNAT (целевой NAT).

SDNAT4 сопоставляет виртуальные сети, позволяя прозрачно передавать трафик (для какого-либо целевого IP-адреса, например публичного) из одной сети на устройство в другой сети без необходимости прямого подключения устройства к первой сети (то есть, без раскрытия адреса конечного устройства в первой сети). Механизм реализуется с помощью сопоставления указанных двух IP-адресов из разных сетей. Такое сопоставление обслуживается  виртуальным маршрутизатором, к которому должны быть подключены все связанные сети. Внешний IP-адрес для сопоставления должен быть присоединен к ВМ в качестве внешнего псевдонима сетевого интерфейса.

Интерфейсы на виртуальном маршрутизаторе, между которыми может быть установлено сопоставление, всегда должны быть указаны в параметре контекстуализации ONEAPP_VNF_SDNAT4_INTERFACES, в противном случае никакие правила применяться не будут (параметр отличается от подобных параметров в других функциях VNF, где пустой список по умолчанию означает все интерфейсы).

Как только список интерфейсов передается в VNF, служба, развернутая внутри виртуального маршрутизатора, начинает отслеживать изменения в распределении IP-адресов через OneGate. На основе агрегированных данных создается список пар для SNAT/DNAT, где конечная часть - это IP-адрес внешнего псевдонима сетевого интерфейса, а исходная часть - реальный IP-адрес, назначенный ВМ, к которой происходит подключение.

Обязательно должен быть установлен параметр шаблона EXTERNAL=YES, в противном случае псевдоним будет настроен как внутренний и в виртуальной машине появится дополнительный IP-адрес. Использование внешних псевдонимов также может быть реализовано для всех IP-адресов виртуальной сети, если параметр EXTERNAL=YES задан непосредственно в шаблоне вашей виртуальной сети.

Такой псевдоним может быть присоединен к ВМ (например, с идентификатором 10) командой:

onevm nic-attach 10 --file external-nic-alias.tmpl

Основные параметры контекстуализации

LB (LoadBalancer)

Для работы функции LB (LoadBalancer) необходимо настроить ПК СВ для использования службы сервера OneGate.

Функция предоставляет службу балансировщика нагрузки, которая для заданных входящих подключений будет перенаправлять трафик и балансировать нагрузку на пул статических и/или динамических реальных серверов.

Функция LoadBalancer основана на Linux Virtual Server (LVS/IPVS) и использует вспомогательные средства пакета ipvsadm, входящего в состав репозитория Astra Linux.

Основные параметры контекстуализации

Основные параметры влияют на все настроенные балансировщики нагрузки.

Параметры балансировщика нагрузки

Ниже перечислены параметры, определяющие балансировщик нагрузки, если не был настроен параметр ONEAPP_VNF_LB_CONFIG.

Параметр	Значение по умолчанию	Описание
ONEAPP_VNF_LB[0-9]_IP		Обязательный параметр: IP-адрес балансировщика нагрузки Если указан только IP-адрес (не указаны ни порт, ни протокол), то весь трафик по этому IP-адресу с балансировкой нагрузки будет перенаправляться на реальные серверы в соотношении 1:1
ONEAPP_VNF_LB[0-9]_PORT		IP-порт для балансировки соединения (опционально)
ONEAPP_VNF_LB[0-9]_PROTOCOL		IP-протокол для балансировки соединения (опционально TCP, UDP или BOTH)
ONEAPP_VNF_LB[0-9]_METHOD	NAT	Метод LVS/IPVS (NAT или DR (Direct Routing — прямая маршрутизация) Для работы метода прямой маршрутизации потребуются дополнительные действия на реальных серверах, которые описаны в разделе (указать после перевода).
ONEAPP_VNF_LB[0-9]_TIMEOUT	10	Допустимый тайм-аут любого реального сервера для этого LB (секунды)

Метод LVS/IPVS NAT

Балансировщик нагрузки по умолчанию будет использовать метод NAT, при котором VNF будет направлять трафик между ВМ и реальными серверами через себя в обоих направлениях.

Для этого метода потребуется два настроенных сетевых интерфейса в VNF и две виртуальные сети - одна общедоступная, из которой будет инициироваться трафик, и частная, где будут расположены реальные серверы:

NAT method:

                 .--------.
                 | Client |
                 `--------`
                eth0: client IP
                     |
                     |

               (public vnet)

    src: client IP <---> dest: LB IP

                     |
                     |
                eth0: LB IP
              .-------------.
      DNAT >> | VNF/Vrouter | >> SNAT
              `-------------`
                eth1: Priv IP
                     |
                     |

               (private vnet)

    src: client IP <---> dest: RS IP

                     |
                     |
                eth0: RS IP
              .-------------.
              | Real Server |
              `-------------`

Метод LVS/IPVS DR (Direct Routing — прямая маршрутизация)

Альтернативой методу NAT является использование метода прямой маршрутизации. Например, какой-то конкретный балансировщик нагрузки (в данном случае LB0) можно переключить на метод прямой маршрутизации, установив контекстному параметру ONEAPP_VNF_LB0_METHOD (параметру lb-method в конфигурационном JSON) значение DR.

При использовании DR VNF будет видеть только входящий трафик, но исходящий трафик с любого реального сервера будет возвращаться непосредственно на ВМ. Для настройки DR метода потребуется только один сетевой интерфейс и только одна виртуальная сеть:

DR method:

                 .--------.
                 | Client |
                 `--------`
                eth0: client IP

                ^               V
                ^               v
                ^                \______
                |                       \
                |                        `_____
                |                              \
                |                               \
                |
                |                src: client IP --> dest: LB IP
                |
                |                               |
                |
                |                          eth0: LB IP
                                         .-------------.
    src: LB IP --> dest: client IP       | VNF/Vrouter |
                                         `-------------`
                |
                |                               |
                |
                |               src: client IP --> dest: LB IP (!!!)
                |
                |                               /
                |                        ______'
                |                       /
                |                ______'
                ^               /
                ^              v
                ^              V

                lo: LB IP (!!!)
                eth0: RS IP
              .-------------.
              | Real Server |
              `-------------`

На приведенной выше схеме реальный сервер отвечает на любые запросы ARP для IP с балансировкой нагрузки, из-за этого возникает конфликт IP-адресов в одной подсети — IP балансировщика нагрузки настроен как на реальном сервере, так и на VNF.

Для предотвращения этого необходимы следующие дополнительные настройки:

• каждому реальному серверу балансировщика нагрузки, использующего DR, также должен быть назначен IP-адрес с балансировкой нагрузки — для этого можно использовать либо loopback-интерфейс, либо какой-либо интерфейс-заглушку (modprobe dummy).:

  $ ip addr add <LB_IP> dev lo

  CODE

• на каждом реальном сервере также необходимо настроить обход проблемы ARP flux, чтобы избежать нежелательных ответов ARP:

  # e.g. in /etc/sysctl.conf
  net.ipv4.ip_nonlocal_bind=1
  net.ipv4.conf.eth0.arp_ignore = 1
  net.ipv4.conf.eth0.arp_announce = 2

  CODE
  

  Аналогичный результат может быть достигнут и с помощью команды arptables - если использование sysctl нежелательно.

Параметры контекстуализации статического реального сервера

Ниже перечислены параметры, определяющие статический реальный сервер, если не был настроен параметр ONEAPP_VNF_LB_CONFIG.

Использование динамических реальных серверов

Если для ПК СВ сконфигурирован сервис OneGate, то есть возможность динамически обновлять пул реальных серверов, используемый балансировщиком нагрузки.

При таком способе создаются ВМ, выполняющие специальную программу или скрипт, которые при начальной загрузке или при возникновении необходимости дадут команду VNF присоединить эту ВМ к пулу реальных серверов, используя переменные OneGate.

Переменные OneGate

Можно определить несколько балансировщиков нагрузки на каждой ВМ, для этого необходимо верно определить переменные с распределением их по IP-порту или IP-протоколу.

Индекс [0-9] не обязательно должно совпадать с индексом VNF, но он должно соответствовать набору параметров балансировщика нагрузки (IP, порт и протокол) или просто IP-адресу с балансировкой нагрузки, если для балансировщика не определены ни порт, ни протокол.

Пример настроек ВМ с переменными OneGate:

onegate vm update --data ONEGATE_LB0_IP=192.168.150.100
onegate vm update --data ONEGATE_LB0_PROTOCOL=TCP
onegate vm update --data ONEGATE_LB0_PORT=80
onegate vm update --data ONEGATE_LB0_SERVER_HOST=192.168.101.1
onegate vm update --data ONEGATE_LB0_SERVER_PORT=8080

В приведенном выше примере использован один индекс (0), чтобы определить этот единственный динамический реальный сервер и связать его с нужным балансировщиком нагрузки.