VPN site-to-site între AWS și Azure: scrieți mai întâi ruta de întoarcere
Un tunel conectat între două cloud-uri nu dovedește nimic până când fiecare subrețea de lucru nu rutează către prefixul îndepărtat. Parcurgeți planul în ordine și apoi testați serviciul.
Tunelul va urca. De obicei așa se întâmplă, pentru că IKE are nevoie doar de propuneri potrivite și de o adresă de peer accesibilă. Ce eșuează după aceea este calea de întoarcere: sarcina din AWS trimite pachete într-un tunel, dar nimic de partea Azure nu știe cum să răspundă la 10.10.0.0/16, sau ruta Azure există într-un tabel pe care subrețeaua sarcinii nu îl folosește. Scrieți planul de rute înainte de a atinge orice consolă, iar tunelul devine partea cea mai puțin interesantă a lucrării.
Pasul 1: înghețați planul de adrese
Lucrați cu valori concrete. O sarcină din AWS se află la 10.10.1.20 în 10.10.0.0/16 și are nevoie de TCP 443 către un serviciu Azure la 10.20.1.30 în 10.20.0.0/16. Cele două intervale nu trebuie să se suprapună, iar testul de acceptare este perechea de servicii, nu tunelul.
Notați aceste patru fapte înainte de orice altceva, pentru că fiecare pas ulterior este verificat față de ele.
Pasul 2: numiți gateway-ul care deține fiecare capăt
AWS Site-to-Site VPN poate termina pe un virtual private gateway sau pe un transit gateway, iar acestea sunt proprietari de rutare diferiți. Azure oferă VPN Gateway-ul administrat și, separat, dispozitive bazate pe VM pe care clienții le administrează singuri. Înregistrați ce pereche aveți, pentru că următorul salt diferă în fiecare combinație.
Pentru un gateway administrat, nu copiați o rută care indică o adresă presupusă de dispozitiv privat. Pentru un dispozitiv, nu presupuneți că propagarea rutelor în cloud configurează sistemul de operare invitat, pentru că nu o face.
O greșeală aici produce un plan care pare complet și trimite pachete către o adresă care nu răspunde niciodată.
Pasul 3: scrieți ruta pe care fiecare sarcină o folosește cu adevărat
Fiecare graniță de mai jos este o căutare separată, iar o rută într-una dintre ele nu este o rută pentru pachet. Completați tabelul cu propriile valori înainte ca tunelul să intre în funcțiune.
| 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 |
În AWS, tabelul de rute al subrețelei sarcinii este al dumneavoastră de actualizat chiar și după ce BGP sau tunelul sunt sănătoase; prezentarea generală a rutării consideră aceasta parte a conexiunii. În Azure, un tabel de rute definite de utilizator este asociat unei subrețele, nu rețelei virtuale, așa că verificați ruta efectivă pe NIC-ul sarcinii, nu în panoul VNet.
Un gateway Azure administrat poate învăța prefixul îndepărtat prin propagarea gateway-ului, iar un UDR poate anula acea decizie. Adăugați UDR când aveți un motiv, nu reflexiv. Dacă adăugați unul, îndreptați-l spre următorul salt pe care gateway-ul îl publică pentru calea VPN, în loc să inventați o adresă de dispozitiv. Apoi recitiți rutele efective pe NIC, pentru că acolo se ia de fapt decizia.
Pasul 4: reconciliați domeniul
Pentru BGP, comparați ce anunță fiecare parte cu ce a învățat efectiv cealaltă, prefix cu prefix. Pentru rutarea statică, comparați intervalele îndepărtate configurate cu rutele sarcinii scrise la pasul 3.
O relație IKE care este de acord asupra criptografiei nu este dovada că vreo parte a învățat 10.10.0.0/16 sau 10.20.0.0/16. Două tuneluri pot fi active în timp ce o parte anunță un singur /24 în locul /16 planificat. Verificați prefixul în tabelul de rutare, nu în starea tunelului. Neconcordanța apare mai târziu ca o subrețea care funcționează și una care nu răspunde niciodată.
Pasul 5: testați serviciul, din sursa reală
Permiteți fluxul dorit în grupurile de securitate și ACL-urile de rețea AWS, în NSG-urile Azure și în orice filtru de dispozitiv de pe cale. Apoi deschideți o conexiune de la 10.10.1.20 la adresa și portul aprobate ale serviciului și confirmați că răspunsul se întoarce la aceeași sursă.
Atât grupurile de securitate din cloud, cât și NSG-urile sunt stateful, așa că un pachet de retur refuzat este un simptom de rutare, nu o regulă pe care ați uitat să o scrieți invers.
Un ping din orice gateway nu decide nimic. ICMP către adresa unui gateway exersează calea planului de control, nu serviciul TCP forwardat de care are nevoie sarcina.
Revenire și înregistrări
Înregistrați proprietarii rutelor lângă identificatorii tunelului și păstrați tabelele de rute dinainte de modificare. Dacă modificarea trebuie retrasă, eliminați rutele sarcinii înainte de a demonta tunelul, ca nicio subrețea să nu rămână îndreptată spre un salt următor care nu mai există.
Astfel, o mutare ulterioară de subrețea sau o conectare spoke are un singur loc definit unde actualiza, în locul unui tunel funcțional care poartă vina pentru o rută pe care nu a deținut-o niciodată.