Azure P2S VPN의 반환 트래픽이 한 방향으로만 동작하는 이유

터널 아이콘은 녹색이고 NSG도 허용하는 것처럼 보이며 유효 경로도 올바르게 보이는데, VM은 여전히 연결된 클라이언트로 돌아가는 연결을 열지 못합니다. 흔한 가정은 정상 동작하는 point-to-site 터널이 대칭적이라는 것입니다. 클라이언트가 VM에 닿으면 VM도 클라이언트에 닿아야 한다는 것입니다. 그 가정이 바로 구성의 문제가 아니라 추론의 오류입니다. 터널은 요청되지 않은 흐름의 한 방향만 전달하고 다른 방향은 버릴 수 있으며, 수정은 어느 계층이 그것을 버리는지에 달려 있습니다.

오해: 연결된 터널은 양방향 터널이다

VPN 터널은 케이블이 아니라 정책 경로입니다. 각 방향은 선택자, 경로, 필터와 대조되며, 그중 어느 것이든 한 방향을 허용하면서 다른 방향을 차단할 수 있습니다.

실제로 비대칭은 흔하기 때문에 방향은 마지막이 아니라 첫 번째 테스트에 들어가야 합니다. 클라이언트가 시작하고 게이트웨이가 흐름을 추적하며 응답은 생성된 상태를 따릅니다. 새 흐름을 시작하는 VM에는 그런 상태가 없으므로 반환 경로가 명시적으로 라우팅 가능하고 허용되어야 합니다. 그 경로가 없으면 연결 시도는 어떤 애플리케이션도 보기 전에 실패합니다.

연결 가능성을 테스트하기 전에 방향을 테스트하십시오

클라이언트 주소 하나, VM 주소 하나, 프로토콜 하나를 고릅니다. 클라이언트에서 연결하고 결과를 기록한 다음, 같은 테스트를 VM에서 시작해 그것도 기록합니다. 첫 번째가 성공하고 두 번째가 실패하면 클라이언트 풀, 게이트웨이 연결, 클라이언트에서 VNet으로 가는 경로가 모두 동작하는 것입니다.

다음 단계는 규칙을 더하는 것이 아니라 증거를 모으는 것입니다. VM 서브넷의 NSG를 양방향으로 확인하고, VM NIC의 유효 경로를 읽고, 클라이언트가 트래픽을 보내는 동안 VM에서 패킷을 캡처하십시오. 응답 없이 도착하는 요청은 필터나 반환 경로 문제이고, 전혀 도착하지 않는 요청은 경로 문제입니다. 실패한 ping을 VM에 도달할 수 없다는 증거로 삼지 마십시오. TCP가 동작하는 동안에도 ICMP 정책이 응답을 버릴 수 있습니다.

IKEv2 point-to-site 반환 경로가 흔한 용의자입니다

이 글의 배경이 된 Azure 보고서에서 클라이언트는 IKEv2로 VM에 도달했지만, 게이트웨이 터널 유형을 OpenVPN으로 전환할 때까지 VM에서 클라이언트로 가는 인바운드 ICMP가 실패했습니다. 보고자는 Microsoft가 IKEv2 point-to-site 경로의 한계를 확인했다고 밝힙니다. 클라이언트가 세션을 시작하지 않으면 VM에서 클라이언트로 가는 반환 트래픽이 대칭적으로 라우팅되지 않는다는 것입니다. IKEv2는 트래픽 선택자에 의존하며, 그 경우 게이트웨이는 반환 방향을 존중하지 않았습니다.

그렇다고 OpenVPN이 일반적으로 더 나은 터널 유형이 되는 것은 아닙니다. 이 워크로드의 테스트 매트릭스에서 터널 유형이 변수가 된다는 뜻입니다.

터널 유형 전환은 서비스 변경이지 스위치가 아닙니다. 모든 클라이언트에 호환되는 프로필이 필요하고 게이트웨이에는 다른 인증서나 인증 설정이 필요할 수 있습니다. 테스트 클라이언트 하나와 테스트 VM 하나로 단방향 동작을 재현하고, 승인된 일정에 따라 유형을 바꾼 뒤 같은 방향 테스트를 반복하십시오. 전환 후에도 동작이 남는다면 터널 유형이 원인이 아니었고, 프로덕션을 건드리지 않고 문제를 좁힌 것입니다.

오해: 브로드캐스트 검색은 VNet 경계를 넘는다

두 번째 가정은 무관한 이유로 틀립니다. Azure 가상 네트워크는 브로드캐스트 트래픽을 전달하지 않으므로 VM은 site-to-site 또는 point-to-site 연결을 통해 온프레미스 네트워크에서 브로드캐스트 프레임을 받을 수 없습니다. 오래된 파일 탐색이나 일부 장치 검색 프로토콜처럼 브로드캐스트로 피어를 찾는 애플리케이션은 경로를 어떻게 작성하든 원격 측을 절대 보지 못합니다.

브로드캐스트 검색을 DNS 이름, 디렉터리 서비스 또는 명시적 피어 목록으로 대체하십시오. 애플리케이션에 유니캐스트 대안이 없다면 설계에는 더 넓은 터널이 아니라 다른 검색 메커니즘이 필요합니다.

무엇을 바꾸고 어떻게 증명할 것인가

방향 테스트가 IKEv2에서만 실패하면 게이트웨이 터널 유형, 클라이언트 주소 풀, 정확한 ICMP 또는 TCP 테스트를 기록하고, 영향을 받는 클라이언트에 대해 승인된 OpenVPN 프로필을 검토하십시오. 모든 터널 유형에서 실패하면 반환 경로를 다루십시오. 클라이언트 주소는 VM 서브넷에서 라우팅 가능해야 하고, 사용자 정의 경로는 유효한 다음 홉을 가리켜야 하며, 클라이언트 방화벽이 인바운드 흐름을 받아들여야 합니다. NSG와 경로 증거를 티켓에 첨부하십시오.

ping이 아니라 애플리케이션으로 검증하십시오. 변경 후 성공한 ICMP 교환은 서비스 포트, 인증, 이름 확인에 대해 아무것도 알려주지 않습니다. 재연결 후 테스트를 반복하십시오. 풀에서 다른 주소를 받은 클라이언트는 결과를 바꿀 수 있습니다. 그런 다음 클라이언트가 잠들었다 깨어난 뒤 한 번 더 반복하십시오. 재개된 세션에서 단방향 동작이 자주 다시 나타나기 때문입니다.