Architecture-center: Esclarecer o uso de 'Permitir tráfego encaminhado'

Olá @jtuliani Obrigado por relatar este problema! Analisaremos e faremos as alterações necessárias.

+1, eu também acrescentaria que devemos observar que, ao habilitar o tráfego encaminhado na VNet, os usuários precisam considerar que as NICs do Azure também precisam ter o encaminhamento habilitado (podemos simplesmente vincular aqui ).

Passei muito tempo tentando descobrir por que minhas VMs do Linux não conseguiam se conectar em VNets emparelhadas seguindo este guia até perceber que havia uma configuração extra nas NICs para habilitar também.

Muito obrigado - este item foi movido para nosso backlog interno para refinamento da documentação.

@doodlemania2 a documentação ainda afirma que "permitir tráfego encaminhado" é necessário. A julgar pelo teste do @jtuliani , não deveria, e a documentação deveria ser alterada.

Aqui você respondeu que é obrigatório:
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment -506504344

Esta é uma grande pergunta! Fazemos isso para que os peers possam conversar entre si por meio de roteamento pelo hub. Sem ele, os pacotes cairiam quando tentassem sair do spoke destinado ao hub e vice-versa. Deixe-nos saber se isso ainda não explica bem e podemos olhar para a reformulação!

É de fato necessário e seu teste estava um pouco incorreto? Ou a documentação precisa ser atualizada?

Você também pode configurar spokes para usar o gateway de hub para se comunicar com redes remotas. Para permitir que o tráfego do gateway flua do spoke para o hub e se conecte a redes remotas, você deve:

• Configure a conexão de emparelhamento no hub para permitir o trânsito do gateway .
• Configure a conexão de peering em cada spoke para usar gateways remotos .
• Configure todas as conexões de peering para permitir o tráfego encaminhado .

Também sugiro que não encerremos a questão aqui até que ela seja concluída. O processo interno não importa para a comunidade, caso contrário, apenas nos deparamos com situações como essa.

obrigado por compartilhar este feedback @jtuliani e @evandropomatti , nós realmente apreciamos isso 😸

Acho que isso se refere à seção Virtual Network Peering em Recomendações, onde, com base no meu entendimento, dois cenários diferentes estão sendo discutidos.

Cenário A

Se você precisar que os spokes se conectem uns aos outros sem emparelhá-los.

Para este cenário de caso, por favor, deixe-nos compartilhar dos documentos Criar um emparelhamento o seguinte:

_"Se esta caixa de seleção não estiver marcada para o emparelhamento entre cada rede virtual spoke e a rede virtual hub, o tráfego não fluirá entre as redes virtuais spoke porque o hub não está encaminhando o tráfego entre as redes virtuais."_

Adicionalmente,

_"Você não precisa verificar essa configuração se o tráfego for encaminhado entre redes virtuais por meio de um Gateway de VPN do Azure."_

Cenário B

Configure os spokes para usar o gateway do hub para se comunicar com redes remotas. Para esta configuração muito particular, Permitir tráfego encaminhado não é necessário.

Dito isto, por favor, vamos reabrir este problema, pois concordo ao ler os documentos que é uma boa ideia fazer uma distinção aqui.

Como parte desta revisão, consideremos também indicar em qual peering essas verificações são realmente necessárias (ou seja, Cenário B, [x] Use remote gateways é necessário do peering do spoke-hub, enquanto [x] Allow gateway transit é necessário do hub -spoke peering, e [] Allow forwarded traffic pode permanecer desmarcado para ambos) desde que seja a preferência do autor. Uma visão lado a lado disso pode ser o ideal.

Apenas para concluir e com toda a justiça, a configuração atual funcionará bem para ambos os cenários A + B, para que eles não entrem em conflito. Dado isso, por uma questão de simplicidade, podemos querer manter o(s) ARM(s) como está por enquanto.

@ferantiro Acho que você