Site-to-Site VPN меѓу AWS и Azure: прво напишете ја повратната рута
Поврзан тунел меѓу два облака не докажува ништо додека секоја подмрежа на работното оптоварување не насочи кон далечниот префикс. Поминете го планот по ред, потоа тестирајте ја услугата.
Тунелот ќе се крене. Обично така се случува, бидејќи на IKE му требаат само совпаѓачки предлози и достапна адреса на партнерот. Она што потоа откажува е повратниот пат: работното оптоварување во AWS испраќа пакети во тунел, но ништо на страната на Azure не знае како да одговори на 10.10.0.0/16, или рутата на Azure постои во табела што подмрежата на работното оптоварување не ја користи. Напишете го планот за рути пред да допрете било која конзола и тунелот ќе стане најмалку интересниот дел од работата.
Чекор 1: замрзнете го планот за адреси
Работете со конкретни вредности. Работно оптоварување во AWS е на 10.10.1.20 внатре во 10.10.0.0/16 и бара TCP 443 кон услуга на Azure на 10.20.1.30 внатре во 10.20.0.0/16. Двата опсези не смеат да се преклопуваат, а тестот за прифаќање е парот услуги, не тунелот.
Запишете ги тие четири факти пред сè друго, бидејќи секој следен чекор се проверува против нив.
Чекор 2: именувајте го порталот што поседува секој крај
AWS Site-to-Site VPN може да заврши на виртуелен приватен портал или на транзитен портал, а тоа се различни сопственици на рутирањето. Azure нуди управуван VPN Gateway и, одделно, уреди базирани на VM што клиентите сами ги водат. Забележете кој пар го имате, бидејќи следниот скок се разликува во секоја комбинација.
За управуван портал, не копирајте рута што покажува на претпоставена адреса на приватен уред. За уред не претпоставувајте дека распространувањето рути во облакот го конфигурира гостувачкиот оперативен систем, бидејќи тоа не го прави.
Грешката тука дава план што изгледа целосен и испраќа пакети до адреса што никогаш не одговара.
Чекор 3: напишете ја рутата што секое работно оптоварување навистина ја користи
Секоја граница подолу е посебно барање, а рута во една од нив не е рута за пакетот. Пополнете ја табелата со свои вредности пред тунелот да стане активен.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
Во AWS, табелата со рути на подмрежата на работното оптоварување е ваша за ажурирање дури и откако BGP или тунелот ќе бидат здрави; прегледот на рутирањето го смета тоа за дел од врската. Во Azure, табелата со рути дефинирани од корисникот се поврзува со подмрежа наместо со виртуелната мрежа, затоа проверете ја ефективната рута на NIC на работното оптоварување, а не во панелот VNet.
Управуван портал на Azure може да го научи далечниот префикс преку распространување од порталот, а UDR може да ја надгласа таа одлука. Додадете UDR кога имате причина, не рефлексно. Ако додадете, насочете го кон следниот скок што порталот го објавува за патот на VPN, наместо да измислувате адреса на уред. Потоа прочитајте ги повторно ефективните рути на NIC, бидејќи одлуката навистина се носи таму.
Чекор 4: усогласете го опсегот
За BGP, споредете што објавува секоја страна со она што другата страна навистина го научила, префикс по префикс. За статичко рутирање, споредете ги конфигурираните далечни опсези со рутите на работното оптоварување што ги напишавте во чекор 3.
IKE врска што се согласува за криптографија не е доказ дека која било страна научила 10.10.0.0/16 или 10.20.0.0/16. Два тунели може да се кренати додека едната страна објавува еден /24 наместо /16 што сте го планирале. Проверете го префиксот во табелата со рутирање, не во статусот на тунелот. Несовпаѓањето подоцна се појавува како една подмрежа што работи и една што никогаш не одговара.
Чекор 5: тестирајте ја услугата од вистинскиот извор
Дозволете го предвидениот тек во безбедносните групи и мрежните ACL на AWS, во NSG на Azure и во секој филтер на уред на патот. Потоа отворете една врска од 10.10.1.20 кон одобрената адреса и порта на услугата и потврдете дека одговорот се враќа на истиот извор.
И безбедносните групи во облакот и NSG се со состојба, така што одбиен повратен пакет е симптом на рутирање, а не правило што сте заборавиле да го напишете во обратна насока.
Ping од кој било портал не решава ништо. ICMP кон адреса на портал го вежба патот на контролната рамнина, не препратената TCP услуга што му е потребна на работното оптоварување.
Враќање назад и записи
Забележете ги сопствениците на рути покрај идентификаторите на тунелот и зачувајте ги табелите со рути пред промената. Ако промената треба да се извади, отстранете ги рутите на работното оптоварување пред да го расклопите тунелот, за да не остане ниту една подмрежа насочена кон следен скок што повеќе не постои.
Тогаш подоцнежно преместување на подмрежа или поврзување spoke има едно определено место за ажурирање, наместо работен тунел што ја носи вината за рута што никогаш не ја поседувал.