TCP상의 IKE 4500: 포트 규칙 전에 양쪽 끝을 확인하십시오
TCP 캡슐화는 양쪽 끝이 협상하며, 방화벽 규칙이 부여하는 것이 아닙니다. 리스너 확인, 캡처, 네 가지 수용 단계를 순서대로 실행하십시오.
지원 티켓은 방화벽 변경이 이미 승인되었는데도 터널이 여전히 올라오지 않을 때 자주 도착한다. 기능이 한쪽 끝에만 있을 때 예상되는 결과다: RFC 9329의 TCP 캡슐화는 양쪽 끝에서 구현하고 구성해야 하며, 보호된 트래픽이 흐르기 전에 연결 내부에서 합의가 이루어진다. 포트를 여는 것은 존재하지 않을 수도 있는 리스너를 광고하는 것이고, 반대편에 일치하는 구성이 없는 리스너는 연결을 받아들인 뒤 조용해진다. 아래 순서는 값싼 확인을 먼저 둔다.
옵션이 실제로 무엇을 추가하는지 아십시오
기본 IPsec은 암호화된 페이로드를 다음과 같이 전달합니다: IP 프로토콜 50, 허용할 포트 번호 없이. NAT 트래버설은 그 패킷을 UDP로 감싸 포트 4500으로 보내며, 그래서 많은 방화벽 규칙이 그 포트를 언급한다. RFC 9329는 스트림 표현을 추가한다: IKE와 IPsec 패킷은 둘 다 하나의 TCP 연결 안에서, 보통 포트 4500으로 이동한다.
스트림은 웹 서비스가 아니다. 4500으로의 TCP 연결은 HTTP, TLS, 프록시 친화성에 대해 아무것도 말하지 않으며, 경로상의 HTTP 프록시는 보통 전달하는 대신 프레이밍을 깨뜨린다.
방화벽을 건드리기 전 사전 확인
표준은 TCP를 UDP 경로를 버리는 네트워크를 위한 대체 수단으로 두며, 그 대체물로 두지 않는다. 각 공급업체에서 두 가지 사실, 즉 정확한 기능 이름과 독점 변형이 아닌 RFC 9329를 구현한 버전을 얻으십시오. IPsec over TCP 같은 레이블은 무관한 설계에 사용되어 왔으므로 문서 참조와 이를 켜는 구성 키를 요청하십시오. 두 답이 없으면 유선 호환성에 대해 아무것도 가정하지 마십시오.
양쪽 끝이 모두 당신의 것인 실험실에서 증명하십시오. TCP 4500에 응답하지만 IKE를 끝내지 않는 게이트웨이는 반대편에 일치하는 캡슐화가 없는 리스너의 특징이며, 변경 창에서 발견하는 것보다 훨씬 저렴하다.
응답자 쪽: 무언가 듣고 있는가
소켓부터 시작하십시오. ss -ltnp | grep 4500은 TCP 리스너가 있는지, 어느 프로세스가 소유하는지 보여준다. 줄이 없으면 조사는 네트워크가 아니라 게이트웨이 구성에서 끝난다.
소켓이 있으면 클라이언트 쪽에서 추측하지 말고 핸드셰이크를 관찰하십시오: tcpdump -ni any 'tcp port 4500'. 삼방향 핸드셰이크가 완료된 뒤 침묵이 이어지면 스트림은 수락되었고 그 안의 IKE 교환이 실패한 것이며, 응답 없는 SYN은 필터링이나 잘못된 주소를 가리킨다.
둘을 혼동하지 않도록 같은 캡처 창에서 UDP 경로와 비교하십시오: tcpdump -ni any 'udp port 4500 or proto 50'. TCP가 사용 중이라고 믿는데 프로토콜 50이나 UDP 포트 4500에 트래픽이 있으면 양쪽 끝이 대체 수단에 합의하지 않은 것이다. 가능하면 게이트웨이에서도 캡처해야 한다(클라이언트 쪽 캡처는 먼 쪽이 무엇을 보냈는지 보여줄 수 없기 때문이다).
네 개의 별도 단계로 수락하십시오
올라오는 과정을 네 가지 결과로 다루십시오. 각각 다른 이유로 실패할 수 있고, 단일 통과나 실패는 어느 것인지 감추므로 실패한 첫 단계에서 멈추고 위에서 다시 시작하십시오.
| Stage | What you check | What it proves |
|---|---|---|
| 1 | TCP connection established to 4500 | A listener exists and the path permits it |
| 2 | IKE_SA authenticated in the gateway log | Both peers agreed on the encapsulation |
| 3 | CHILD_SA installed, visible with ip xfrm state | Keys exist for the protected traffic |
| 4 | A new application exchange succeeds | The data path works, not just the control path |
네 번째 단계가 건너뛰어지는 단계다. 기존 세션은 캐시된 상태로 계속 동작할 수 있으므로 변경을 닫기 전에 게이트웨이 뒤의 호스트로 새 연결을 여십시오. 두 번째 단계가 실패하고 첫 번째가 통과하면 불일치는 제안이나 캡슐화 설정에 있지 방화벽에 있지 않다.
롤백, 그리고 켜 둔 채로 두는 비용
변경 전에 되돌리기를 계획하십시오. 양쪽 끝에서 캡슐화 옵션을 끄고 터널이 UDP로 돌아오는지 확인하십시오. 대체 수단이 다시 필요할 경우를 위해 TCP 규칙을 한 번의 검토 주기 동안 유지한 뒤 제거하십시오(4500의 사용하지 않는 리스너는 운영 가치가 없는 공격 표면이다).
실제 작업을 실어 나르기 시작하면 성능 특성을 관찰하십시오. TCP 안의 TCP는 단일 손실에서 멈추는 확인 계층을 추가하고, 하나의 연결을 공유하는 스트림은 서로를 막을 수 있으므로 ping 대신 터널을 사용할 애플리케이션을 측정하십시오.
수락 목록
양쪽 끝의 기능 이름과 버전, 응답자의 리스너, 완료된 핸드셰이크를 보여주는 캡처, 타임스탬프와 함께 기록된 네 단계를 확인하십시오. 다음 엔지니어가 TCP가 왜 있는지 알 수 있도록 변경 기록에 대체 이유를 추가하십시오. 필요해지기 전에 롤백을 연습하십시오.
어느 단계든 실패하면 그 단계만 고치십시오. 전송 문제를 쫓기 위해 암호 제품군이나 ID 설정을 바꾸는 것은 보통 첫 번째 위에 두 번째의 무관한 실패를 더한다.