Site-to-Site VPN de AWS al Azure: unue skribu la revenan vojon
Konektita tunelo inter nuboj pruvas nenion ĝis ĉiu subreto de laborŝarĝo enkursigas al la fora prefikso. Trapasu la planon laŭorde, poste testu la servon.
La tunelo leviĝos. Ĝi kutime faras tion, ĉar IKE bezonas nur kongruajn proponojn kaj atingeblan samtulan adreson. Kio poste malsukcesas estas la reva vojo: la laborŝarĝo en AWS sendas pakaĵojn en tunelon, sed nenio ĉe la flanko de Azure scias kiel respondi al 10.10.0.0/16, aŭ la vojo de Azure ekzistas en tabelo, kiun la laborŝarĝa subreto ne uzas. Skribu la vojplanon antaŭ ol tuŝi iun ajn konzolon, kaj la tunelo fariĝos la malplej interesa parto de la laboro.
Paŝo 1: frostigu la adresplanon
Laboru kun konkretaj valoroj. Laborŝarĝo en AWS situas ĉe 10.10.1.20 ene de 10.10.0.0/16 kaj bezonas TCP 443 al Azure-servo ĉe 10.20.1.30 ene de 10.20.0.0/16. La du gamoj ne rajtas interkovri, kaj la akcepta testo estas la servoparo, ne la tunelo.
Skribu tiujn kvar faktojn antaŭ ĉio alia, ĉar ĉiu posta paŝo kontroliĝas kontraŭ ili.
Paŝo 2: nomu la pordegon, kiu posedas ĉiun finon
AWS Site-to-Site VPN povas finiĝi sur virtuala privata pordego aŭ sur traireja pordego, kaj tiuj estas malsamaj vojposedantoj. Azure ofertas sian administritan VPN Gateway kaj, aparte, VM-bazitajn aparatojn, kiujn klientoj mem funkciigas. Notu, kiun paron vi havas, ĉar la sekva salto diferencas en ĉiu kombinaĵo.
Por administrita pordego, ne kopiu vojon, kiu montras al supozita adreso de privata aparato. Por aparato, ne supozu, ke vojdisvastigo en la nubo agordas la gastan operaciumon, ĉar ĝi tion ne faras.
Erari ĉi tie produktas planon, kiu aspektas kompleta kaj sendas pakaĵojn al adreso, kiu neniam respondas.
Paŝo 3: skribu la vojon, kiun ĉiu laborŝarĝo vere uzas
Ĉiu limo sube estas aparta serĉo, kaj vojo en unu el ili ne estas vojo por la pakaĵo. Plenigu la tabelon per viaj propraj valoroj antaŭ ol la tunelo ekfunkcios.
| 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 |
En AWS, la vojaro de la laborŝarĝa subreto estas via por ĝisdatigi eĉ post kiam BGP aŭ tunelo estas sana; la superrigardo de enkursigado traktas tion kiel parton de la konekto. En Azure, uzant-difinita vojaro asociiĝas kun subreto anstataŭ ligiĝi al la virtuala reto, do kontrolu la efektivan vojon ĉe la NIC de la laborŝarĝo, ne en la VNet-klingo.
Administrita Azure-pordego povas lerni la foran prefikson per pordega disvastigo, kaj UDR povas superregi tiun decidon. Aldonu la UDR kiam vi havas kaŭzon, ne reflekseme. Se vi aldonas unu, direktu ĝin al la sekva salto, kiun la pordego publikigas por la VPN-vojo, anstataŭ elpensi aparatan adreson. Poste relegu la efektivajn vojojn ĉe la NIC, ĉar la decido efektive fariĝas tie.
Paŝo 4: harmonigu la amplekson
Por BGP, komparu tion, kion anoncas ĉiu flanko, kun tio, kion la alia flanko efektive lernis, prefikso post prefikso. Por statika enkursigado, komparu la agorditajn forajn gamojn kun la laborŝarĝaj vojoj, kiujn vi skribis en paŝo 3.
IKE-rilato, kiu interkonsentas pri kriptografio, ne pruvas, ke iu flanko lernis 10.10.0.0/16 aŭ 10.20.0.0/16. Du tuneloj povas esti levitaj dum unu flanko anoncas unu solan /24 anstataŭ la /16, kiun vi planis. Kontrolu la prefikson en la vojaro, ne en la tunela stato. La malkongruo montriĝas poste kiel unu funkcianta subreto kaj unu, kiu neniam respondas.
Paŝo 5: testu la servon el la reala fonto
Permesu la celitan fluon en la sekurecgrupoj kaj retaj ACL-oj de AWS, en la NSG-oj de Azure kaj en iu ajn aparata filtro sur la vojo. Poste malfermu unu konekton de 10.10.1.20 al la aprobita serva adreso kaj pordo kaj konfirmu, ke la respondo revenas al la sama fonto.
Kaj nubaj sekurecgrupoj kaj NSG-oj estas statohavaj, do rifuzita reva pakaĵo estas simptomo de enkursigado, ne regulo, kiun vi forgesis skribi inverse.
Ping de iu ajn pordego solvas nenion. ICMP al pordega adreso ekzercas la vojon de la rega ebeno, ne la plusenditan TCP-servon, kiun la laborŝarĝo bezonas.
Retroigo kaj registraĵoj
Registru la vojposedantojn apud la tunelaj identigiloj kaj konservu la vojarojn de antaŭ la ŝanĝo. Se la ŝanĝo devas esti forigita, forigu la laborŝarĝajn vojojn antaŭ ol malkonstrui la tunelon, por ke neniu subreto restu montranta al sekva salto, kiu jam ne ekzistas.
Posta subreta movo aŭ spoke-alkroĉo tiam havas unu difinitan lokon por ĝisdatigi, anstataŭ funkcianta tunelo, kiu portas la kulpon por vojo, kiun ĝi neniam posedis.