GCP HA VPN: сесія BGP застрягає на Waiting for peer, переплутана пара адрес
Сесія BGP у Cloud VPN, що зависла на Waiting for peer, зазвичай має переплутані адреси тунелю та партнера. Перевірте пару, перш ніж щось перебудовувати.
Сесія BGP, яка ніколи не досягає Established на тунелі Cloud VPN, зазвичай не є проблемою маршрутизації. Це проблема підключення: дві адреси, які мають дзеркально відповідати одна одній, введено в неправильному порядку, або пару першого тунелю повторно використано на другому. Сам тунель може бути цілком справним, поки сесія стоїть на Waiting for peer, бо IPsec і BGP це окремі переговори між тими самими двома кінцевими точками. Визначте, що саме з двох зламано, перш ніж щось перебудовувати.
Одне питання вирішує більшість випадків: чи бачить пристрій партнера адресу Cloud Router взагалі?
Стан тунелю і стан сесії це різні перевірки
Спочатку йдуть IKE та ESP. Якщо тунель не встановлено, ніщо всередині нього не має значення, і розмова про адресу BGP передчасна. Прочитайте стан і докладний стан тунелю, потім стан BGP-партнера маршрутизатора для того самого тунелю.
Тунель працює, а його BGP-партнер опущений, і це звужує несправність до сесії: адреса партнера, ASN або TCP 179, що надходить на внутрішню адресу. Тунель працює, сесія працює і досі немає маршрутів у VPC це третій випадок. Зміна адрес там не допоможе, бо сесія вже працює, а префікс просто не оголошується або не отримує переваги. Розділення цих трьох випадків це більша частина роботи.
Кожному тунелю потрібна власна /30 із заповненими обома кінцями
Кожен тунель HA VPN отримує link-local /30 з 169.254.0.0/16: одна адреса на інтерфейсі Cloud Router, інша на вашому партнері. Поле партнера має називати дальній кінець, ніколи не власну адресу маршрутизатора.
Два тунелі означають два інтерфейси на Cloud Router, кожен зі своєю /30. Повторне використання пари тунелю 0 на тунелі 1 це помилка, яка виглядає охайно у зведеній таблиці й умирає в пакеті OPEN.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
Читайте пару з ресурсу маршрутизатора, а не зі зведення в консолі. Зведення показує адресу партнера в стовпці, який легко прочитати неправильно, а ipRange інтерфейсу плюс peerIpAddress партнера мають описувати протилежні кінці однієї /30.
Перестановка зазвичай відбувається під час перебудови
Пари плутаються саме тоді, коли тунель перебудовують. Адресу партнера старого тунелю копіюють у поле інтерфейсу нового, або нову сесію спрямовують на партнера попередньої. У будь-якому разі Cloud Router надсилає пакети OPEN на адресу, яка тепер є ним самим, або на адресу, за якою немає тунелю.
Запишіть пари до відкриття консолі: ім'я тунелю, інтерфейс, адреса маршрутизатора, адреса партнера, ASN партнера. Потім створіть обидва тунелі за один прохід, щоб другий не заповнювався залишками першого.
Ще три причини, чому сесія чекає
Перша це ASN партнера: кожна сторона має бути налаштована з ASN іншої сторони, і розбіжність доходить до партнера, але з'єднання не встановлюється. Друга це власний міжмережевий екран партнера, який має дозволяти TCP 179 на інтерфейсі тунелю; правило IKE або ESP цього не покриває. Третя це партнер, що відповідає з іншої вихідної адреси, ніж та, що налаштована як його сусід.
Вирішальним є власний журнал партнера. Якщо в його зведенні BGP немає сусіда для цієї адреси, пакети не надходять, і пара або шлях неправильні. Якщо сусід перебуває в Active або Connect, пакети надходять, а параметри сесії не збігаються.
Перевіряйте в тому порядку, у якому йдуть пакети
Рухайтеся назовні: стан тунелю, потім стан BGP-партнера маршрутизатора, потім зведення BGP партнера, потім маршрути. Якщо перші два здорові, припиніть редагувати бік Cloud VPN і працюйте з пристроєм партнера. Якщо маршрутизатор повідомляє, що партнер опущений, а на вашому пристрої немає сусіда, пара неправильна або порт BGP фільтрується. Перехоплення пакетів на інтерфейсі тунелю партнера вирішує це з одного погляду, бо пакети OPEN або надходять туди, або не надходять ніколи.
gcloud compute routers get-status ROUTER --region=REGION друкує стан партнера поряд з адресою, яку він використовує, і це саме та пара, яку треба порівняти.
Після встановлення сесії переконайтеся, що вивчений префікс з'являється в таблиці маршрутів VPC і що по одному хосту з кожного боку відповідає. Потім запишіть остаточні пари поряд з іменами тунелів, щоб наступна перебудова починалася з перевіреної таблиці, а не зі зведення в консолі.