Межі Cloud VPN, які не можна налаштувати: час життя IKE і NAT піра

Задайте віддаленому пристрою час життя фази 1 у 24 години, і тунель Cloud VPN залишиться лежати, хоча на боці Google усе налаштовано правильно. Пір пропонує значення, яке відповідач не прийме, тому узгодження або повністю провалюється, або перезапускається нескінченно. Cloud VPN обмежує фазу 1 значенням 36,000 секунд, тобто десятьма годинами, і цю межу не можна підняти налаштуванням. Зміна стосується віддаленого пристрою.

Пір питає, відповідач вирішує

IKE — це вправа зіставлення двох наборів пропозицій. Тунель утворюється лише там, де набори перетинаються в межах, які приймає відповідач, тому час життя поза діапазоном не дає навіть часткового тунелю. Звичайна помилка — ставитися до конфігурації піра як до списку побажань, а не як до пропозиції. Порожній перетин залишає тунель лежати, хоч би якою правильною була маршрутизація та селектори.

Прочитайте стан самого тунелю, перш ніж відкривати звернення, бо докладний статус зазвичай називає етап, який не вдався:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Порівняйте те, що повертається, з підтримуваним набором для вашого типу шлюзу й версії IKE і запишіть обидва селектори трафіку, поки ви там. Розбіжність селектора дає той самий симптом тунелю, що лежить, як і розбіжність алгоритму, і, на відміну від алгоритму, це вам виправляти.

36,000 секунд — це стеля

Фаза 1 зупиняється на 36,000 секундах. Пристрій, виставлений на 86,400, просить те, з чим відповідач ніколи не погодиться, і повторні спроби не змінюють його рішення. Поверніть віддалену пропозицію в діапазон, і та сама конфігурація встановиться; асиметрія — це весь урок, бо своє значення можна знизити, а значення Google підняти не можна.

Запишіть вибране значення в проєктні нотатки. Інакше наступний інженер повторить експеримент із 24 годинами і впреться в ту саму стіну.

Підтримуваний набір публікується для кожного типу шлюзу й версії IKE в огляді Cloud VPN, тож читайте розділ для своєї топології, а не загальний посібник з IKE.

Тунель, що падає за розкладом

Фаза 2 поводиться інакше: коли два кінці не домовляються, переузгодження ключів іде за коротшим інтервалом. Пір, який вважає розбіжність фатальною, натомість скидає тунель, тож одна розбіжність може виглядати як дві не пов'язані несправності. Стежте за ритмом переузгодження ключів, а не лише за першим підключенням. Тунель, який піднімається, а потім падає в регулярному такті, частіше є розбіжністю часу життя, ніж дефектом маршрутизації.

Зіставте ці позначки часу падінь із власними журналами піра, перш ніж щось змінювати, бо зміна селектора чи маршруту може імітувати той самий ритм. Якщо такт збігається з таймером фази 2, причину знайдено без втручання в пропозицію.

Набори походять від типу шлюзу

Набори шифрування й цілісності — це не профіль для кожного тунелю, який ви редагуєте, як дозволяє strongSwan. Ви обираєте їх за типом шлюзу й версією IKE, а пошук неіснуючого профілю марнує півдня.

Старий пристрій, який нічого не пропонує в межах підтримуваного набору, залишає два чесні шляхи: замінити пристрій або завершити на програмному шлюзі, яким ви керуєте, і звідти маршрутизувати у VPC. Усе інше — обхідний шлях, який провалиться на наступному огляді.

Одна зовнішня адреса на пристрій

Зовнішня адреса піра має відображатися один-до-одного на його внутрішню адресу. Перевантажений пул PAT працювати не може, бо кілька хостів за однією публічною адресою не дають відповідачеві жодного способу їх розділити. Там, де кілька хостів мають ділити адресу, тунель повинен закінчуватися в місці, яке може їх розрізнити.

Тримайте і цю зовнішню адресу стабільною. Перенесіть пристрій за інший NAT, і зв'язок розірветься, хоча кожна пропозиція все ще збігається. Варто записати, які значення належать Google, а які вам: час життя, набори й NAT один-до-одного фіксовані на їхньому боці, а пропозиції, селектори, маршрутизація й пріоритети BGP — ваші.