Google HA VPN кон 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 префикси ги опишуваат работните оптоварувања зад тоа поврзување. Копирањето на внатрешната адреса на VM во надворешното поле на партнерот ги меша првите две улоги, а отказот изгледа како проблем со преговарањето, а не како грешка при внесување податоци.
Испланирајте два соодветни тунели на партнерот, по еден за секој HA VPN интерфејс. Користењето на двата облачни интерфејси само по себе не ја отстранува локалната точка на отказ, бидејќи двата тунели сѐ уште можат да слетаат на истото куќиште.
Напишете ја улогата на адресата покрај секоја вредност во работниот лист. Таа една навика го спречува најголемиот дел од мешањето.
Преведете го работниот лист во Cisco издание
Започнете од поддржаната документација за партнерот или соодветен Google шаблон за конфигурација за вашата платформа, потоа усогласете го секој заменски елемент со работниот лист. Проверете ја IKEv2 автентикацијата, ESP предлозите, PFS и моделот на тунел и рутирање заедно, бидејќи несовпаѓање во еден од нив обично се појавува како несовпаѓање во друг. Користете ја вистинската платформа и издание на софтверот за да изберете што е поддржано, бидејќи рецептот Classic VPN е друга почетна точка.
Држете ја споделената тајна надвор од екрански слики, прилози на тикети и белешки за поддршка. Однапред споделен клуч залепен во коментар на случај е откривање на акредитиви, а не артефакт за решавање проблеми.
Ако шаблонот и работниот лист не се совпаѓаат, запрете и решете го на хартија. Уредот нема да арбитрира наместо вас.
Прифатете го секој тунел според сопствените докази
HA VPN бара BGP сесии, а успешното IKE преговарање воспоставува само првата фаза. Внатрешната сесија мора да се подигне, предвидените префикси мора да се најават и прифатат, а корисните рути и дозволите за огнен ѕид мора да постојат пред да се движи сообраќајот на работните оптоварувања. Евидентирањето на тоа како едно зелено светло крие која фаза всушност не успеала.
Забележете докази за прифаќање по тунел: преговарани безбедносни асоцијации, состојба на BGP сосед, очекувани научени префикси и предвидената патека на работното оптоварување. Потоа изведете контролирана проверка на отказ и обновување, бидејќи тунел што никогаш не откажал е тунел чија патека за обновување не е тестирана.
Тој запис е повторно употреблив следниот пат кога ќе се смени дизајнот и тоа е разликата меѓу интероперабилноста и дел од команда чии претпоставки се изгубени.