strongSwan vips: как запросить у IKEv2 виртуальный адрес

vips запрашивает внутренний адрес IKEv2; шлюз решает, что выдать. Настройте запрос, загрузите его, а затем проверьте, что именно назначил ответчик.

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

Что запрашивает vips и чего он не может обещать

vips принадлежит определению соединения и запрашивает у ответчика виртуальный адрес. Руководство strongSwan по виртуальным адресам прямо говорит, что ответом может быть другой адрес или ничего, и именно эту фразу пропускают, когда вписывают значение и ждут, что оно появится. Запрос всё же стоит сделать, потому что проверяете вы именно ответ. Относитесь к параметру как к указанию спросить, а не как к настройке результата.

Запрос 0.0.0.0 означает запрос любого доступного виртуального адреса IPv4, и это обычно правильно, когда точное значение не важно. Запрос конкретного адреса — подсказка шлюзу, а не требование к нему.

Фрагмент swanctl и где он находится

Параметр находится внутри блока соединения, не в отдельном файле и не в профиле операционной системы. Этот изолированный фрагмент показывает форму:

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

Загрузите его файлом, которому принадлежит соединение, затем запустите соединение и прочитайте результат. Фрагмент, вставленный не в тот раздел, даёт ошибку разбора или, что хуже, соединение, которое загружается без запроса, который вы, как вам казалось, сделали. Выполните три команды по порядку и сохраните вывод.

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts выбирает трафик, а не создаёт адрес

local_ts называет набор трафика, который защищает дочерний SA; он не помещает адрес на интерфейс. После согласования виртуального IP strongSwan перестаёт использовать свой стандартный динамический селектор и применяет выданный адрес. Если привязать селектор к буквальному адресу, вы утверждаете то, что шлюз мог и не выдать, и поэтому сбой выглядит как работающий SA с трафиком, который никуда не идёт. Селектор описывает трафик, а назначение приходит из другого обмена.

Другой способ получить стабильный внутренний адрес — владеть им локально. Поместите адрес на интерфейс до того, как поднимется туннель, направьте селектор на то, что уже существует, и упорядочьте партнёра и маршрут вокруг этого.

В такой схеме ничего не согласуется, поэтому ничего нельзя переназначить, и это и есть обмен: детерминизм в обмен на то, что адресацией вы занимаетесь сами. Это другой механизм, а не вариант vips, поэтому их не следует смешивать в одном соединении. Закреплённый селектор рядом с согласованным адресом — это соединение, которое работает, пока шлюз не выдаст что-то другое.

Проверьте, что именно назначил ответчик

Прочитайте список SA, чтобы найти адрес, выданный шлюзом, затем подтвердите, что адрес существует на интерфейсе. Если они не совпадают, туннель поднят, а трафик идёт не туда, куда вы думаете. Выданный адрес, который так и не доходит до интерфейса, — самый запутанный сбой в этой последовательности, потому что каждая половина по отдельности выглядит правильной.

Держите в заметках четыре адреса отдельно: запрошенный внутренний адрес, выданный, LAN-адрес машины и публичный выход, о котором сообщает какой-нибудь сайт. Они относятся к разным уровням и появляются в разных местах. Инструкция, в которой записаны все четыре, — это та, которой другой человек может следовать, не спрашивая, какой адрес вы имели в виду. Перечитывайте их после каждой перезагрузки, потому что выданное значение — единственное, которое описывает живой туннель.

Держите статическую схему отдельно

Если вам нужен фиксированный внутренний адрес, организуйте резервирование на шлюзе и оставьте запрос клиента запросом. Смешивание закреплённого селектора с согласованным адресом даёт соединение, которое работает, пока шлюз не назначит что-то другое. Запишите правило резервирования рядом с соединением, потому что это та часть, которую коллега не выведет из конфигурационного файла. Тогда новый клиент наследует правило, вместо того чтобы открывать его заново.

Во встроенном клиенте Mac ни одного из этих имён параметров не существует. Используйте любое назначение или резервирование, которое предлагает шлюз, и профиль, который публикует оператор, а любое значение на стороне клиента считайте подсказкой, пока не перечитаете назначение. Откат — это удаление строки vips и перезагрузка, что возвращает вас к тому, что шлюз назначает по умолчанию.

Похожие статьи