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