DPD 응답은 IKE 피어가 살아 있음을 증명할 뿐, 데이터가 흐른다는 뜻은 아닙니다
생존 응답, 패딩 알림, 축소된 선택자는 서로 다른 세 가지를 설명합니다. 멈춤의 원인을 하나로 몰기 전에 따로 읽어 보세요.
IPsec 로그는 그 앞의 애플리케이션이 멈춰 있는 동안에도 생존 응답을 보여 줄 수 있으며, 두 사실은 동시에 참일 수 있습니다. DPD 응답은 그 순간 피어의 IKE 처리부가 답했다는 것만 확인하며, 자식 SA가 여러분이 신경 쓰는 패킷을 운반하는지에 대해서는 아무것도 말하지 않습니다. 장애 근처의 모든 경고를 그 원인으로 취급하는 것이 바로 선택자 문제를 프로토콜 버그로 오진하는 방식입니다. 가장 자주 혼동되는 세 가지 관찰이 있고, 그것들은 서로 다른 세 가지 질문에 답합니다. 타임스탬프로 읽기 전에 연관과 목적으로 읽으세요.
각 관찰이 증명하는 것
표는 각 관찰이 무엇을 확정하는지와 단지 무엇을 동반하는지를 구분합니다.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
셋 중 어느 것도 그 자체로 오류가 아닙니다. 각각은 디버깅 중인 흐름 옆에서만 의미가 생기며, 특정 흐름과 연결할 수 없는 행은 증거가 아니라 맥락입니다.
생존은 데이터 건강이 아닙니다
DPD는 INFORMATIONAL 교환, 즉 IKE 데몬 사이의 제어 평면 대화로 동작합니다. 응답은 피어의 IKE 프로세스에 도달할 수 있고 답할 의사가 있음을 증명하며, 타임아웃은 그렇지 않음을 증명합니다. 어느 결과도 자식 SA, 선택자, 전달 경로, 애플리케이션의 응답을 시험하지 않으므로, 멈춘 전송 옆의 건강한 DPD는 모순이 아니라 일관된 그림입니다.
그래서 생존 관련 줄은 로그 맨 위에서 아무리 안심시켜 보여도 데이터 평면 티켓에서 가장 쓸모없는 부분입니다.
패딩 알림은 패딩에 대한 진술입니다
TFC 패딩은 이 로그에서 가장 과대 해석되는 줄입니다. 트래픽 흐름 기밀성을 위한 패딩이 해당 자식 SA에서 허용되지 않는다는 뜻이며, 이는 ESP 보호의 거부가 아니라 선택적 패딩 기능에 대한 진술입니다. 장애 근처에서 발견되는 것은 대개 말이 많아서 생긴 우연이며, 패딩을 켜거나 꺼도 선택자 범위에는 아무 변화가 없습니다.
「IKEv2 사양」은 알림과 선택자 협상을 모두 정의하며, 구현의 경고 라벨이 어느 경우에도 프로토콜의 의미를 대체하지는 않습니다.
축소는 더 조용하고 중요할 가능성이 더 큽니다
응답자는 제시된 선택자의 부분집합을 받아들일 수 있고, 받아들인 집합은 여러 항목에 걸쳐 출력될 수 있습니다. 하나는 포트로 한정되고 다른 하나는 모든 포트를 포괄합니다. 첫 번째 포트 한정 줄만 읽으면 받아들인 범위를 과소평가하고, 넓은 줄만 읽으면 과대평가합니다. 출력된 제안을 설치된 정책과 비교하세요. 제안은 피어가 말한 것이고 정책은 커널이 대조할 것이기 때문입니다. 둘이 어긋나면 터널은 있고 트래픽은 없는, 전형적인 간헐적 불만이 됩니다. 피어를 비교할 때는 로컬과 원격 관점을 뒤집으세요. 각 측의 로컬이 상대의 원격이기 때문입니다.
포트 제한이 있는 호스트별 항목은 두 번 읽을 가치가 있습니다. ICMP나 두 번째 포트를 제외하면서 게이트웨이로의 ping은 계속 작동하게 하는 것이 바로 그 항목들이기 때문입니다.
실패하는 흐름에 대한 기록을 하나 만드세요
보호 결정 시점에 보이는 출발지, 목적지, 주소 체계, 프로토콜, 포트를 의도적인 변환까지 포함해 기록하세요. 이것이 선택자와 일치해야 하는 값이며, 티켓이 세 번째 손에 도착했을 때 사람들이 기억에서 다시 입력하는 값이기도 합니다.
그다음 자식 SA와 방향별 카운터를 식별하세요: swanctl --list-sas은 strongSwan 호스트에서 연결 요약을 보여 주고, ip -s xfrm state는 카운터를 보여 줍니다. 시스템이 유휴 상태일 때가 아니라 새로 허용된 요청 다음에 읽으세요. 송신 쪽 증가가 없으면 선택이나 로컬 경로를 가리키고, 대응하는 수신 없이 송신만 있으면 피어와 그 전달 또는 응답을 가리킵니다.
완료된 애플리케이션 교류는 어느 카운터보다 우선하므로, 테스트는 터널 표시가 아니라 애플리케이션에서 끝나야 합니다.
그다음에 수정을 고르세요
그 기록이 있어야만 고를 수 있는 수정이 생깁니다. 승인된 선택자, 라우트, 필터링, 피어 구현, 또는 이제 입증한 경계입니다. 피어를 초기화하면 여러 상태가 한꺼번에 바뀌고 어느 것이 틀렸는지 설명하지 않은 채 트래픽이 복구되는 경우가 많아 장애가 다시 나타납니다. 커널 상태 덤프도 티켓에서 빼 두세요. 키가 들어 있을 수 있고, 도움이 필요한 사람에게는 간단한 요약으로 충분합니다.
기록이 첫 가설과 모순되면 기록을 믿고 가설을 다시 쓰세요. 그 습관은 여기서 논한 어떤 단일 로그 줄보다 값집니다.