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 usmeri prema udaljenom prefiksu. Prođite plan redom, zatim testirajte uslugu.
Tunel će se podići. To se obično i dogodi, jer IKE traži samo podudarne predloge i dostupnu adresu partnera. Ono što posle zakaže jest povratni put: radno opterećenje u AWS-u šalje pakete u tunel, ali ništa na strani Azurea ne zna kako da odgovori na 10.10.0.0/16, ili ruta Azurea postoji u tabeli koju podmreža radnog opterećenja ne koristi. Napišite plan ruta pre nego što dotaknete bilo koju konzolu i tunel će postati najmanje zanimljiv deo posla.
Korak 1: zamrznite plan adresa
Radite sa konkretnim vrednostima. Radno opterećenje u AWS-u nalazi se na 10.10.1.20 unutar 10.10.0.0/16 i treba TCP 443 ka usluzi u Azureu na 10.20.1.30 unutar 10.20.0.0/16. Dva opsega ne smeju da se preklapaju, a prihvatni test je par usluga, ne tunel.
Zapišite te četiri činjenice pre svega ostalog, jer se svaki kasniji korak proverava prema njima.
Korak 2: imenujte pristupnik koji poseduje svaki kraj
AWS Site-to-Site VPN može da završi na virtuelnom privatnom pristupniku ili na tranzitnom pristupniku, a to su različiti vlasnici usmeravanja. Azure nudi upravljani VPN Gateway i, odvojeno, uređaje na bazi VM-a koje korisnici sami vode. Zabeležite koji par imate, jer se sledeć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 konfiguriše gostujući operativni sistem, jer to ne čini.
Greška u tome daje plan koji izgleda potpun i usmerava 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 tabelu svojim vrednostima pre nego što 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 tabela ruta podmreže radnog opterećenja vaša za ažuriranje čak i nakon što BGP ili tunel budu zdravi; pregled usmeravanja to smatra delom veze. U Azureu se tabela ruta definisanih korisnikom povezuje sa podmrežom, a ne sa virtuelnom mrežom, pa proverite efektivnu rutu na NIC-u radnog opterećenja, a ne u oštrici VNet.
Upravljani pristupnik Azurea može da nauči udaljeni prefiks kroz širenje pristupnika, a UDR može da nadjača tu odluku. Dodajte UDR kada imate razlog, ne refleksno. Ako ga dodate, usmerite ga na sledeći skok koji pristupnik objavljuje za VPN put, umesto da izmišljate adresu uređaja. Zatim ponovo 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 sa onim što je druga strana stvarno naučila, prefiks po prefiks. Za statičko usmeravanje uporedite konfigurisane udaljene opsege sa rutama radnog opterećenja koje ste napisali u koraku 3.
IKE odnos koji se slaže oko kriptografije nije dokaz da je bilo koja 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 umesto /16 koji ste planirali. Proverite prefiks u tabeli 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 uslugu sa pravog izvora
Dozvolite predviđeni tok u AWS sigurnosnim grupama i mrežnim ACL-ovima, u Azure NSG-ovima i u bilo kom filtru uređaja na putu. Zatim otvorite jednu vezu sa 10.10.1.20 na odobrenu adresu i port usluge 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 usmeravanja, a ne pravilo koje ste zaboravili da napišete u obrnutom smeru.
Ping sa bilo kog pristupnika ništa ne rešava. ICMP na adresu pristupnika vežba put kontrolne ravni, a ne prosleđenu TCP uslugu koja radnom opterećenju treba.
Vraćanje i zapisi
Zabeležite vlasnike ruta uz identifikatore tunela i sačuvajte tabele ruta pre promene. Ako promena mora da izađe, uklonite rute radnog opterećenja pre rušenja tunela, da nijedna podmreža ne ostane usmerena na skok koji više ne postoji.
Kasnije premeštanje podmreže ili priključivanje spoke-a tada ima jedno definisano mesto za ažuriranje, umesto tunela koji radi i nosi krivicu za rutu koju nikada nije posedovao.