Azure Point-to-Site VPN 로그는 어디에 있을까? Monitor에서 확인하세요

사용자가 Point-to-Site 게이트웨이에 연결하지 못해 게이트웨이 블레이드를 열어도 페이지 어디에도 연결 기록이 없습니다. 구성, 인증서, 상태는 모두 있지만 기록은 없습니다. 로그는 존재하지만 네트워크 페이지가 생성하는 것이 아닙니다. 로그는 게이트웨이 리소스에 연결된 진단 설정에서 나오고 그 설정은 Monitor 아래에 있기 때문에, 뻔한 곳에서의 첫 검색은 아무것도 반환하지 않고 사람들은 서비스가 감사 기록을 남기지 않는다고 결론짓습니다.

뻔한 검색이 실패하는 이유

오래된 지침은 Azure Point-to-Site VPN에 감사가 없다고 말하며, 서비스가 연결별 기록을 노출하지 않던 시절에는 사실이었습니다. 현재 게이트웨이는 터널 진단 기록을 게시하므로 유용한 질문이 바뀌었습니다. 로그의 존재 여부가 아니라 어떤 리소스가 로그를 내보내고 어떤 범주를 켰는지입니다. 게이트웨이 블레이드는 구성 화면이며, 구성 화면이 로그 뷰어를 겸하는 경우는 드뭅니다. 진단 설정은 리소스별 개체이므로 선택한 리소스가 이후의 모든 것을 결정합니다.

혼란의 나머지 절반은 인증입니다. 인증서 기반 Point-to-Site 연결은 ID 공급자처럼 사용자별 로그인 이벤트를 생성하지 않으므로, 비밀번호를 입력한 특정인의 기록은 찾을 수 없습니다.

진단 설정을 게이트웨이 리소스에 연결하세요

Monitor를 연 다음 Diagnostic settings를 열고, 대상이 게이트웨이를 포함하는 가상 네트워크가 아니라 가상 네트워크 게이트웨이 자체인 새 설정을 추가합니다. P2SDiagnosticLog라는 이름의 Point-to-Site 진단 범주를 선택하세요. 클라이언트별 연결 기록을 담는 것이 바로 이것입니다. 터널, 경로 또는 IKE 범주는 그것들이 다루는 사이트 간 오류에만 추가합니다. 그다음 데이터를 직접 제어하는 Log Analytics 작업 영역으로 보내고, 보존 기간은 의도적으로 선택한 값을 사용합니다. 실패한 검색의 대부분은 기능 부재가 아니라 잘못된 리소스에 연결된 설정입니다.

범주 목록은 게이트웨이 유형과 세대에 따라 다릅니다. Point-to-Site 범주가 없으면 게이트웨이가 이 기능보다 오래되었거나 절대 내보내지 않는 SKU에서 실행 중일 수 있으므로, 권한 문제를 찾기 전에 지원되는 범주를 확인하세요. Point-to-Site 범주가 없는 게이트웨이는 고장 난 것이 아닙니다. 단지 해당 기록의 원천이 될 수 없을 뿐이며, 가장 가까운 대안은 터널 또는 IKE 범주입니다. 이는 Point-to-Site 세션을 설명하지는 않지만 클라이언트 주소를 기록합니다. 로그가 없다는 이유로 지원 사례를 열기 전에 범주 목록을 확인하세요.

사용 중인 모드의 테이블에서 기록 읽기

레거시 수집 모드에서는 항목이 AzureDiagnostics 테이블에 들어가고 범주가 열 값으로 표시되며, 리소스별 테이블에서는 게이트웨이에 자체 테이블이 있습니다. 어느 경우든 게이트웨이 리소스와 실패한 시도 전후의 시간 범위로 쿼리한 다음 개별 행이 아니라 상관 관계를 읽으세요:

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

열 집합은 수집 모드를 따르므로 쿼리를 스크립트가 아니라 형태로 다루세요. 찾아야 할 것은 나타났다가 사라지는 클라이언트 주소와 성공이 아닌 결과 유형입니다.

게이트웨이 기록을 클라이언트 측 관점과 맞추기

게이트웨이 로그는 터널을 설명하며, 노트북이 터널을 만들지 못한 이유를 설명하지 않습니다. 같은 타임스탬프에서 RAS 클라이언트의 Windows 이벤트 로그, macOS 연결 로그 또는 클라이언트 앱이 표시한 오류 텍스트로 클라이언트 측을 수집하세요. 일치하는 클라이언트 시도가 없는 게이트웨이 기록은 클라이언트를 가리키며, 클라이언트가 성공을 보고하는데 게이트웨이가 아무것도 기록하지 않는다면 보통 프로필이 다른 게이트웨이를 향하고 있다는 뜻입니다.

두 절반을 같은 티켓에 남기세요. 게이트웨이 로그만으로는 잘못된 결론을 부르고, 클라이언트 로그만으로는 패킷이 도착했는지 보여줄 수 없습니다.

어느 쪽에도 아무것도 나타나지 않으면 플랫폼을 의심하기 전에 클라이언트의 시계를 확인하세요. 어긋난 타임스탬프는 마치 데이터가 없는 것처럼 보이는 방식으로 상관 분석을 실패하게 만듭니다.

보존, 범위 및 runbook 항목

터널 기록에는 클라이언트 주소와 연결 타임스탬프가 포함되므로 플랫폼 기본값을 그대로 두지 말고 삭제 일정이 있는 개인 데이터로 취급하세요. 또한 시끄러운 작업 영역은 클라이언트 로그를 직접 읽는 것보다 상관 분석을 느리게 만들므로, 작업 영역이 구독의 모든 리소스에서 모든 범주를 수집하고 있지 않은지 확인하세요.

마지막으로 설정 이름, 작업 영역, 선택한 범주를 게이트웨이의 runbook에 적어 두세요. 다음에 클라이언트를 디버그할 사람은 먼저 게이트웨이 블레이드를 보고 아무것도 찾지 못한 뒤 로그가 없다고 결론지을 것입니다.