Site-to-Site VPN med AWS in Azure: najprej napišite povratno pot
Povezan tunel med dvema oblakoma ne dokaže ničesar, dokler vsaka podomrežje delovne obremenitve ne usmeri na oddaljeno predpono. Izpeljite načrt po vrsti in nato preizkusite storitev.
Tunel se bo dvignil. Običajno se, ker IKE potrebuje le ujemajoče se predloge in dosegljiv naslov partnerja. Kar nato odpove, je povratna pot: delovna obremenitev v AWS pošilja pakete v tunel, a na strani Azure nihče ne ve, kako odgovoriti na 10.10.0.0/16, ali pa je pot Azure v tabeli, ki je podomrežje delovne obremenitve ne uporablja. Napišite načrt poti, preden se dotaknete katere koli konzole, in tunel bo postal najmanj zanimiv del dela.
Korak 1: zamrznite načrt naslovov
Delajte s konkretnimi vrednostmi. Delovna obremenitev v AWS je na 10.10.1.20 znotraj 10.10.0.0/16 in potrebuje TCP 443 do storitve Azure na 10.20.1.30 znotraj 10.20.0.0/16. Obsega se ne smeta prekrivati, sprejemni preizkus pa je par storitev, ne tunel.
Zapišite ta štiri dejstva pred vsem drugim, ker se vsak naslednji korak preverja proti njim.
Korak 2: poimenujte prehod, ki ima v lasti vsak konec
AWS Site-to-Site VPN se lahko konča na virtualnem zasebnem prehodu ali na tranzitnem prehodu, in to sta različna lastnika usmerjanja. Azure ponuja upravljani VPN Gateway in ločeno naprave na osnovi VM, ki jih stranke upravljajo same. Zabeležite, kateri par imate, ker se naslednji skok razlikuje v vsaki kombinaciji.
Za upravljani prehod ne kopirajte poti, ki kaže na domnevni naslov zasebne naprave. Za napravo ne predpostavljajte, da širjenje poti v oblaku konfigurira gostujoči operacijski sistem, ker tega ne počne.
Napaka tukaj da načrt, ki je videti popoln, in pošilja pakete na naslov, ki nikoli ne odgovori.
Korak 3: napišite pot, ki jo vsaka delovna obremenitev res uporablja
Vsaka meja spodaj je ločeno iskanje in pot v eni od njih ni pot za paket. Izpolnite tabelo z lastnimi vrednostmi, preden tunel zaživi.
| 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 |
V AWS je usmerjevalna tabela podomrežja delovne obremenitve vaša za posodabljanje tudi potem, ko sta BGP ali tunel zdrava; pregled usmerjanja to šteje za del povezave. V Azure se tabela uporabniško določenih poti poveže s podomrežjem in ne z virtualnim omrežjem, zato preverite dejansko pot na NIC delovne obremenitve in ne v rezini VNet.
Upravljani prehod Azure se lahko nauči oddaljene predpone s širjenjem prehoda, UDR pa lahko to odločitev preglasi. UDR dodajte, ko imate razlog, ne refleksno. Če ga dodate, ga usmerite na naslednji skok, ki ga prehod objavi za pot VPN, namesto da bi si izmislili naslov naprave. Nato znova preberite dejanske poti na NIC, ker se odločitev v resnici sprejme tam.
Korak 4: uskladite obseg
Za BGP primerjajte, kaj vsaka stran oglašuje, s tem, kar se je druga stran dejansko naučila, predpono za predpono. Za statično usmerjanje primerjajte konfigurirane oddaljene obsege s potmi delovne obremenitve, ki ste jih napisali v koraku 3.
Razmerje IKE, ki se strinja o kriptografiji, ni dokaz, da se je katera stran naučila 10.10.0.0/16 ali 10.20.0.0/16. Dva tunela sta lahko vzpostavljena, medtem ko ena stran oglašuje eno samo /24 namesto načrtovane /16. Preverite predpono v usmerjevalni tabeli, ne v stanju tunela. Neskladje se pozneje pokaže kot eno delujoče podomrežje in eno, ki nikoli ne odgovori.
Korak 5: preizkusite storitev iz pravega vira
Dovolite predvideni tok v varnostnih skupinah in omrežnih ACL AWS, v NSG Azure in v katerem koli filtru naprave na poti. Nato odprite eno povezavo z 10.10.1.20 na odobreni naslov in vrata storitve ter potrdite, da se odgovor vrne na isti vir.
Varnostne skupine v oblaku in NSG so stateful, zato je zavrnjen povratni paket simptom usmerjanja, ne pravilo, ki ste ga pozabili napisati v nasprotno smer.
Ping s katerega koli prehoda ne odloči ničesar. ICMP na naslov prehoda vadi pot krmilne ravnine, ne posredovane storitve TCP, ki jo delovna obremenitev potrebuje.
Povrnitev in zapisi
Zabeležite lastnike poti ob identifikatorjih tunela in shranite usmerjevalne tabele pred spremembo. Če je treba spremembo umakniti, odstranite poti delovne obremenitve, preden razstavite tunel, da nobeno podomrežje ne ostane kazati na naslednji skok, ki ne obstaja več.
Poznejša selitev podomrežja ali priklop spoke ima tako eno določeno mesto za posodobitev, namesto delujočega tunela, ki nosi krivdo za pot, ki je ni nikoli imel v lasti.