Site-to-Site VPN starp AWS un Azure: vispirms uzrakstiet atgriešanās maršrutu
Savienots starp-mākoņu tunelis neko nepierāda, kamēr katra darba slodzes apakštīkla nevirza uz attālo prefiksu. Izpildiet plānu secībā un pēc tam pārbaudiet pakalpojumu.
Tunelis pacelsies. Parasti tā arī notiek, jo IKE nepieciešami tikai atbilstoši priekšlikumi un sasniedzama partnera adrese. Kas pēc tam neizdodas, ir atgriešanās ceļš: AWS darba slodze sūta paketes tunelī, bet Azure pusē neviens nezina, kā atbildēt uz 10.10.0.0/16, vai arī Azure maršruts atrodas tabulā, kuru darba slodzes apakštīkls neizmanto. Uzrakstiet maršrutu plānu, pirms pieskaraties jebkurai konsolei, un tunelis kļūs par vismazāk interesanto darba daļu.
1. solis: iesaldējiet adrešu plānu
Strādājiet ar konkrētām vērtībām. AWS darba slodze atrodas 10.10.1.20 iekš 10.10.0.0/16 un tai nepieciešams TCP 443 uz Azure pakalpojumu 10.20.1.30 iekš 10.20.0.0/16. Abiem diapazoniem nevajadzētu pārklāties, un pieņemšanas tests ir pakalpojumu pāris, nevis tunelis.
Pierakstiet šos četrus faktus pirms visa cita, jo katrs nākamais solis tiek pārbaudīts pret tiem.
2. solis: nosauciet vārteju, kurai pieder katrs gals
AWS Site-to-Site VPN var beigties virtuālajā privātajā vārtejā vai tranzīta vārtejā, un tie ir dažādi maršrutēšanas īpašnieki. Azure piedāvā savu pārvaldīto VPN Gateway un atsevišķi VM balstītas ierīces, ko klienti uztur paši. Pierakstiet, kurš pāris jums ir, jo nākamais lēciens katrā kombinācijā atšķiras.
Pārvaldītai vārtejai nekopējiet maršrutu, kas norāda uz minētu privātas ierīces adresi. Ierīcei nepieņemiet, ka maršrutu izplatīšana mākonī konfigurē viesa operētājsistēmu, jo tā to nedara.
Kļūda šeit rada plānu, kas izskatās pilnīgs un sūta paketes uz adresi, kas nekad neatbild.
3. solis: uzrakstiet maršrutu, ko katra darba slodze patiešām izmanto
Katra robeža zemāk ir atsevišķa meklēšana, un maršruts vienā no tām nav maršruts paketei. Aizpildiet tabulu ar savām vērtībām, pirms tunelis sāk darboties.
| 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 darba slodzes apakštīkla maršrutu tabula ir jāatjaunina jums, arī pēc tam, kad BGP vai tunelis ir vesels; maršrutēšanas pārskats to uzskata par savienojuma daļu. Azure lietotāja definētā maršrutu tabula tiek saistīta ar apakštīklu, nevis virtuālo tīklu, tāpēc pārbaudiet efektīvo maršrutu darba slodzes NIC, nevis VNet panelī.
Pārvaldītā Azure vārteja var apgūt attālo prefiksu ar vārtejas izplatīšanu, un UDR var šo lēmumu atcelt. Pievienojiet UDR, kad jums ir iemesls, nevis refleksīvi. Ja pievienojat, vērsiet to uz nākamo lēcienu, ko vārteja publicē VPN ceļam, nevis izdomājiet ierīces adresi. Pēc tam vēlreiz izlasiet efektīvos maršrutus NIC, jo lēmums patiešām tiek pieņemts tur.
4. solis: saskaņojiet apjomu
BGP gadījumā salīdziniet, ko katra puse reklamē, ar to, ko otra puse faktiski iemācījās, prefikss pret prefiksu. Statiskajai maršrutēšanai salīdziniet konfigurētos attālos diapazonus ar 3. solī uzrakstītajiem darba slodzes maršrutiem.
IKE attiecības, kas vienojas par kriptogrāfiju, nav pierādījums, ka kāda puse ir iemācījusies 10.10.0.0/16 vai 10.20.0.0/16. Divi tuneļi var būt uzcelti, kamēr viena puse reklamē vienu /24 plānotā /16 vietā. Pārbaudiet prefiksu maršrutu tabulā, nevis tuneļa statusā. Neatbilstība vēlāk parādās kā viens strādājošs un viens nekad neatbildošs apakštīkls.
5. solis: pārbaudiet pakalpojumu no īstā avota
Atļaujiet paredzēto plūsmu AWS drošības grupās un tīkla ACL, Azure NSG un jebkurā ierīces filtrā ceļā. Pēc tam atveriet vienu savienojumu no 10.10.1.20 uz apstiprināto pakalpojuma adresi un portu un apstipriniet, ka atbilde atgriežas tajā pašā avotā.
Gan mākoņa drošības grupas, gan NSG ir ar stāvokli, tāpēc noraidīta atgriešanās pakete ir maršrutēšanas simptoms, nevis noteikums, ko aizmirsāt uzrakstīt pretējā virzienā.
Ping no jebkuras vārtejas neko neizšķir. ICMP uz vārtejas adresi trenē vadības plaknes ceļu, nevis pārsūtīto TCP pakalpojumu, kas darba slodzei nepieciešams.
Atritināšana un ieraksti
Pierakstiet maršrutu īpašniekus blakus tuneļa identifikatoriem un saglabājiet maršrutu tabulas pirms izmaiņām. Ja izmaiņas ir jāizņem, noņemiet darba slodzes maršrutus pirms tuneļa nojaukšanas, lai neviens apakštīkls nepaliktu norādīts uz nākamo lēcienu, kas vairs neeksistē.
Tad vēlākai apakštīkla pārvietošanai vai spoke pievienošanai ir viena noteikta vieta, kur atjaunināt, nevis strādājošs tunelis, kas nes vainu par maršrutu, kas tam nekad nav piederējis.