Серверы в другом VRF

• Проверено на версии — 2.2.1
• Требуется — изолированная сеть на VLAN, вторая изолированная сеть с серверами приложения

Клиенты приходят в одну изолированную сеть, а приложение живёт в другой — например, во внутреннем контуре, куда клиентам доступа быть не должно.

Балансировщик принимает соединение в первой сети и открывает новое во второй; прямой связности между сетями при этом не появляется. Значения — из сквозного примера.

Что получится

• VIP 10.88.0.100 будет принимать соединения в VRF demo.
• Балансировщик будет обращаться к серверу 10.89.0.200 из VRF tenant2.
• Узлы сети demo не получат доступа к сети tenant2: маршруты между VRF не добавляются.

Перед началом

• Профиль demo создан по сценарию Изолированная сеть на VLAN.
• Так же создан профиль tenant2 с сегментом на VLAN 301 и сетью 10.89.0.0/24.
• Сервер приложения 10.89.0.200 доступен в сети tenant2.

Настройка

Порядок важен: без политики конфигурацию балансировки создать не удастся.

1. Откройте раздел VRF, перейдите на вкладку Cross-VRF политики и нажмите Создать политику.
2. Заполните форму:
   • Из VRF — demo, то есть VRF, в котором находится VIP;
   • В VRF — tenant2, то есть VRF, в котором находятся серверы;
   • Режим политики — Через балансировщик (bridge).
3. Сохраните политику.
4. Создайте клиентский сервер 10.89.0.200 с VRF tenant2 и группу серверов с тем же VRF.
5. Создайте конфигурацию балансировки с VRF demo, VIP 10.88.0.100/32 и этой группой серверов.

Проверка

В интерфейсе системы

1. В группе серверов узлы перешли в состояние ОК: проверки доступности идут из VRF tenant2 и подтверждают, что путь к серверам есть.
2. На вкладке Cross-VRF политики пара demo → tenant2 присутствует с режимом bridge.
3. Обращение балансировщика к серверам видно инструментом TCP Dump на интерфейсе ens19.301: источником будет адрес агента в сети tenant2.

Трафиком

С узла сети demo обратитесь к VIP:

curl -sS -o /dev/null -w '%{http_code}\n' http://10.88.0.100:8080/

В журнале сервера приложения источником запроса будет 10.89.0.11 или 10.89.0.12 — адрес агента в сети tenant2. Это и означает, что соединение открыл балансировщик, а не клиент.

Изоляция проверяется с того же узла сети demo — напрямую до сервера приложения дойти не должно:

ping -c3 10.89.0.200

Частые ошибки

Другие сочетания

Тот же механизм связывает изолированную сеть с общей таблицей маршрутизации — в обе стороны. Меняются только концы политики, порядок шагов остаётся прежним.

Приложение в изолированной сети, клиенты — в общей. Балансировщик принимает соединения на адресе в общей сети, серверы скрыты в изолированной и снаружи недоступны.

1. Политика: Из VRF — default (global), В VRF — demo, режим Через балансировщик.
2. Клиентский сервер и группа серверов — с VRF demo.
3. Конфигурация балансировки — поле VRF оставьте пустым.

Балансировщик в изолированной сети, приложение — в общей. Обратный случай: сервис доступен только клиентам изолированной сети, а серверы приложения ещё не перенесены.

1. Политика: Из VRF — demo, В VRF — default (global), режим Через балансировщик.
2. Клиентский сервер и группа серверов — с VRF default (global).
3. Конфигурация балансировки — поле VRF со значением demo.

Дальше

• Выход из изолированной сети наружу — если нужна не связь через балансировщик, а маршрутизация между сетями.
• SNAT-группа в VRF — подмена адреса источника при обращении к серверам.