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 съседа, очаквани научени префикси и предвидения път на натоварването. След това направете контролирана проверка на отказ и възстановяване, защото тунел, който никога не се е провалял, е тунел с непроверен път за възстановяване.
Този запис може да се използва отново при следваща промяна на дизайна и това е разликата между взаимодействие и фрагмент от команда, чиито допускания са загубени.