Hub y spokes

En el modelo hub-and-spoke el hub aloja lo que se comparte (firewall, puerta de enlace, DNS) y cada spoke aloja una carga. Cada spoke se empareja con el hub. Un peering conecta dos redes virtuales como si fueran una, con direcciones privadas, pero la relación no es transitiva: que la red A tenga peering con el hub y la red B también no hace que A llegue a B.

Para que dos spokes se vean hay dos caminos: un peering directo entre ellos (que se salta el hub y su firewall) o rutas definidas por el usuario que envíen el tráfico al firewall del hub, que lo reenvía. El segundo camino es el que permite inspeccionar el tráfico entre spokes, y por eso el primero, aunque funciona, es una decisión de diseño que hay que justificar por escrito.

Dos redes virtuales no pueden emparejarse si sus espacios de direcciones se solapan: el enrutamiento no sabría a cuál mandar un paquete. Por eso el plan de direcciones se escribe antes de crear la primera red, y se reserva un bloque por spoke. Un espacio dentro de otro también es solape. Para verlo, convierte cada bloque a su primera y su última dirección.

Abre el laboratorio. redes-virtuales.txt trae el espacio de direcciones de las cinco redes de Chaguaral. Una de ellas, la última que alguien añadió, pisa el espacio de la red de la planta.

Un peering existe en cada sentido: hay que crearlo en las dos redes. Su estado lo dice: Initiated cuando solo existe un lado, Connected cuando existen los dos y Disconnected cuando uno de los dos lados se borró después de haber estado conectado. En un peering desconectado el tráfico no pasa, y mientras no se recrea el lado que falta, no hay forma de que vuelva a pasar.

En peerings.json cada objeto es un sentido, con su nombre y su estado.

Un peering entre dos spokes funciona, y por eso es tentador: es rápido de crear y ahorra saltos. Pero ese tráfico no pasa por el firewall central, no se registra allí y no se filtra con sus reglas. En una revisión se cuentan estos atajos y se pregunta quién los pidió.

Cada objeto de peerings.json es un sentido, así que un atajo entre dos spokes aparece como dos objetos. Cuenta los objetos cuyo origen y destino son ambos spokes, es decir, ninguno es el hub.

Cada peering tiene cuatro opciones. allowVirtualNetworkAccess permite la comunicación normal entre las dos redes. allowForwardedTraffic admite el tráfico que no nace en la red remota, sino que un dispositivo (como el firewall del hub) reenvía en su nombre. allowGatewayTransit deja que la red use su puerta de enlace para las redes emparejadas, y useRemoteGateways hace que la otra red la utilice.

Para que el firewall del hub pueda reenviar el tráfico de un spoke hacia otro, el peering del spoke hacia el hub tiene que admitir el tráfico reenviado. Revisa en peerings.json los peerings que salen de un spoke hacia el hub.