ESP는 TCP 포트 50이 아니라 IP 프로토콜 50입니다: 무엇을 허용해야 할까
프로토콜 번호와 포트 번호는 서로 다른 이름 공간입니다. TCP 포트 50에 대한 규칙은 아무것도 허용하지 않으며, NAT 트래버설은 ESP를 UDP 4500으로 옮깁니다.
방화벽 입력란은 TCP 포트를 묻고, 누구나 50을 적습니다. 그 설정은 아무것도 허용하지 않습니다. ESP는 IP 프로토콜 번호 50이고 프로토콜 번호는 포트가 아니기 때문입니다. 두 이름 공간은 작은 정수만 공유할 뿐이고, IKE가 끝난 뒤 보호된 트래픽이 도착하지 않아야 비로소 문제를 알게 됩니다.
작은 숫자를 공유하는 두 이름 공간
IP 헤더에는 다음에 무엇이 오는지 지정하는 프로토콜 필드가 있으며, TCP는 6, UDP는 17, ICMP는 1, ESP는 50, AH는 51입니다. TCP나 UDP 헤더에는 포트 번호가 있어 목적지 호스트의 프로세스를 고릅니다. 프로토콜 50과 TCP 포트 50은 서로 무관한 값이지만, 대화 상자는 둘을 교환 가능한 것처럼 보이게 만듭니다.
그래서 포트 포워딩 규칙으로는 네이티브 ESP를 표현할 수 없습니다. 포워딩할 ESP 목적지 포트가 존재하지 않고, 포트 규칙만 이해하는 장비에는 그 패킷을 표현할 어휘 자체가 없습니다. 올바른 규칙은 대신 IP 프로토콜을 지정합니다. 어떤 포트 대화 상자든 그 패킷에는 잘못된 도구입니다.
혼동에는 또 다른 절반이 있습니다. 패킷이 암호화되면 그 안의 모든 것이 불투명해지며, 원래 연결의 TCP 헤더도 마찬가지입니다. 그 패킷에서 포트를 검사하는 방화벽은 바깥 헤더를 보는 것이고, 네이티브 경우에는 거기에 검사할 포트가 없습니다.
네이티브 ESP, 그다음 캡슐화된 대안
네이티브 ESP는 IP 프로토콜로 직접 전달되며, 이는 효율적이면서 똑같이 번거롭습니다. 추가 헤더가 없어 효율적이고, 주소와 포트를 변환하는 어떤 장비도 추적할 수 없어 번거롭습니다. NAT 트래버설은 바로 이것을 해결하려고 존재하며, ESP 패킷을 UDP 안에 감싸 변환 측이 다시 쓸 포트를 갖게 합니다.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
두 형태는 같은 데이터 채널의 대안 배포이지 한쪽의 계층이 아닙니다. 네이티브 ESP를 허용해도 캡슐화 형태가 허용되지 않고, UDP 4500을 허용해도 네이티브 트래픽이 허용되지 않으므로 규칙 집합은 배포에 맞아야 하며 우연히 둘 다 덮어서는 안 됩니다.
여기서는 탐지도 중요합니다. 종단점은 협상 중에 두 형태 중 하나를 정하고, 전환은 보통 둘 사이에서 NAT가 감지될 때 일어납니다. 따라서 터널이 설정된 뒤 경로가 바뀌면 트래픽이 규칙이 전혀 다루지 않던 이름 공간으로 옮겨질 수 있습니다.
연결이 실제로 어느 형태를 쓰는지 읽어 보세요
방화벽에서 추측하지 말고 종단점에 물어보세요. Linux에서는 상태 항목이 연관이 UDP 캡슐화를 쓰는지, 어떤 포트가 관련되는지 알려 줍니다. 패킷 캡처는 같은 질문에 회선에서 답하며, 둘 다 규칙 집합을 읽고 기대하는 것보다 빠릅니다.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'첫 번째 명령은 NAT 트래버설이 쓰일 때 캡슐화 유형을 보여 주고 쓰이지 않을 때는 아무것도 보여 주지 않습니다. 두 번째는 두 형태 중 어느 것이 실제로 인터페이스를 통과하는지 보여 주며, 종이 위에서 맞아 보이는 설정에 대한 논쟁을 끝냅니다.
반대 증거도 같은 단계에 속합니다. 일치가 전혀 없다고 보고하는 규칙은 패킷이 그 규칙에 도달한 적이 없다는 뜻이며, 그것은 방화벽이 아니라 라우팅이나 선택자의 문제입니다.
그다음 제어 채널을 따로 확인하세요. IKE에는 자체 포트와 자체 로그가 있고, 데이터 없이 끝난 협상은 바로 이 글에서 말하는 분리입니다.
규칙을 올바른 이름 공간에 쓰세요
프로토콜 규칙과 포트 규칙은 서로 다른 지시이므로 도구는 의도한 쪽을 표현해야 합니다. nftables에서는 프로토콜 일치가 명시적이며, 캡슐화된 대안은 자체 UDP 규칙을 받습니다. 두 규칙을 나란히 두어 검토할 때 짝이 보이게 하세요.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } accept잘못된 진단을 보상하려고 어느 규칙도 넓히지 마세요. 모든 인터페이스에서 ESP 프로토콜을 전부 허용하거나 어디서나 어디로든 UDP를 허용하면 증상은 고쳐지지만 설정하려던 통제가 사라집니다. 형태를 알면 좁은 허용으로 거의 항상 충분합니다.
마지막으로, 터널은 되는데 애플리케이션이 안 될 때 계층을 헷갈리지 마세요. 게이트웨이에 도착한 패킷에는 여전히 포워딩과 반환 경로, 그리고 그것을 받아들이는 정책이 필요하며, 그중 어느 것도 ESP 규칙으로 표현되지 않습니다. 빠진 포트는 특정 실패를 설명할 뿐, 모든 IPsec 실패를 설명하지는 않습니다. 규칙 수정과 라우팅 확인을 두 개의 별개 결론으로 두세요.
관찰한 형태, 추가한 프로토콜 규칙, 그 뒤에 본 카운터를 기록하세요. 세 줄이면 다음 사람이 반나절이 아니라 일 분 만에 이름 공간 실수와 라우팅 실수를 구분할 수 있습니다.