AWS eta Azure arteko site-to-site VPN: idatzi itzulera-bidea lehenengo
Hodeien arteko tunel konektatuak ez du ezer frogatzen karga bakoitzaren azpisareak urruneko prefijora bideratzen ez duen arte. Egin plana hurrenez hurren, eta gero probatu zerbitzua.
Tunela altxatuko da. Normalean bai, IKEk proposamen bat datozenak eta peer-aren helbide irisgarri bat baino ez baititu behar. Geroago huts egiten duena itzulera-bidea da: AWSko kargak paketeak tunel batera bidaltzen ditu, baina Azure aldean inork ez daki 10.10.0.0/16ri nola erantzun, edo Azureko bidea kargaren azpisareak erabiltzen ez duen taula batean dago. Idatzi bide-plana edozein kontsola ukitu aurretik, eta tunela lanaren zatirik interesik gabeena bihurtuko da.
1. urratsa: izoztu helbide-plana
Egin lan balio zehatzekin. AWSko karga bat 10.10.1.20-n dago 10.10.0.0/16 barruan eta TCP 443 behar du 10.20.1.30-n dagoen Azure zerbitzu batera, 10.20.0.0/16 barruan. Bi tarteek ezin dute gainjarri, eta onarpen-proba zerbitzu-parea da, ez tunela.
Idatzi lau gertaera horiek beste edozer baino lehen, geroagoko urrats bakoitza haien aurka egiaztatzen baita.
2. urratsa: izendatu mutur bakoitzaren jabe den atebidea
AWS Site-to-Site VPN atebide pribatu birtualean edo transit atebidean amaitu daiteke, eta bideratze-jabe desberdinak dira. Azurek bere VPN Gateway kudeatua eskaintzen du eta, bereizita, bezeroek beren kabuz exekutatzen dituzten VM oinarriko gailuak. Erregistratu zein pare duzun, hurrengo jauzia desberdina baita konbinazio bakoitzean.
Atebide kudeatu baterako, ez kopiatu ustezko gailu pribatu baten helbidera doan biderik. Gailu baterako, ez suposatu hodeiko bide-propagazioak gonbidatuaren sistema eragilea konfiguratzen duenik, ez baitu egiten.
Hori gaizki egiteak osatuta dirudien plana sortzen du, eta inoiz erantzuten ez duen helbide batera bidaltzen ditu paketeak.
3. urratsa: idatzi karga bakoitzak benetan erabiltzen duen bidea
Beheko muga bakoitza bilaketa bereizia da, eta horietako bateko bidea ez da paketearen bidea. Bete taula zure balioekin tunela martxan jarri aurretik.
| 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 |
AWSm, kargaren azpisarearen bide-taula zurea da eguneratzeko, BGP edo tunela osasuntsu egon ondoren ere; bideratzearen ikuspegi orokorrak konexioaren parte dela dio. Azure-n, erabiltzaileak definitutako bide-taula azpisare batekin lotzen da, ez sare birtualarekin, beraz egiaztatu bide eraginkorra kargaren NICean, ez VNet orrian.
Azureko atebide kudeatu batek urruneko prefijoa atebide-propagazioaren bidez ikas dezake, eta UDR batek erabaki hori gaindi dezake. Gehitu UDR arrazoi bat duzunean, ez erreflexuz. Gehitzen baduzu, zuzendu atebideak VPN bidearentzat argitaratzen duen hurrengo jauzira, gailu-helbide bat asmatu beharrean. Gero irakurri berriro NICeko bide eraginkorrak, erabakia NICean hartzen baita benetan.
4. urratsa: adostu irismena
BGPren kasuan, alderatu alde bakoitzak iragartzen duena beste aldeak benetan ikasi duenarekin, prefijoz prefijo. Bideratze estatikoaren kasuan, alderatu konfiguratutako urruneko tarteak 3. urratsean idatzitako karga-bideekin.
Kriptografian ados dagoen IKE erlazio batek ez du frogatzen inongo aldek 10.10.0.0/16 edo 10.20.0.0/16 ikasi duenik. Bi tunel altxatuta egon daitezke alde batek planifikatu zenuen /16-aren ordez /24 bakarra iragartzen duen bitartean. Egiaztatu prefijoa bideratze-taulan, ez tunelaren egoeran. Desadostasuna geroago azaleratzen da funtzionatzen duen azpisare bat eta inoiz erantzuten ez duen beste bat bezala.
5. urratsa: probatu zerbitzua benetako iturritik
Baimendu aurreikusitako fluxua AWSko segurtasun-taldeetan eta sareko ACLetan, Azureko NSGetan eta bideko edozein gailu-iragazkitan. Gero ireki konexio bat 10.10.1.20-tik onartutako zerbitzuaren helbide eta portura, eta berretsi erantzuna iturri berera itzultzen dela.
Hodeiko segurtasun-taldeak eta NSGak egoeradunak dira, beraz ukatutako itzulera-paketea bideratze-sintoma da, ez alderantziz idaztea ahaztu zenuen araua.
Edozein atebidetatik egindako ping-ek ez du ezer erabakitzen. Atebide-helbide baterako ICMPk kontrol-planoaren bidea probatzen du, ez kargak behar duen birbidalitako TCP zerbitzua.
Atzera-egitea eta erregistroak
Erregistratu bide-jabeak tunelaren identifikatzaileen ondoan, eta gorde aldaketaren aurreko bide-taulak. Aldaketa kendu behar bada, kendu karga-bideak tunela eraitsi aurretik, inongo azpisare ez dadin existitzen ez den hurrengo jauzi batera seinalatuta geratu.
Orduan, geroagoko azpisare-mugimendu edo spoke konexio batek leku zehatz bat du eguneratzeko, inoiz izan ez zuen bide baten errua daraman tunel funtzionamendu baten ordez.