Architecture-center: '전달된 트래픽 허용'의 사용을 명확히 합니다.

안녕하세요 @jtuliani 이 문제를 신고해 주셔서 감사합니다! 검토하고 필요한 사항을 변경하겠습니다.

+1, VNet에서 전달된 트래픽을 활성화할 때 사용자는 Azure NIC도 전달을 활성화해야 한다는 점을 고려해야 합니다( 여기에 간단히 연결할 수 있음).

NIC에도 활성화할 추가 설정이 있다는 것을 깨달을 때까지 이 가이드에 따라 피어링된 VNet에서 Linux VM이 서로 연결할 수 없는 이유를 파악하는 데 많은 시간을 보냈습니다.

감사합니다. 이 항목은 문서 개선을 위해 내부 백로그로 이동되었습니다.

@doodlemania2 문서에는 여전히 "전달된 트래픽 허용"이 필요하다고 나와 있습니다. @jtuliani 테스트로 판단하면 그렇게 해서는 안 되며 문서를 변경해야 합니다.

여기에서 당신은 그것이 필요하다고 대답했습니다:
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment -506504344

이것은 좋은 질문입니다! 피어가 허브를 통한 라우팅을 통해 서로 통신할 수 있도록 그렇게 합니다. 이것이 없으면 패킷은 허브로 향하는 스포크를 종료하려고 시도할 때 드롭되며 그 반대의 경우도 마찬가지입니다. 그래도 잘 설명되지 않으면 알려주십시오. 다시 단어를 볼 수 있습니다!

그것은 실제로 필수이며 그의 테스트가 다소 잘못 되었습니까? 아니면 문서를 업데이트해야 합니까?

허브 게이트웨이를 사용하여 원격 네트워크와 통신하도록 스포크를 구성할 수도 있습니다. 게이트웨이 트래픽이 스포크에서 허브로 흐르도록 하고 원격 네트워크에 연결하려면 다음을 수행해야 합니다.

• 게이트웨이 전송 을
• 원격 게이트웨이 를 사용하도록 각 스포크의 피어링 연결을 구성합니다.
• 전달된 트래픽 을

또한 문제가 완료될 때까지 여기에서 문제를 닫지 않는 것이 좋습니다. 내부 프로세스는 커뮤니티에 중요하지 않습니다. 그렇지 않으면 이와 같은 상황이 발생합니다.

이 피드백을 공유해 주셔서 감사합니다 @jtuliani 및 @evandropomatti , 정말 감사합니다 😸

이것은 내 이해에 따라 두 가지 다른 시나리오가 논의되고 있는 권장 사항 아래의 가상 네트워크 피어링 섹션을 참조한다고 생각합니다.

시나리오 A

스포크를 피어링하지 않고 서로 연결해야 하는 경우.

이 사례 시나리오의 경우 피어링 만들기 문서에서 다음을 공유하도록 하십시오.

_"각 스포크 가상 네트워크와 허브 가상 네트워크 간의 피어링에 대해 이 확인란을 선택하지 않으면 허브가 가상 네트워크 간에 트래픽을 전달하지 않기 때문에 스포크 가상 네트워크 간에 트래픽이 흐르지 않습니다."_

추가적으로,

_"Azure VPN Gateway를 통해 가상 네트워크 간에 트래픽이 전달되는 경우 이 설정을 확인할 필요가 없습니다."_

시나리오 B

허브 게이트웨이를 사용하여 원격 네트워크와 통신하도록 스포크를 구성합니다. 이 특정 구성의 경우 전달된 트래픽 허용 이 필요하지 않습니다.

즉, 문서를 읽는 동안 여기에서 구별하는 것이 좋습니다.

이 수정의 일부로 이러한 검사가 실제로 필요한 피어링을 나타내는 것도 고려해 보겠습니다(예: 시나리오 B, [x] Use remote gateways 는 스포크 허브 피어링에서 필요하고 [x] Allow gateway transit 는 허브에서 필요) -spoke peering 및 [] Allow forwarded traffic 는 작성자의 기본 설정인 경우 둘 다 선택되지 않은 상태로 유지될 수 있습니다. 이것의 측면 보기가 이상적일 수 있습니다.

결론적으로 공정하게 말하면 현재 구성은 두 시나리오 A + B 모두에서 잘 작동하므로 서로 충돌하지 않습니다. 이를 감안할 때 단순성을 위해 ARM(들)을 현재 그대로 유지하기를 원할 수 있습니다.

@ferantivero 나는 당신이 그것을 못 박았고 우리는 지금 문제를 닫을 수 있다고 생각합니다.