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