VPN de lloc a lloc entre AWS i Azure: escriviu primer la ruta de tornada
Un túnel connectat entre núvols no demostra res fins que cada subxarxa de càrrega encamina cap al prefix remot. Seguiu el pla per ordre i després proveu el servei.
El túnel s’aixecarà. Normalment ho fa, perquè IKE només necessita propostes coincidents i una adreça de parell accessible. El que falla després és el camí de tornada: la càrrega d’AWS envia paquets dins d’un túnel, però res a la banda d’Azure sap com respondre a 10.10.0.0/16, o la ruta d’Azure existeix en una taula que la subxarxa de càrrega no utilitza. Escriviu el pla de rutes abans de tocar qualsevol consola i el túnel esdevindrà la part menys interessant de la feina.
Pas 1: congeleu el pla d’adreces
Treballa amb valors concrets. Una càrrega d’AWS és a 10.10.1.20 dins de 10.10.0.0/16 i necessita TCP 443 cap a un servei d’Azure a 10.20.1.30 dins de 10.20.0.0/16. Els dos rangs no es poden solapar, i la prova d’acceptació és la parella de serveis, no el túnel.
Anota aquests quatre fets abans de qualsevol altra cosa, perquè cada pas posterior es comprova contra ells.
Pas 2: nomena la passarel·la que posseeix cada extrem
AWS Site-to-Site VPN pot acabar en una passarel·la privada virtual o en una passarel·la de trànsit, i són propietaris d’encaminament diferents. Azure ofereix la seva VPN Gateway gestionada i, a part, aparells basats en VM que els clients executen ells mateixos. Anota quina parella tens, perquè el següent salt és diferent en cada combinació.
Per a una passarel·la gestionada, no copiïs una ruta que apunti a una adreça suposada d’aparell privat. Per a un aparell, no assumeixis que la propagació de rutes al núvol configura el sistema operatiu convidat, perquè no ho fa.
Equivocar-te aquí produeix un pla que sembla complet i encamina paquets a una adreça que no respon mai.
Pas 3: escriviu la ruta que cada càrrega realment utilitza
Cada frontera de sota és una consulta separada, i una ruta en una d’elles no és una ruta per al paquet. Ompliu la taula amb els vostres valors abans que el túnel entri en servei.
| 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 |
A AWS, la taula de rutes de la subxarxa de càrrega és teva per actualitzar-la fins i tot després que BGP o un túnel estiguin sans; la visió general de l’encaminament ho considera part de la connexió. A Azure, una taula de rutes definides per l’usuari s’associa a una subxarxa en lloc d’enllaçar-se a la xarxa virtual, així que comprova la ruta efectiva a la NIC de la càrrega i no al full del VNet.
Una passarel·la d’Azure gestionada pot aprendre el prefix remot mitjançant la propagació de la passarel·la, i una UDR pot anul·lar aquesta decisió. Afegeix la UDR quan tinguis un motiu, no per reflex. Si l’afegeixes, apunta-la al següent salt que la passarel·la publica per al camí VPN en lloc d’inventar una adreça d’aparell. Després torna a llegir les rutes efectives a la NIC, perquè la NIC és on es pren realment la decisió.
Pas 4: reconcilieu l’abast
Per a BGP, compara què anuncia cada costat amb què ha après realment l’altre, prefix per prefix. Per a l’encaminament estàtic, compara els rangs remots configurats amb les rutes de càrrega que vas escriure al pas 3.
Una relació IKE que coincideix en criptografia no és prova que cap costat hagi après 10.10.0.0/16 o 10.20.0.0/16. Dos túnels poden estar aixecats mentre un costat anuncia un sol /24 en lloc del /16 que vas planificar. Comprova el prefix a la taula d’encaminament, no a l’estat del túnel. La discrepància apareix més tard com una subxarxa que funciona i una que no respon mai.
Pas 5: proveu el servei, des de la font real
Permet el flux previst als grups de seguretat i les ACL de xarxa d’AWS, als NSG d’Azure i a qualsevol filtre d’aparell del camí. Després obre una connexió des de 10.10.1.20 a l’adreça i el port aprovats del servei i confirma que la resposta torna a la mateixa font.
Tant els grups de seguretat del núvol com els NSG són stateful, així que un paquet de tornada denegat és un símptoma d’encaminament, no una regla que vas oblidar escriure en sentit invers.
Un ping des de qualsevol passarel·la no resol res. ICMP a l’adreça d’una passarel·la exercita el camí del pla de control, no el servei TCP reenviat que la càrrega necessita.
Revertiment i registres
Anota els propietaris de rutes al costat dels identificadors del túnel i conserva les taules de rutes anteriors al canvi. Si el canvi s’ha de retirar, elimina les rutes de càrrega abans d’enderrocar el túnel, perquè cap subxarxa quedi apuntant a un salt que ja no existeix.
Així, un trasllat posterior de subxarxa o una connexió spoke té un lloc definit on actualitzar, en lloc d’un túnel que funciona i carrega la culpa d’una ruta que mai no va posseir.