Site-to-Site VPN između AWS-a i Azurea: prvo napišite povratnu rutu
Povezan tunel između oblaka ne dokazuje ništa dok svaka podmreža radnog opterećenja ne usmjeri prema udaljenom prefiksu. Izvedite plan po redu, zatim testirajte servis.
Tunel će se podići. To se obično i dogodi, jer IKE traži samo podudarne prijedloge i dostupnu adresu partnera. Ono što poslije zakaže jest povratni put: radno opterećenje u AWS-u šalje pakete u tunel, ali ništa na strani Azurea ne zna kako odgovoriti na 10.10.0.0/16, ili ruta Azurea postoji u tablici koju podmreža radnog opterećenja ne koristi. Napišite plan ruta prije nego što dotaknete bilo koju konzolu i tunel će postati najmanje zanimljiv dio posla.
Korak 1: zamrznite plan adresa
Radite s konkretnim vrijednostima. Radno opterećenje u AWS-u nalazi se na 10.10.1.20 unutar 10.10.0.0/16 i treba TCP 443 prema servisu u Azureu na 10.20.1.30 unutar 10.20.0.0/16. Dva raspona ne smiju se preklapati, a prihvatni test je par servisa, ne tunel.
Zapišite te četiri činjenice prije svega ostalog, jer se svaki kasniji korak provjerava prema njima.
Korak 2: imenujte pristupnik koji posjeduje svaki kraj
AWS Site-to-Site VPN može završiti na virtualnom privatnom pristupniku ili na tranzitnom pristupniku, a to su različiti vlasnici usmjeravanja. Azure nudi upravljani VPN Gateway i, odvojeno, uređaje na bazi VM-a koje korisnici sami vode. Zabilježite koji par imate, jer se sljedeći skok razlikuje u svakoj kombinaciji.
Za upravljani pristupnik ne kopirajte rutu koja pokazuje na pretpostavljenu adresu privatnog uređaja. Za uređaj ne pretpostavljajte da širenje ruta u oblaku konfigurira gostujući operativni sistem, jer to ne čini.
Pogreška u tome daje plan koji izgleda potpun i usmjerava pakete na adresu koja nikada ne odgovara.
Korak 3: napišite rutu koju svako radno opterećenje stvarno koristi
Svaka granica ispod je zasebno traženje, a ruta u jednoj od njih nije ruta za paket. Popunite tablicu svojim vrijednostima prije nego tunel postane aktivan.
| 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 |
U AWS-u je tablica ruta podmreže radnog opterećenja vaša za ažuriranje čak i nakon što BGP ili tunel budu zdravi; pregled usmjeravanja to smatra dijelom veze. U Azureu se tablica ruta definiranih korisnikom povezuje s podmrežom, a ne s virtualnom mrežom, pa provjerite efektivnu rutu na NIC-u radnog opterećenja, a ne u oštrici VNet.
Upravljani pristupnik Azurea može naučiti udaljeni prefiks kroz širenje pristupnika, a UDR može nadjačati tu odluku. Dodajte UDR kada imate razlog, ne refleksno. Ako ga ipak dodate, usmjerite ga na sljedeći skok koji pristupnik objavljuje za VPN put, umjesto da izmišljate adresu uređaja. Zatim ponovno pročitajte efektivne rute na NIC-u, jer se odluka stvarno donosi tamo.
Korak 4: uskladite obuhvat
Za BGP uporedite šta svaka strana oglašava s onim što je druga strana stvarno naučila, prefiks po prefiks. Za statičko usmjeravanje uporedite konfigurirane udaljene raspone s rutama radnog opterećenja koje ste napisali u koraku 3.
IKE odnos koji se slaže oko kriptografije nije dokaz da je ijedna strana naučila 10.10.0.0/16 ili 10.20.0.0/16. Dva tunela mogu biti podignuta dok jedna strana oglašava jedan /24 umjesto /16 koji ste planirali. Provjerite prefiks u tablici ruta, ne u statusu tunela. Neusklađenost se kasnije pokaže kao jedna podmreža koja radi i jedna koja nikada ne odgovara.
Korak 5: testirajte servis s pravog izvora
Dozvolite predviđeni tok u AWS sigurnosnim grupama i mrežnim ACL-ovima, u Azure NSG-ovima i u bilo kojem filtru uređaja na putu. Zatim otvorite jednu vezu s 10.10.1.20 na odobrenu adresu i port servisa i potvrdite da se odgovor vraća na isti izvor.
I sigurnosne grupe u oblaku i NSG-ovi su stateful, pa je odbijeni povratni paket simptom usmjeravanja, a ne pravilo koje ste zaboravili napisati u obrnutom smjeru.
Ping s bilo kojeg pristupnika ništa ne rješava. ICMP na adresu pristupnika vježba put kontrolne ravnine, a ne proslijeđeni TCP servis koji radnom opterećenju treba.
Vraćanje i zapisi
Zabilježite vlasnike ruta uz identifikatore tunela i sačuvajte tablice ruta prije promjene. Ako promjena mora izaći, uklonite rute radnog opterećenja prije rušenja tunela, da nijedna podmreža ne ostane usmjerena na skok koji više ne postoji.
Kasnije premještanje podmreže ili priključivanje spoke-a tada ima jedno definirano mjesto za ažuriranje, umjesto tunela koji radi i nosi krivicu za rutu koju nikada nije posjedovao.