strongSwan ESP-in-UDP: 탐지할 NAT가 없을 때

NAT 탐지는 주소 변환을 찾아내며 방화벽 정책을 찾아내지 않습니다. NAT가 없는 사이트 연결에도 명시적인 ESP-in-UDP 선택이 필요할 수 있습니다.

NAT 탐지는 한 가지 질문에 답합니다: 경로에서 주소나 포트가 바뀌었는가? 방화벽이 IP 프로토콜 50을 허용하는지는 답하지 않습니다. 변환이 전혀 없는 사이트 게이트웨이도 native ESP를 버리는 정책 뒤에 있을 수 있으며, 그 요구 사항은 탐지하는 것이 아니라 구성해야 합니다. 메커니즘은 ESP-in-UDP이고, 이는 스스로 나타나는 대체 수단이 아니라 결정입니다.

탐지는 주소에 대한 산술이며 방화벽 탐침이 아닙니다

IKEv2는 NAT 탐지 페이로드 를 전달하며, 여기에는 출발지와 목적지 주소 및 포트의 해시가 들어 있습니다. 각 측은 받은 내용을 로컬에서 보는 내용과 비교하고, 불일치가 있으면 무언가가 패킷을 변환했음을 알게 됩니다. 그 교환에서 중간 라우터가 프로토콜 50을 전달하는지 시험하는 것은 아무것도 없습니다.

실무적 결과는 솔직히 말할 가치가 있습니다. native ESP로 작동하던 터널은 새로 제한적인 방화벽을 스스로 발견하지 못하고, IKE가 계속 성공하는 동안 다음 시도는 데이터 단계에서 실패합니다. 설정된 IKE 보안 연관과 보호된 트래픽이 없음 이 보이며, 이는 유선에서 캡처하기 전까지 라우팅 결함처럼 보입니다.

따라서 캡슐화는 구성하는 연결의 속성이지, 피어가 네트워크 동작에서 협상하는 결과가 아닙니다.

encap이 교환을 바꾸는 방식

현대적인 strongSwan 배포에서는 swanctl.conf 을 통해 관리되며, 연결의 encap = yes 설정이 NAT 탐지 교환에 영향을 주어 두 피어 모두 ESP에 UDP 캡슐화를 사용하게 합니다. 보호된 패킷은 이후 UDP 내부에서, 일반적으로 포트 4500에서 이동하며, 양쪽 끝이 그 배치에 합의해야 합니다.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

그 조각은 실제 연결 정의 안에 속하며 완전한 사이트 프로필이 아닙니다. 이미 운영 중인 피어 주소, 인증, child 트래픽 선택기를 유지하세요; 추가된 단일 키는 보호된 데이터가 어떻게 포장되는지를 바꾸며, 무엇을 보호하는지는 바꾸지 않습니다.

strongSwan의 NAT-traversal 안내서 는 MOBIKE 사용 시 포트 플로팅과의 상호 작용을 포함해 이 동작을 설명합니다.

자신의 백엔드에 속한 설정을 사용하세요

strongSwan에는 두 가지 구성 백엔드가 있고 키가 서로 다릅니다. swanctl.conf 연결은 encap 을 사용하고, 구형 ipsec.conf 연결은 forceencaps 을 사용합니다. 한 백엔드의 키워드를 다른 쪽에 넣으면 불평 없이 로드되고 아무것도 바꾸지 않는 구성이 만들어지며, 이는 오류보다 나쁩니다.

무엇이든 편집하기 전에 실제로 어떤 데몬이 실행 중인지 확인하세요. 많은 배포판에서 두 파일이 모두 존재하는데, 하나는 이전 마이그레이션의 잔재이고 활성 파일은 서비스 유닛이 시작하는 쪽입니다. 파일 타임스탬프로 추측하지 말고 그 유닛을 읽으세요. 여기서의 다섯 초 확인이 아무것도 로드하지 않은 설정을 몇 시간씩 시험하는 일을 막습니다.

연결 소유자를 통해 변경을 적용하고 통제된 시간 창에서 연관을 다시 설정하세요. 이미 설치된 child는 교체될 때까지 현재 캡슐화를 유지하므로 파일 편집만으로는 새 배치가 사용 중임을 증명하지 못합니다.

포장된 데이터를 검증하고 포트만 보지 마세요

보호된 트래픽이 흐르는 동안 게이트웨이에서 캡처한 다음 strongSwan 자체의 보기와 비교하세요:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP는 IP 프로토콜 50으로 나타나며 UDP와 전혀 비슷하지 않습니다. 포장된 ESP는 4500의 UDP 데이터그램으로 나타나며 그 페이로드는 IKE가 아닙니다. 같은 포트의 IKE 트래픽은 캡슐화의 증거가 아니며, MOBIKE가 IKE를 그곳으로 옮겨도 데이터 경로는 native로 남기 때문에 포트 번호가 아니라 페이로드를 읽으세요.

경로 MTU도 염두에 두세요. 래퍼는 오버헤드를 더하고, native ESP를 실었던 경로는 패킷이 커지면 조정이 필요할 수 있습니다. 필요한 ICMP 처리는 이미 설계의 일부여야 하며, 캡슐화가 그 의존성을 없애지는 않습니다.

터널 내부의 새 애플리케이션 트래픽이 양쪽 끝에서 포장된 ESP로 캡처에 보이고, 내부 서비스와 그 반환 경로가 여전히 작동할 때 변경을 받아들이세요. 그보다 못하면 파일에서 올바르게 보이는 구성일 뿐입니다.

관련 글