IKE의 MAC 불일치는 공유 키 검사가 실패했다는 뜻입니다
IKEv2 사전 공유 키 로그에서 MAC은 메시지 인증 코드입니다. 검사가 무엇을 비교하는지, 그리고 실제로 이를 일으키는 두 가지 구성 오류를 설명합니다.
Cloud VPN 로그에 공유 키 시도 뒤에 MAC mismatched가 표시되면, 첫 반응은 대개 주소 문제를 찾는 것입니다. 이 분기에서 MAC은 메시지 인증 코드이며, 협상된 키로 수행한 교환 전체에 대해 계산한 값입니다. 피어는 자신의 계산을 수신한 값과 비교했고, 두 값은 달랐습니다. 여기에는 네트워크 카드가 관여하지 않으며, 어떤 인터페이스 설정도 그 비교를 바꾸지 않습니다.
실제로 두 조건이 이를 만듭니다. 양쪽 끝의 비밀이 같은 값이 아니거나 비밀을 선택하는 ID가 서로 대응하지 않는 경우인데, 어느 쪽인지는 단일 터널이 아니라 쌍을 읽어 판단하십시오.
이 단계가 증명하는 것
검사는 양쪽이 초기 매개변수를 교환하고 자신을 식별한 뒤 실행됩니다. 로컬 및 원격 ID에 대한 후보 공유 키를 선택하고 수신한 인증 데이터를 검증하려 시도하며, 어느 것도 검증되지 않으면 진단이 출력됩니다. 이는 인증에 대한 강한 진술이지만 원인에 대해서는 약한 진술인데, 어느 쪽이 잘못되었는지 말하지 않기 때문입니다.
이전의 성공은 이 검사로 이어지지 않습니다. 완료된 IKE_SA_INIT이나 예상 값을 반환한 NAT 검색 페이로드는 피어가 통신할 수 있음을 증명합니다. 비밀을 공유하는지에 대해서는 아무것도 증명하지 않습니다.
두 가지 구성 오류, 하나의 메시지
첫 번째는 실제 비밀 불일치이며 보통 프로비저닝 사고, 즉 생성된 값을 한 콘솔에 설치하고 다른 콘솔에서 다시 입력했거나 한쪽에 끝 문자가 남았거나 붙여넣기와 함께 따옴표가 들어온 경우입니다. 두 번째는 ID 불일치로, 비밀은 맞지만 피어가 제시하는 ID가 다른 항목을 선택하므로 올바른 비밀이 시도되지 않습니다. 둘 다 같은 줄을 만들기 때문에 추측에는 반나절이 걸립니다.
어떤 비밀이든 건드리기 전에 터널, 피어 끝점, 시간 창, 원격 구성을 일치시켜 쌍을 비교하십시오. 중복 터널 두 개가 서로 다른 비밀을 가질 수 있고, 눈앞의 화면이 실패한 것이 아닐 수 있습니다.
NAT 검색은 다른 단계입니다
NAT 검색은 패킷이 어떻게 다시 쓰이는지를 묻지, 피어가 누구인지를 묻지 않습니다. NAT 뒤의 고객 게이트웨이는 구성된 ID가 피어가 기대하는 것이면 여전히 올바르게 인증되며, NAT 문제는 인증 비교 실패가 아니라 제안이나 포트 불일치로 나타납니다.
한 공급업체 릴리스에 관한 오래된 서술을 현재 배포로 가져오지 마십시오. 해당 릴리스에서 NAT 통과가 요구하는 것은 그 릴리스 자체 문서에 속하며, MAC mismatch라는 문구는 그에 대한 찬반 증거가 아닙니다.
화면이 아니라 쌍에서 결정하십시오
비밀을 가린 채 두 구성을 나란히 읽고 세 가지 질문을 하십시오. 각 쪽의 ID가 상대가 기대하는 것과 문자 단위로 정확히 일치합니까? 양쪽 끝이 같은 IKE 버전과 같은 인증 방법을 사용합니까? 실패하는 터널이 읽고 있는 구성에 해당합니까? 어느 하나라도 '아니요'이면 비밀을 건드리지 않고 수리 방법이 결정됩니다.
세 가지가 모두 깨끗하면 주변을 편집하는 대신 승인된 워크플로로 비밀을 교체하십시오.
피어가 인증한 후
인증이 성공하면 다음 실패 표면은 자식 보안 연결의 제안과 트래픽 선택자입니다. 이미 수락된 비밀을 회전해도 자식 실패는 고쳐지지 않으며 중단이 길어집니다. 자식 상태를 읽고, 다음으로 양쪽의 선택자와 보호 범위를 읽고, Cloud VPN 문제 해결 지침을 실제로 실패한 단계에 맞추십시오.
양쪽 끝의 새 로그를 연관시키십시오 같은 쌍과 같은 창에 대해 수행하십시오. 한쪽만으로는 다른 쪽의 입력 없이 판단을 내리게 되며, 그것이 애초에 이 메시지를 만든 모호함입니다.
결론 내리지 말아야 할 것
이 메시지를 MAC 주소를 바꾸라는 요구로 읽지 말고, 도움을 요청할 때 공유 비밀을 공개하지 마십시오. 키가 포함된 발췌는 로그를 보관하는 것이 아니라 키를 제거해야 하며, 서로 도달할 수 없는 피어는 인증 비교를 전혀 생성하지 않으므로 라우팅 오류라고 단정하지도 마십시오. 그리고 한 제품군의 문서화된 한계를 모든 IPsec 구현으로 일반화하지 마십시오.
실패한 쌍, 변경 전후의 터널 상태, 두 조건 중 무엇을 바꿨는지 기록하십시오. 그 기록이 다음 발생을 오 분짜리 점검으로 바꿉니다.