Architecture-center: Aclarar el uso de 'Permitir tráfico reenviado'

Creado en 11 dic. 2018  ·  6Comentarios  ·  Fuente: MicrosoftDocs/architecture-center

En la sección Emparejamiento de VNet, el documento establece:

También puede configurar los radios para usar la puerta de enlace de red virtual del concentrador para comunicarse con redes remotas. Para permitir que el tráfico de la puerta de enlace fluya del radio al concentrador y se conecte a redes remotas, debe:

  • Configure la conexión de emparejamiento de red virtual en el concentrador para permitir el tránsito de la puerta de enlace.
  • Configure la conexión de emparejamiento de red virtual en cada radio para usar puertas de enlace remotas.
  • Configure todas las conexiones de emparejamiento de red virtual para permitir el tráfico reenviado.

La tercera viñeta está mal. No se requiere 'Permitir tráfico reenviado' para transitar el tráfico a través de una puerta de enlace VPN (lo acabo de probar).

Creo que 'Permitir tráfico reenviado' solo es necesario en el escenario descrito en el párrafo anterior, donde el tráfico se enruta a través de un NVA en una arquitectura de radio central.

El documento debe aclararse para explicar correctamente el uso de "permitir tráfico reenviado" en cada escenario.


Detalles del documento

No edite esta sección.

Pri1 assigned-to-author doc-enhancement guidancsvc triaged

Comentario más útil

gracias por compartir estos comentarios @jtuliani y @evandropomatti , realmente apreciamos esto 😸

Creo que esto se refiere a la sección Emparejamiento de red virtual en Recomendaciones donde, según mi entendimiento, se están discutiendo dos escenarios diferentes.

Escenario A

Si necesita que los radios se conecten entre sí sin emparejarlos.

Para este escenario de caso, permítanos compartir lo siguiente de los documentos Create a peering :

_"Si esta casilla de verificación no está marcada para el emparejamiento entre cada red virtual radial y la red virtual central, el tráfico no fluye entre las redes virtuales radiales porque el concentrador no está reenviando el tráfico entre las redes virtuales"._

Adicionalmente,

_"No necesita marcar esta configuración si el tráfico se reenvía entre redes virtuales a través de Azure VPN Gateway"._

Escenario B

Configure los radios para usar la puerta de enlace del concentrador para comunicarse con redes remotas. Para esta configuración muy particular, no se requiere Permitir el tráfico reenviado .

Dicho esto, volvamos a abrir este problema, ya que al leer los documentos estoy de acuerdo en que es una buena idea hacer una distinción aquí.

Como parte de esta revisión, también consideremos indicar en qué emparejamiento se requieren realmente estas comprobaciones (es decir, Escenario B, se requiere [x] Use remote gateways del emparejamiento de centro radial, mientras que se requiere [x] Allow gateway transit del centro -spoke peering, y [] Allow forwarded traffic podría permanecer sin marcar para ambos) siempre que esa sea la preferencia del autor. Una vista de lado a lado de esto podría ser ideal.

Solo para concluir y con toda justicia, la configuración actual funcionará bien para ambos escenarios A + B, por lo que no están en conflicto entre sí. Dado eso, en aras de la simplicidad, es posible que deseemos mantener los ARM tal como están por ahora.

Todos 6 comentarios

Hola @jtuliani ¡ Gracias por informar este problema! Revisaremos y haremos los cambios necesarios.

+1, también agregaría que debemos tener en cuenta que al habilitar el tráfico reenviado en la red virtual, los usuarios deben tener en cuenta que las NIC de Azure también deben tener habilitado el reenvío (simplemente podemos vincularnos aquí ).

Pasé mucho tiempo tratando de averiguar por qué mis VM de Linux no podían comunicarse entre sí en redes virtuales emparejadas siguiendo esta guía hasta que me di cuenta de que había una configuración adicional en las NIC para habilitar también.

Muchas gracias: este elemento se ha movido a nuestra cartera de pedidos interna para mejorar la documentación.

@ doodlemania2, la documentación aún establece que se requiere "permitir tráfico reenviado". A juzgar por las pruebas de

Aquí respondiste que es obligatorio:
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment-506504344

¡Esta es una gran pregunta! Hacemos eso para que los pares puedan hablar entre sí mediante el enrutamiento a través del concentrador. Sin él, los paquetes se caerían al intentar salir del radio destinado al concentrador y viceversa. ¡Háganos saber si eso todavía no lo explica bien y podemos ver la nueva redacción!

¿Es de hecho requerido y su prueba fue algo incorrecta? ¿O la documentación necesita ser actualizada?

También puede configurar los radios para usar la puerta de enlace del concentrador para comunicarse con redes remotas. Para permitir que el tráfico de la puerta de enlace fluya del radio al concentrador y se conecte a redes remotas, debe:

  • Configure la conexión de emparejamiento en el concentrador para permitir el tránsito de la puerta de enlace .
  • Configure la conexión de emparejamiento en cada radio para usar puertas de enlace remotas .
  • Configure todas las conexiones de emparejamiento para permitir el tráfico reenviado .

También sugiero que no cerremos el tema aquí hasta que esté hecho. El proceso interno no le importa a la comunidad, de lo contrario nos encontramos con situaciones como esta.

gracias por compartir estos comentarios @jtuliani y @evandropomatti , realmente apreciamos esto 😸

Creo que esto se refiere a la sección Emparejamiento de red virtual en Recomendaciones donde, según mi entendimiento, se están discutiendo dos escenarios diferentes.

Escenario A

Si necesita que los radios se conecten entre sí sin emparejarlos.

Para este escenario de caso, permítanos compartir lo siguiente de los documentos Create a peering :

_"Si esta casilla de verificación no está marcada para el emparejamiento entre cada red virtual radial y la red virtual central, el tráfico no fluye entre las redes virtuales radiales porque el concentrador no está reenviando el tráfico entre las redes virtuales"._

Adicionalmente,

_"No necesita marcar esta configuración si el tráfico se reenvía entre redes virtuales a través de Azure VPN Gateway"._

Escenario B

Configure los radios para usar la puerta de enlace del concentrador para comunicarse con redes remotas. Para esta configuración muy particular, no se requiere Permitir el tráfico reenviado .

Dicho esto, volvamos a abrir este problema, ya que al leer los documentos estoy de acuerdo en que es una buena idea hacer una distinción aquí.

Como parte de esta revisión, también consideremos indicar en qué emparejamiento se requieren realmente estas comprobaciones (es decir, Escenario B, se requiere [x] Use remote gateways del emparejamiento de centro radial, mientras que se requiere [x] Allow gateway transit del centro -spoke peering, y [] Allow forwarded traffic podría permanecer sin marcar para ambos) siempre que esa sea la preferencia del autor. Una vista de lado a lado de esto podría ser ideal.

Solo para concluir y con toda justicia, la configuración actual funcionará bien para ambos escenarios A + B, por lo que no están en conflicto entre sí. Dado eso, en aras de la simplicidad, es posible que deseemos mantener los ARM tal como están por ahora.

@ferantivero Creo que lo

¿Fue útil esta página
0 / 5 - 0 calificaciones