Адрасы BGP у Cloud VPN належаць усярэдзіне тунеля, а не на сеткавай карце

Адкрыйце старонку Cloud Router для VPN, і на вас глядзіць сесія BGP з адрасам у 169.254.0.0/16. Натуральная рэакцыя — змясціць гэты адрас недзе на VM і чакаць, пакуль сесія ўзнімецца. Гэтая рэакцыя памылковая цалкам канкрэтным чынам: пара належыць лагічным звяну, якое стварае тунель IPsec, а не звычайнаму сеткаваму інтэрфейсу машыны. Нішто з дададзенага на NIC не прымусіць тунель пераносіць BGP.

Прайдзіце за парай па стэку ўніз, а не дадавайце яе на хост.

Пачніце там, дзе кансоль паказвае пару

Старонка сесіі пералічвае адрас BGP Cloud Router і адрас партнёра, абодва link-local для IPv4 HA VPN. Побач з імі — знешнія адрасы шлюзаў, якія тэрмінуюць тунелі. Гэта розныя аб'екты: пара link-local жыве ўнутры, а адрасы шлюзаў жывуць звонку і павінны быць маршрутызаванымі, перш чым што-небудзь іншае запрацуе.

Запішыце ўсе тры, перш чым адкрываць файл канфігурацыі, бо іх блытаніна — гэта і ёсць увесь збой.

Спусціцеся да тунеля, які яе пераносіць

Пара link-local мае сэнс толькі тады, калі паміж двума шлюзамі існуе асацыяцыя бяспекі IPsec. На баку Google тунелі HA VPN ствараюць яе на двух інтэрфейсах; на вашым баку гэта тое, што ўзгадніў партнёр. Спачатку праверце асацыяцыю даных з дапамогай swanctl --list-sas і адзначце, які тунель узняты на якім інтэрфейсе, бо здаровая сесія BGP праз мёртвы тунель немагчымая, а мёртвы тунель са спагадлівай канфігурацыяй — звычайная справа.

Пакет BGP — гэта ўнутраны IP-трафік. Знешняя сетка яго ніколі не бачыць, таму ніводнаму камутатару не патрэбныя абодва адрасы ў адным VLAN.

Цяпер наладзьце Linux-партнёра адпаведна

Выберыце падтрыманы дызайн тунеля і дайце яму вызначыць унутраныя адрасы. З маршрутным інтэрфейсам запіс маршруту і ўзгодненыя селектары трафіку павінны супадаць, бо адно імя інтэрфейса нічога не дазваляе. Нацэльце BIRD на ўнутраны лакальны адрас і ўнутраны адрас Cloud Router, задайце нумары AS са старонкі сесіі і дазвольце TCP 179 унутры абароненага шляху. Трымайце маршрут да далёкага знешняга адраса на фізічным uplink, каб тунель не захопліваў уласны транспарт.

Тунель, які маршрутызуе сам сябе, — гэта пятля з рукапоціскам, і гадзіну ён будзе выглядаць як праблема з міжсетевым экранам.

Правярайце кожны этап па парадку, а не ўсё адразу

Прайдзіце этапы: асацыяцыя бяспекі ўзнята, унутраны партнёр дасягальны з адраса тунеля, сесія BGP усталявана, прэфіксы прыняты, затым прэфікс працоўнай нагрузкі сапраўды выкарыстаны. birdc show protocols адказвае на трэцяе пытанне і ні на што іншае, таму людзі абвяшчаюць перамогу занадта рана.

Усталяваны сусед не гарантуе, што абодва бакі абвясцілі патрэбныя вам прэфіксы або што гэтыя маршруты ўсталяваныя як пераважныя.

Калі сесія ўсталявана, а трафік усё яшчэ ідзе няправільным шляхам, параўнайце абвешчаныя прэфіксы з тым, што робіць з імі табліца маршрутызацыі. Больш канкрэтны маршрут у іншым месцы або перавага іншаму шляху даюць працоўную сесію BGP і ніякай карыснай перасылкі.

Спыніцеся, перш чым прымяняць гэта да Router Appliance

Network Connectivity Center Router Appliance — гэта іншая мадэль далучэння. Яго партнёры Cloud Router выкарыстоўваюць унутраныя адрасы з раскладкі VPC і падсеткі, а не пару link-local HA VPN. Калі сапраўдная мэта — BGP з маршрутнай VM, прытрымлівайцеся патрабаванняў інтэрфейсу гэтага прадукту, а не капіюйце сесію link-local.

Абсяг link-local па-ранейшаму азначае тое, што азначае. Лагічны тунель забяспечвае гэтую суседства, і ён не дазваляе маршрутызаваць адвольныя link-local прызначэнні праз VPC.