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 и что по одному хосту с каждой стороны отвечает. Затем запишите итоговые пары рядом с именами туннелей, чтобы следующая перестройка начиналась с проверенной таблицы, а не со сводки в консоли.