У меня новая установка Google Cloud Platform. Он состоит из одной виртуальной машины (еще предстоит добавить) и VPN в другую сеть, где у меня есть 3 небольших подсети (две / 24 и одна / 32).
Когда я впервые настраивал VPN, я просто использовал / 32, и все было в порядке - соединение Google VPN установило соединение, с моей виртуальной машины я мог пропинговать IP-адрес / 32, и все было отлично.
На этой неделе мы попытались ввести в соединение / 24. Я вернулся к подключению Google VPN, добавил / 24 в диапазон IP-адресов удаленной сети, и здесь все пошло не так.
Журналы Google показывают, что ссылка пытается установить, но единственный способ открыть туннель - это попросить кого-то в одноранговой сети проверить мою виртуальную машину, соединение VPN показывает УСТАНОВЛЕННОЕ, а для подсети этот одноранговый блок затем доступен из моего ВМ - остальные подсети пока недоступны.
Иногда я замечал, что если я пингую из одноранговой сети в одной из других подсетей, эта подсеть станет доступной, а первая будет отключена (это не всегда происходит, и иногда одноранговый эхо-запрос к виртуальной машине по-прежнему не работает).
Сегодня вечером я установил с виртуальной машины два эхо-запроса на IP-адреса в разных подсетях / 24 одноранговых узлов. Я вижу, как связь переключается между / 24. Он не переключается быстро (я вижу, что подсеть A работала до ping seq 240, остановилась до seq 3370 и продолжала работать до seq 3660). Я не настраивал iTerm, чтобы разрешить неограниченную обратную прокрутку, поэтому я не вижу стабильности для подсети B, но из того факта, что подсеть B прошла более 1000 строк, я предполагаю, что она работает дольше, чем подсеть A.
Оба конца VPN уже пару раз перестраивались, и каждый раз проблема не исчезла. Я пропустил какой-то шаг здесь или есть настоящая проблема, которую нужно решить?
Если я перестрою VPN и просто разрешаю одну из / 24, проблема исчезнет, и все снова начнет работать.
Похоже, вы столкнулись с проблемой, описанной в vpn документация:
Сопоставления безопасности и несколько подсетей
Cloud VPN создает единую дочернюю ассоциацию безопасности (SA), объявляющую все блоки CIDR, связанные с туннелем. Некоторые одноранговые устройства IKEv2 поддерживают это поведение, а некоторые поддерживают только создание уникальной дочерней SA для каждого блока CIDR. С этими последними устройствами туннели с несколькими блоками CIDR могут не установиться.
Есть несколько способов решения этой проблемы:
Совсем недавно я столкнулся с той же проблемой, пытаясь подключиться к одноранговому узлу с двумя одиночными / 32 IP-адресами для удаленной сети. Мне удалось объединить 2 IP-адреса в один блок / 31 CIDR, и это сработало.
При этом с двумя / 24 и одним / 32 я не знаю, реально ли объединить их в один блок CIDR. Вы уже используете вариант 4 как обходной путь. Если вы используете IKEv1, запрещая что-либо с помощью Cloud Router (который недавно перешел с альфа-версии на бета-версию), это может быть настолько хорошо, насколько вы можете сейчас.