HA VPN ад Google да маршрутызатара Cisco: спачатку сплануйце рэсурс суседа
Назвіце абодва інтэрфейсы Google, рэсурс суседа, дамову IKEv2 і кожную сесію BGP, перш чым наладжваць маршрутызатар Cisco, затым выберыце аднаго суседа або двух.
Першае рашэнне ў HA VPN паміж Cisco і Google — не тое, які профіль шыфравання выкарыстоўваць, а тое, ці будуць тунэлі завяршаць адна лакальная прылада ці дзве. Шлюз HA VPN у Google мае два інтэрфейсы, і кожны чакае адпаведны тунэль суседа. Гэта дае два тунэлі незалежна ад таго, ці ёсць у вас два маршрутызатары, а розніца ў тым, ці можа адзін блок сілкавання або абнаўленне праграмнага забеспячэння абрынуць увесь праект.
Рашэнне: адна прылада суседа ці дзве
Выберыце схему з трох умоў: ці можаце вы дапусціць лакальную кропку адмовы, ці павінны выкарыстоўвацца абодва хмарныя інтэрфейсы і якую рэканвергенцыю цярпяць вашыя нагрузкі. Калі любая з трох з'яўляецца жорсткай патрабаваннем, дзве прылады суседа — гэта сумленны адказ.
Вырашыце гэта, перш чым адкрыць кансоль, бо адказ змяняе, колькі тунэляў і сесій BGP павінен апісаць аркуш.
Напішыце аркуш да любой каманды
У аркушы пяць радкоў, і кожнаму патрэбны ўладальнік:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
Знешні рэсурс суседа апісвае вашыя інтэрфейсы ўнутры Google Cloud, і яго стварэнне не наладжвае маршрутызатар Cisco. Гэтая асіметрыя здзіўляе тых, хто чакае, што хмарная кансоль будзе крыніцай праўды для абодвух бакоў. Гэта дэкларацыя таго, чаго Google павінен чакаць, і маршрутызатар усё яшчэ павінен ёй адпавядаць. Кіраўніцтва па суседнім шлюзе ад Google суадносіць гэтую дэкларацыю з працай над тунэлем, BGP, файрволам і IKE, якую вы ўсё яшчэ павінны зрабіць.
Калі ў радка няма ўладальніка, яго запоўніць той, хто будзе на змене падчас пераключэння.
Трымайце тры ролі адрасоў асобна
Публічныя адрасы суседа нясуць знешні абмен IPsec. Унутраная пара BGP належыць абароненаму лагічнаму злучэнню, якое працуе праз яго. Абвешчаныя прэфіксы LAN і VPC апісваюць нагрузкі за гэтым злучэннем. Капіраванне ўнутранага адраса віртуальнай машыны ў поле знешняга суседа змешвае першыя дзве ролі, і збой выглядае як праблема перамоў, а не як памылка ўводу даных.
Сплануйце два адпаведныя тунэлі суседа, па адным на кожны інтэрфейс HA VPN. Выкарыстанне абодвух хмарных інтэрфейсаў само па сабе не прыбірае лакальную кропку адмовы, бо абодва тунэлі ўсё яшчэ могуць апынуцца на адным шасі.
Запішыце ролю адраса побач з кожным значэннем у аркушы. Гэтая адна звычка прадухіляе большасць змешвання.
Перанясіце аркуш у рэліз Cisco
Пачніце з падтрыманай дакументацыі суседа або адпаведнага шаблона канфігурацыі Google для вашай платформы, затым узгадніце кожны запаўняльнік з аркушам. Праверце аўтэнтыфікацыю IKEv2, прапановы ESP, PFS і мадэль тунэля і маршрутызацыі разам, бо неадпаведнасць у адной з іх звычайна выглядае як неадпаведнасць у іншай. Выкарыстоўвайце фактычную платформу і рэліз праграмнага забеспячэння, каб выбраць падтрыманае, бо рэцэпт Classic VPN — гэта іншая адпраўная кропка.
Трымайце агульны сакрэт па-за здымкамі экрана, укладаннямі тыкетаў і нататкамі падтрымкі. Папярэдне агучаны ключ, устаўлены ў каментар да справы, — гэта раскрыццё ўліковых даных, а не артэфакт дыягностыкі.
Калі шаблон і аркуш супярэчаць, спыніцеся і вырашыце гэта на паперы. Прылада не будзе вырашаць за вас.
Прымайце кожны тунэль па яго ўласных доказах
HA VPN патрабуе сесій BGP, а паспяховыя перамовы IKE устанаўліваюць толькі першы этап. Унутраная сесія павінна ўзняцца, меркаваныя прэфіксы павінны быць абвешчаны і прыняты, а карысныя маршруты і дазволы файрвола павінны існаваць да таго, як пойдзе трафік нагрузак. Запіс усіх гэтых як аднаго зялёнага святла хавае, які этап насамрэч збоіць.
Запісвайце доказы прыёмкі для кожнага тунэля: узгодненыя асацыяцыі бяспекі, стан суседа BGP, чаканыя вывучаныя прэфіксы і меркаваны шлях нагрузкі. Затым праведзіце кантраляваную праверку збою і аднаўлення, бо тунэль, які ніколі не збоіць, — гэта тунэль, шлях аднаўлення якога не правераны.
Гэты запіс можна выкарыстаць паўторна пры наступнай змене дызайну, і ў гэтым розніца паміж узаемадзеяннем і фрагментам каманды, чые дапушчэнні страчаны.