Site-to-Site VPN AWS-ist Azure’i: kirjuta kõigepealt tagasitee
Ühendatud pilvevaheline tunnel ei tõesta midagi enne, kui iga töökoormuse alamvõrk marsruudib kaugprefiksini. Käi plaan järjekorras läbi ja seejärel testi teenust.
Tunnel tõuseb. Tavaliselt tõusebki, sest IKE vajab ainult sobivaid ettepanekuid ja kättesaadavat partneri aadressi. Seejärel ebaõnnestub tagasitee: AWS-i töökoormus saadab paketid tunnelisse, aga Azure’i poolel ei tea keegi, kuidas 10.10.0.0/16-le vastata, või Azure’i marsruut asub tabelis, mida töökoormuse alamvõrk ei kasuta. Kirjuta marsruudiplaan enne, kui puudutad ükskõik millist konsooli, ja tunnelist saab töö kõige vähem huvitav osa.
Samm 1: külmuta aadressiplaan
Tööta konkreetsete väärtustega. AWS-i töökoormus asub 10.10.1.20 juures vahemikus 10.10.0.0/16 ja vajab TCP 443 Azure’i teenusesse 10.20.1.30 juures vahemikus 10.20.0.0/16. Kaks vahemikku ei tohi kattuda ja vastuvõtutest on teenusepaar, mitte tunnel.
Kirjuta need neli fakti enne kõike muud üles, sest iga järgnev samm kontrollitakse nende vastu.
Samm 2: nimeta lüüs, millele kuulub kumbki ots
AWS Site-to-Site VPN võib lõppeda virtuaalses privaatlüüsis või transiitlüüsis ja need on erinevad marsruudiomanikud. Azure pakub oma hallatavat VPN Gateway’d ja eraldi VM-põhiseid seadmeid, mida kliendid ise käitavad. Pane kirja, milline paar sul on, sest järgmine hüpe erineb igas kombinatsioonis.
Hallatava lüüsi puhul ära kopeeri marsruuti, mis osutab oletatavale privaatse seadme aadressile. Seadme puhul ära eelda, et pilve marsruudi levitamine seadistab külalisoperatsioonisüsteemi, sest see ei tee seda.
Sellega eksimine annab plaani, mis näeb täielik välja ja suunab paketid aadressile, mis ei vasta kunagi.
Samm 3: kirjuta marsruut, mida iga töökoormus tegelikult kasutab
Iga piir allpool on eraldi otsing ja marsruut ühes neist ei ole paketi marsruut. Täida tabel oma väärtustega enne, kui tunnel tööle läheb.
| 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-is on töökoormuse alamvõrgu marsruutitabel sinu uuendada ka siis, kui BGP või tunnel on terve; marsruutimise ülevaade peab seda ühenduse osaks. Azure’is seostatakse kasutaja määratud marsruutitabel alamvõrguga, mitte virtuaalvõrguga, seega kontrolli tegelikku marsruuti töökoormuse NIC-il, mitte VNeti blade’il.
Hallatav Azure’i lüüs võib kaugprefiksi õppida lüüsi levitamise kaudu ja UDR võib selle otsuse tühistada. Lisa UDR siis, kui sul on põhjus, mitte refleksina. Kui lisad, suuna see järgmisele hüppele, mille lüüs VPN-tee jaoks avaldab, mitte ära mõtle seadme aadressi välja. Seejärel loe tegelikud marsruudid NIC-il uuesti, sest otsus tehakse tegelikult seal.
Samm 4: vii ulatus kooskõlla
BGP puhul võrdle, mida kumbki pool kuulutab, sellega, mida teine pool tegelikult õppis, prefiks prefiksi haaval. Staatilise marsruutimise puhul võrdle seadistatud kaugvahemikke sammus 3 kirjutatud töökoormuse marsruutidega.
IKE suhe, mis lepib kokku krüptograafias, ei ole tõestus, et kumbki pool õppis 10.10.0.0/16 või 10.20.0.0/16. Kaks tunnelit võivad olla üleval, samal ajal kui üks pool kuulutab ühte /24 sinu kavandatud /16 asemel. Kontrolli prefiksi marsruutitabelis, mitte tunneli olekus. Lahtinevus ilmneb hiljem ühe töötava ja ühe mitte kunagi vastava alamvõrguna.
Samm 5: testi teenust tegelikust allikast
Luba kavandatud voog AWS-i turvagruppides ja võrgu-ACL-ides, Azure’i NSG-des ja igas tee peal olevas seadmefiltris. Seejärel ava üks ühendus 10.10.1.20-lt heakskiidetud teenuse aadressile ja pordile ning kinnita, et vastus tuleb tagasi samasse allikasse.
Nii pilve turvagrupid kui ka NSG-d on olekuga, seega tagasi lükatud vastusepakett on marsruutimise sümptom, mitte reegel, mille kirjutamise vastupidises suunas unustasid.
Ping ükskõik millisest lüüsist ei otsusta midagi. ICMP lüüsi aadressile harjutab juhtimistasandi teed, mitte edastatud TCP-teenust, mida töökoormus vajab.
Tagasipööramine ja kirjed
Märgi marsruudiomanikud tunneli identifikaatorite kõrvale ja hoia muudatuseelsed marsruutitabelid alles. Kui muudatus tuleb välja võtta, eemalda töökoormuse marsruudid enne tunneli lammutamist, et ükski alamvõrk ei jääks osutama järgmisele hüppele, mida enam ei ole.
Hilisemal alamvõrgu liigutamisel või spoke-ühendusel on siis üks kindel koht uuendamiseks, mitte töötav tunnel, mis kannab süüd marsruudi eest, mida ta kunagi ei omanud.