Azure S2S VPN 연결됨인데 트래픽 없음: IKE 로그 읽기

포털에는 Connected라고 표시되고 터널에는 가동 시간 카운터가 있으며 가상 머신에서 보낸 trace는 두 번째 홉에서 끊깁니다. 연결 상태가 설명하는 것은 IKE와 IPsec 협상이며, 어느 한쪽에서 패킷 하나가 정책 계층을 통과하는지는 아닙니다. 이런 티켓 대부분은 두 가지 결함으로 설명되고 둘 다 Azure 경로를 바꿔서는 고쳐지지 않습니다. 둘 다 게이트웨이가 만든 로그에 이미 적혀 있으므로 저는 경로 테이블이 아니라 그곳에서 시작합니다.

Connected가 실제로 보증하는 것

연결된 사이트 간 연결은 페이즈 1과 페이즈 2가 완료되었고 보안 연결이 살아 있다는 뜻입니다. 그것은 협상에 대한 진술입니다. 양쪽 피어가 제안에 합의하고 키를 교환하고 SA 쌍을 설치했습니다. 보호된다고 생각하는 서브넷과 트래픽 선택자가 일치하는지, 또는 복호화 후 상대가 패킷을 어딘가로 라우팅하는지에 대해서는 아무것도 말하지 않습니다. 터널은 몇 주 동안 살아 있으면서 흥미로운 흐름을 모두 버릴 수 있고, 바로 그 패턴이 사람들로 하여금 건강한 게이트웨이를 다시 만들게 합니다.

먼저 확인할 두 가지 결함은 ESP 대신 AH를 제안하는 피어와, 게이트웨이가 내부로 취급하지 않는 공간에 번호가 매겨진 가상 네트워크입니다.

경로를 건드리기 전에 내보낸 로그를 여십시오

포털에서 가상 네트워크 게이트웨이를 열고 연결에 대해 VPN troubleshoot 작업을 실행한 다음 생성된 번들을 내려받아 압축을 풉니다. 안에는 페이즈 1과 페이즈 2 교환이 담긴 IKE 로그가 있고 타임스탬프가 있으며 일반 텍스트로 읽을 수 있습니다. 위에서 아래로 읽지 말고 transform 줄을 검색하십시오. 흥미로운 항목은 보통 몇백 줄 안쪽에 있습니다. 포털에 접근할 수 없다면 진단 설정이 켜져 있을 때 같은 진단 정보가 게이트웨이의 로그 대상에 나타납니다.

두 항목이 가치의 대부분을 차지합니다. 첫 번째는 대략 expected ESP with combined authentication and cipher, received AH라고 적혀 있습니다. 두 번째는 IKE 교환 중의 invalid payload 오류로, 보통 잘못 구성되었거나 지원되지 않는 제안 필드를 뜻합니다.

둘 다 온프레미스 장비가 무엇을 제안했는지를 설명하므로 둘 다 피어 쪽 설정입니다. Azure 쪽을 다시 생성해도 방화벽이 보내는 제안은 바뀌지 않으며, 그래도 해보는 것이 이 작업에서 가장 흔히 낭비되는 한 시간입니다. 피어에서 페이즈 2를 결합 인증과 암호를 쓰는 ESP로 설정하고 알고리즘은 협상에 맡긴 다음, combined mode 같은 이름의 공급업체 체크박스가 그 아래에서 조용히 AH 제안을 선택하고 있지 않은지 확인하십시오.

가상 네트워크의 주소 공간을 확인하십시오

게이트웨이는 가상 네트워크가 사설 범위에 있기를 기대합니다. 공용 블록에 번호가 매겨진 네트워크, 예를 들어 111.x로 시작하는 네트워크는 터널을 올릴 수 있지만 Azure가 그 공간을 내부로 취급하지 않으므로 연결은 건강해 보이고 어떤 흐름도 허용되지 않습니다. 선택자에 반나절을 쓰기 전에 주소 공간을 확인하십시오. 그 번호가 오래된 할당에서 온 엄격한 요구 사항이라면 해결책은 다른 게이트웨이가 아니라 주소 계획의 변경입니다.

주소 공간 블레이드에 있는 동안 온프레미스 범위와의 중복을 기록하십시오. 중복되는 접두사는 클라이언트 쪽에서 비슷하게 보이는 다른 종류의 장애를 만듭니다.

양방향에서 접두사를 확인하십시오

로컬 네트워크 게이트웨이 리소스에는 온프레미스 접두사가 들어 있고, 그것은 원격 장비가 실제로 보호하는 서브넷과 일치해야 합니다. 장비가 버리는 주소를 포함하는 요약은 일부 흐름을 통과시키고 다른 흐름에서는 실패하며, 이는 구성 불일치가 아니라 간헐적인 라우팅 장애처럼 읽힙니다. 반대편도 확인하십시오. 한쪽 끝이 /16을 나열하고 다른 쪽이 그 안의 세 개 /24를 나열하는 것이 전형적인 부분 장애입니다. 어느 목록도 단독으로 권위가 없으므로 보이는 쪽을 믿지 말고 나란히 비교하십시오.

접두사 변경은 항상 저절로 반영되지 않으므로 연결 개체를 다시 저장하거나 다시 만들 계획을 세우고, 그다음 새 접두사가 양쪽에 나타나는지 확인하십시오.

ping이 아니라 경로를 시험하십시오

동작하는 터널과 동작하는 경로를 구분하는 trace는 이렇습니다. 첫 홉은 온프레미스 게이트웨이, 다음은 응답하지 않는 몇 개의 홉, 그다음 원격 호스트가 응답합니다. trace가 호스트에 닿지 않는다면 애플리케이션이 실제로 쓰는 TCP 포트를 시험하십시오. ICMP는 충분히 자주 필터링되어 실패한 ping이 증명하는 것이 거의 없습니다. 같은 trace를 원격 호스트에서 Azure의 가상 머신 쪽으로 실행하십시오. 두 결과의 비대칭이 돌아오는 경로의 누락이나 한 방향만 허용하는 규칙을 찾는 가장 빠른 방법입니다.

피어 제안, 두 주소 공간, 연결 생성 시각을 티켓에 적으십시오. 다음 엔지니어가 어떤 값을 다시 만들었고 어떤 값은 건드리지 않았는지 알 수 있도록 하기 위해서입니다.

로그가 비어서 돌아온다면 게이트웨이가 연결을 아예 종료하지 않을 수 있습니다. 로컬 네트워크 게이트웨이의 피어 주소가 로그를 읽는 장비와 일치하는지 확인하십시오. 같은 구독의 두 게이트웨이는 재구성 중에 혼동하기 쉽습니다. 그 실수는 하루를 잡아먹고 어떤 로그에도 흔적을 남기지 않습니다.