Per què la connexió de punt a lloc necessita una passarel·la Azure VPN basada en rutes

Una passarel·la basada en polítiques construeix un túnel IPsec seleccionat pels selectors de trànsit i no té cap interfície a la qual lliurar les rutes dels clients. La connexió de punt a lloc és una funció d’encaminament: la passarel·la posseeix un conjunt d’adreces de client i instal·la rutes cap a aquests clients a la xarxa virtual. Aquesta discrepància és la raó per la qual el portal no mostra cap opció per afegir-la. Res de la passarel·la existent no es pot commutat per produir la interfície, de manera que el canvi és una substitució i no una edició de la configuració.

L’ordre importa més que els passos individuals. Si t’equivoques en la seqüència, la interrupció de lloc a lloc s’allargarà més enllà de la finestra de manteniment.

Què fa realment una passarel·la basada en polítiques

Una passarel·la basada en polítiques compara els paquets amb els selectors de trànsit configurats a la connexió i envia les coincidències a un sol túnel. No hi ha cap interfície de túnel amb adreça i no apareix cap ruta per client enlloc de la xarxa virtual. La taula de rutes simplement rep els prefixos locals que apunten a la passarel·la. Aquest model és suficient per a una connexió de lloc a lloc entre dos espais d’adreces fixos.

Una passarel·la basada en rutes funciona a l’inrevés: presenta una interfície de túnel i les rutes decideixen què hi entra. La connexió de punt a lloc, i qualsevol disseny el conjunt de parells del qual canvia, depèn que aquesta interfície existeixi.

Per què el conjunt de clients necessita aquesta interfície

Quan un portàtil es connecta, la passarel·la li assigna una adreça del conjunt de punt a lloc. Llavors la xarxa virtual necessita una ruta que digui que aquesta adreça és abastable a través de la passarel·la. Sense una interfície de túnel no hi ha res a què adjuntar aquesta ruta.

El conjunt prové d’un interval que tu designes, i la passarel·la assigna adreces d’allà. Si aquest interval se superposa amb la xarxa local o amb una xarxa virtual enllaçada, el conflicte només apareix després que es connecti un client, que és un mal moment per descobrir-lo. Reserva el conjunt abans que comenci la migració.

El tipus tampoc no és una configuració per connexió. Una passarel·la té un sol tipus, i cada connexió que manté es comporta en conseqüència, així que un disseny mixt necessita una segona passarel·la i no una segona connexió.

El tipus es fixa en crear-la

Microsoft afirma que una passarel·la de xarxa virtual no es pot canviar entre basada en polítiques i basada en rutes després del desplegament. No hi ha cap ordre de conversió ni cap commutador al portal. Crear una segona passarel·la a la mateixa subxarxa tampoc no és una solució alternativa, perquè Azure permet una passarel·la per xarxa virtual. Per tant, la migració és eliminar, reconstruir i tornar a connectar.

Això també incorpora la decisió d’SKU a la mateixa construcció. Passar a un SKU més gran més endavant és una altra substitució de passarel·la amb una altra interrupció.

Una passarel·la, una GatewaySubnet

La passarel·la viu en una subxarxa anomenada GatewaySubnet, i només una passarel·la l’ocupa. Dimensionar aquesta subxarxa forma part de la preparació, perquè un SKU més gran necessita més adreces i una subxarxa no es pot reduir després. Anota la configuració actual de lloc a lloc, la clau compartida, la passarel·la de xarxa local i les rutes efectives abans de tocar res. Després tracta la finestra com una interrupció, perquè el túnel de lloc a lloc queda aturat fins que es configura la connexió nova.

Un ordre de reconstrucció que manté la interrupció acotada: crea la passarel·la basada en rutes, torna a crear la connexió de lloc a lloc cap a la mateixa passarel·la de xarxa local, confirma el túnel i una petició d’equip a equip, i només llavors afegeix punt a lloc i genera un paquet de client nou.

Què no arregla la substitució

Un segon límit pertany al parell i no a Azure. Un dispositiu local basat en polítiques només pot arribar a la xarxa virtual a la qual es connecta, i no pot transitar cap a altres xarxes locals ni altres xarxes virtuals a través de la mateixa passarel·la. Substituir el costat d’Azure no canvia què pot seleccionar el parell.

Si el requisit és realment trànsit entre llocs, la resposta és un dispositiu parell basat en rutes o una topologia en què cada destinació acabi per separat. Decideix-ho abans de prometre una data, perquè la substitució de la passarel·la per si sola no ho lliurarà.

Ordre de les operacions i comprovacions

Verifica cada capacitat per separat. Primer l’estat del túnel de lloc a lloc i una petició d’equip a equip, després una connexió de punt a lloc i un recurs privat, després qualsevol camí de trànsit que el disseny afirmi. Un estat verd de la passarel·la només demostra que l’associació de seguretat s’ha aixecat, i res més. Mantén les comprovacions en aquest ordre perquè un error assenyali l’etapa que l’ha introduït.

Torna a generar els paquets de client després de qualsevol canvi de topologia i mantén el conjunt allunyat de cada interval local i enllaçat. Les restriccions i les diferències entre SKU es recullen a la referència de configuració d’Azure VPN Gateway.