Necessita una VNet d’Azure amb peering la seva pròpia passarel·la VPN?
Una VNet amb peering pot utilitzar la passarel·la VPN del hub amb un SKU compatible i un paràmetre en cada direcció del peering. Comproveu les rutes efectives, no l’estat del peering.
Apareix una VNet spoke nova, el hub ja té una passarel·la site-to-site en funcionament, i la pregunta òbvia és si cal pagar una segona passarel·la. Normalment no: el trànsit de passarel·la permet que la spoke consumeixi la passarel·la del hub a través del peering. Tres condicions decideixen si això funcionarà, i cap d’elles no es veu a la insígnia d’estat del peering. La connectivitat del peering i el permís per utilitzar la passarel·la d’algú altre són paràmetres separats, així que dues VM que ja es poden fer ping no proven res sobre el camí VPN.
Primera condició: la passarel·la, i la manca d’una a la spoke
Azure admet el trànsit de passarel·la per als SKU de VPN Gateway diferents de Basic, i tant el peering regional com el global poden transportar-lo. La spoke consumeix una passarel·la que no posseeix, així que no pot tenir-ne una de pròpia: si ja existeix una passarel·la a la spoke, o ja hi ha seleccionada una opció de passarel·la remota, el paràmetre de trànsit que voleu estarà indisponible o serà ineficaç. Comproveu-ho abans de depurar res, perquè la casella desactivada és el símptoma, no la fallada. Llegiu primer el SKU i la passarel·la existent, i després mireu els paràmetres del peering.
No suprimiu una passarel·la spoke existent per fer aparèixer l’opció fins que sapigueu què en depèn. L’ordre de migració importa més que la casella.
Segona condició: un paràmetre en cada direcció del peering
Un peering són dos objectes, un a cada VNet, i els paràmetres de trànsit viuen a costats diferents d’aquesta parella. El peering del hub cap a la spoke ha de permetre que la passarel·la del hub serveixi la spoke; el peering de la spoke cap al hub ha d’acceptar la passarel·la del hub. la guia de trànsit de passarel·la de Microsoft els anomena per direcció, que és l’única manera de mantenir-los correctes:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Un control etiquetat com a remote canvia de significat segons de quina VNet editeu el peering, així que llegiu la direcció, no la paraula. Definiu els dos costats, deseu i confirmeu que el peering informa de connexió als dos llocs.
Tercera condició: espai d’adreces i límits de permisos
El trànsit no pot fer que el mateix prefix de destinació signifiqui dues xarxes, així que els rangs del hub, de la spoke i de la xarxa local han de ser disjunts abans que res d’això funcioni. Les VNet també poden estar en subscripcions o inquilins diferents; això no és una prohibició, però la identitat que crea o actualitza cada peering necessita els permisos necessaris en aquella xarxa. Els canvis entre subscripcions sovint fallen per permisos, i l’error és fàcil de malinterpretar com un problema de topologia.
Anoteu els rangs i els propietaris abans del canvi. Endevinar qualsevol dels dos produeix un peering que connecta i no encamina res.
Verifiqueu amb rutes efectives, no amb l’estat del peering
Mireu les rutes efectives a la interfície de xarxa d’una càrrega de treball de la spoke i trobeu el prefix real de la xarxa local. Comproveu la taula de rutes de la subxarxa i si la propagació de rutes de passarel·la està desactivada, perquè una ruta definida per l’usuari o un dispositiu d’inspecció poden substituir el camí que suggereixen els indicadors del peering. Després confirmeu l’altra direcció: la xarxa local ha de saber com arribar al prefix de la spoke a través de la connexió site-to-site, ja sigui mitjançant anuncis apresos o mitjançant una ruta explícita i una entrada de xarxa protegida corresponent al dispositiu del client. Si falta el prefix en qualsevol dels dos costats, els indicadors del peering no són el que cal canviar.
Proveu un servei des d’una càrrega de treball de la spoke i seguiu la resposta. Una prova des de la passarel·la VPN o des d’una VM del hub exerceix un prefix d’origen i un camí diferents.
Si la topologia també serveix clients de punt a lloc, valideu les seves rutes instal·lades per separat. Els paquets de client de Windows poden necessitar regeneració després d’un canvi de topologia, i això és una tasca d’encaminament de client, no una prova que hagi fallat el fet de compartir la passarel·la.
Què no atorga compartir una passarel·la
El trànsit de passarel·la és una comoditat d’encaminament, no una autorització. Els grups de seguretat de xarxa, els filtres locals i les regles de nivell de servei encara decideixen a què pot arribar una càrrega de treball de la spoke, així que habiliteu el servei concret d’origen a destinació en lloc de suposar que el túnel compartit ho permet tot al darrere.
El peering tampoc no és transitiu tal com la gent espera. Afegir una altra spoke, o un punt de connexió privat, introdueix els seus propis requisits d’encaminament i accés que el paràmetre de trànsit existent no cobreix.