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: тестирајте услугу са правог извора
Дозволите предвиђени ток у AWS сигурносним групама и мрежним ACL-овима, у Azure NSG-овима и у било ком филтеру уређаја на путу. Затим отворите једну везу са 10.10.1.20 на одобрену адресу и порт услуге и потврдите да се одговор враћа на исти извор.
И сигурносне групе у облаку и NSG-ови су stateful, па је одбијени повратни пакет симптом усмеравања, а не правило које сте заборавили да напишете у обрнутом смеру.
Ping са било ког приступника ништа не решава. ICMP на адресу приступника вежба пут контролне равни, а не прослеђену TCP услугу која радном оптерећењу треба.
Враћање и записи
Забележите власнике рута уз идентификаторе тунела и сачувајте табеле рута пре промене. Ако промена мора да изађе, уклоните руте радног оптерећења пре рушења тунела, да ниједна подмрежа не остане усмерена на скок који више не постоји.
Касније премештање подмреже или прикључење spoke-а тада има једно дефинисано место за ажурирање, уместо тунела који ради и носи кривицу за руту коју никада није поседовао.