중복 IKE 패킷: 빠진 전이 찾기
반복되는 IKE 요청은 타이머 이벤트이지 진단이 아닙니다. 올바른 버전 식별자와 함께 개시자에서 응답까지 하나의 증거 사슬을 만드십시오.
로그에 같은 IKE 요청이 두 번 나타나고, 누군가는 모바일 업링크를 가리키며, 티켓은 추측으로 닫힌다. 그 추측이야말로 신화다: 반복된 패킷은 하나의 교환에 대한 관찰이지 링크의 진단이 아니다. 재전송은 나름의 규칙을 가진 정상 동작이며, 응답이 느릴 때는 건강한 경로에서도 나타난다. 인터페이스를 탓하기 전에 응답을 따라가라.
신화: 반복된 요청은 한 링크의 손실을 증명한다
서로 다른 두 가지가 중복을 만들며 어느 것도 범인을 지목하지 않는다. 요청자는 응답을 받지 못해 요청을 반복할 수 있고, 캡처 지점은 스택에 연결된 위치 때문에 같은 패킷을 두 번 보여 줄 수 있다. 같은 호스트에서 인그레스와 이그레스를 보는 탭은 한 패킷을 기꺼이 둘로 기록하며, 그 로그를 읽는 운영자는 교환 식별자 없이는 차이를 구별할 방법이 없다. 둘 중 어느 것을 손에 쥐고 있는지 말할 수 있을 때까지 중복을 타이머 이벤트로 취급하라.
업링크가 둘이면 혼란이 줄어들기는커녕 커진다. 로그 한 줄은 인터페이스 하나를 지목하지만 응답은 다른 쪽으로 나갔을 수 있으므로, 메시지의 인터페이스는 패킷이 어디서 보였는지를 설명할 뿐 대화의 형태를 설명하지 않는다. 그래서 첫 질문은 어느 링크가 고장 났는가가 아니라 어느 교환을 보고 있는가이다.
재전송이 실제로 말해 주는 것
IKEv2에서 재전송 은 이렇게 동작한다: 응답이 도착하지 않으면 요청자가 요청을 반복하고, 응답자는 새로 계산하는 대신 캐시한 응답을 다시 보낼 수 있다. 메시지 식별자는 그 교환에 속하며, 같은 식별자를 가진 반복 요청이 새로운 시도가 아니라 프로토콜이 동작하는 것으로 인식되는 이유가 바로 그것이다. 최초 시도는 상관을 위해 소스 주소나 개시자 SPI 이상을 필요로 하는 경우가 많으므로, 플랫폼 자체의 교환 기록이 패킷 목록보다 낫다. IKEv1은 다른 식별자로 다른 규칙을 따르며, 첫 패킷 중복에 대한 공급업체 경고도 버전마다 같은 의미가 아니다.
따라서 재전송 타임스탬프는 타이머가 만료되었음을 알려 준다. 어느 홉이 느렸는지는 알려 주지 않으며, 통신사가 잘못했다고 말하지도 않는다. 이는 별개의 주장이고, 티켓에서 쓸모 있는 것은 두 번째뿐이다.
실무적 결론은 결론을 내리기 전에 교환을 기록하는 것이다. 로컬 수신 주소, 정책이 선택한 응답 경로, 피어 튜플, 교환 식별자를 한곳에 적어 두라. 나중에 기록을 읽을 때 각각이 서로 다른 질문에 답하기 때문이다.
하나의 사슬로서의 네 관측 지점
교환을 네 개의 따로 보는 장소가 아니라 사슬의 네 고리로 생각하라. 고리는 증거를 담거나 미지로 남고, 사슬은 기록된 가장 약한 고리만큼만 정보를 준다. 아래 표는 목록이다: 각 위치가 무엇을 입증할 수 있고 무엇을 건드리지 않는지.
| 위치 | 제공할 수 있는 증거 | 열린 채로 남기는 것 |
|---|---|---|
| 개시자가 보낸다 | 요청이 이 호스트를 떠났다 | 피어에 도달했는지 |
| 응답자가 받는다 | 요청이 도착했다 | 응답이 생성되었는지 |
| 응답자가 보낸다 | 응답이 게이트웨이를 떠났다 | 의도한 경로를 따랐는지 |
| 개시자가 받는다 | 교환이 완료되었다 | 정책이 결과를 받아들였는지 |
접근 권한이 있는 곳에서만 사슬을 채우고, 나머지는 추론하는 대신 미지로 표시하라. 한 장비에서 패킷을 기록하는 훅은 원격 장비가 무엇을 받았는지에 대해 아무것도 말하지 않으며, 요청이 보였다는 로그 한 줄은 응답이 나간 적이 있다는 증거가 아니다. 정직한 빈틈이 추측으로 만든 완전해 보이는 기록보다 유용하다.
첫 번째 빠진 전이를 찾아라
개시자에서 바깥으로 사슬을 따라가며 증거가 없는 첫 고리에서 멈춰라. 게이트웨이가 요청을 전혀 기록하지 않으면 결함은 그 앞의 경로에 있다. 게이트웨이가 같은 요청을 거듭 기록하는데 클라이언트가 응답을 전혀 기록하지 않으면 의심스러운 것은 반환 방향이다: 소스 주소, 변환, 그리고 통제하는 각 경계의 필터링. 응답이 도착해도 클라이언트가 나아가지 않으면 질문은 전송을 떠나 정책이나 상태가 되었다.
비교하는 동안 피어와 프로토콜을 고정하고, 지연, 손실, 정책, 상태가 각각 다른 시간선을 만든다는 점을 기억하라. 모바일 네트워크가 자동으로 원인인 것은 아니고, 고정 회선이 모든 요구에 자동으로 충분히 신뢰할 만한 것도 아니다. 교환이 살아 있는 동안 양방향을 캡처하라:
tcpdump -ni any -vv 'udp port 500 or udp port 4500'
접근이 원격 끝 이전에 끊기면 기록이 어디서 끊기는지 말해 줄 때 여전히 도움이 된다. 개시자에서만 캡처하면 요청이 나가고 응답이 오지 않는 것을 보여 줄 수 있어, 결함을 그 훅 이후의 모든 것으로 좁힐 수 있다. 어느 홉이 떨어뜨렸는지 아는 척하지 않고서. 원격 고리는 미지로 표시하고 접근 권한이 있는 다음 사람이 채우게 하라. 그렇게 적으면 기록은 정직하게 유지되고 여전히 짧다.
무엇이든 바꾸기 전에 비교하라. 같은 피어에 같은 프로토콜로 같은 요청을 반복하면 변수를 셀 수 있게 유지하지만, 캡처 사이의 재설정, 키 갱신, 정책 편집은 비교를 파괴한다. 변경이 불가피하면 곧바로 다시 캡처하여 이전과 이후가 여전히 같은 교환을 설명하게 하라.
유용한 보고서가 말하는 것
행동할 가치가 있는 보고서는 하나의 요청을 그 응답과 짝지어 주고, 뒤에 증거가 없는 첫 단계를 지목한다. 그 문장은 일주일 뒤 그 자리에 없던 엔지니어가 읽어도 견디며, 다음 사람에게 용의자가 아니라 시작점을 준다.
재전송 이론을 확인하려고 신원 검사를 약화하거나 허용 프로토콜 집합을 넓히지 말라. 재설정 전에 원본 패킷과 이벤트 기록을 저장하라. 재설정은 수집하려던 자료를 정확히 파괴하고 교환이 어디서 멈췄는지 보여 주던 타이밍을 지운다.
신화는 하나의 중복이 통신사의 잘못을 증명한다는 것이다. 현실은 하나의 중복이 타이머의 만료를 증명하며, 답은 응답 경로에 있다.