ipsec.conf인가 swanctl.conf인가? strongSwan 프런트엔드 하나를 고르세요

오래된 안내서에서 가져온 정상 동작하는 IKEv1 프로필이 Ubuntu 24.04에 도착하지만, 데몬이 그 파일을 한 번도 읽지 않았기 때문에 첫 시도는 실패한다. 흔한 대응은 프로필을 다시 편집하는 것이다. 진짜 질문은 어느 strongSwan 프런트엔드가 설치되어 있고 실행 중인 서비스가 어느 쪽을 쓰는가이다. 그 답이 나오기 전까지 모든 편집은 존재하지 않을 수도 있는 로더를 향한다.

파일 둘, 로더 둘, 데몬 하나

옛 starter 구성은 ipsec.conf를 읽고 예전 관리 통합을 통해 연결을 charon에 넘긴다. 그 운영상 진입점은 ipsec 명령이다.

swanctl 구성은 VICI를 통해 정의를 읽어 들이고 swanctl.conf를 읽으며 swanctl 명령으로 구동된다. systemd에 네이티브인 charon 데몬이 이 방식과 통합된다.

둘 다 같은 머신에 설치될 수 있고, 혼란이 바로 거기서 시작된다. /etc 아래의 파일은 누군가 그것을 썼다는 것만 증명할 뿐, 실행 중인 프로세스가 읽어 들였다는 것은 아니다. 어느 쪽이 동작하는지 보려고 모든 대안을 설치하면 관리 경로가 두 개이고 소유자가 불분명한 호스트가 된다. 한 구성을 고르고 다른 쪽을 제거하거나 비활성화하세요.

설치된 패키지와 unit 읽기

읽기 전용으로 시작하세요. Ubuntu 24.04의 패키지 이름은 따로 있습니다: strongswan-starter, strongswan-swanctl, charon-systemd입니다. 없는 패키지는 유용한 정보이며, 설치하라는 지시가 아닙니다.

패키지와 unit를 한 번에 조사하세요:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

그다음 활성 unit과 그 시작 명령을 확인하세요. unit 이름은 어느 데몬이 설정을 소유하는지 알려 주고, 명령줄은 어떤 파일을 읽으라고 지시받았는지 확인해 줍니다. 활성화되었지만 실행 중이 아닌 unit은 지금 실행 중인 것과 다른 이야기를 합니다.

활성 unit이 strongswan-starter라면 중요한 파일은 ipsec.conf입니다. swanctl을 쓰는 charon-systemd라면 ipsec.conf는 그저 장식입니다.

맞는 제어 경로 사용하기

각 프런트엔드는 연결과 연관에 대해 자기 나름의 시각을 가집니다. swanctl --list-conns는 읽어 들인 정의를, swanctl --list-sas는 활성 연관을 보여 줍니다. 옛 경로는 ipsec statusall을 씁니다.

둘을 섞으면 오해를 부르는 오류가 생깁니다. VICI 소켓이 없거나 제어 요청이 거부된 것은 관리 경로의 문제이며, 상대가 인증을 거부했다는 증거가 아닙니다.

실행 중인 데몬에 속한 시각을 읽으세요, 그다음 결과를 해석하세요. 그 시각에 연결이 없다면 문제는 불러오기이지 협상이 아닙니다.

형식은 IKE 버전이 아닙니다

옛 프로필은 keyexchange=ikev1로 IKEv1을 고릅니다. swanctl 연결은 버전 설정을 쓰며, 여기서 1은 IKEv1을 고릅니다. 이것은 같은 개념의 두 어휘일 뿐 변환이 아닙니다.

상대 주소, 로컬과 원격 신원, 자격 증명 출처, 제안, child 선택자는 모두 의도적으로 대응시켜야 합니다. left/right 블록을 swanctl 문법에 붙여 넣어도 그중 아무것도 되지 않습니다.

프로토콜 버전만 바꾸는 것이 가장 흔한 반쪽 이전입니다. 그것은 불러오기는 되지만 버전과 무관한 이유로 인증에 실패하는 파일을 만듭니다. IKEv1 자체가 RFC 9395로 폐기되었으므로, 여전히 그것을 요구하는 기존 상대에게는 문서화된 호환성 제약과 이전 경로가 필요하지, 새로운 기본값이 필요하지 않습니다.

프로필을 건드리기 전에 로더 확인하기

먼저 로더 점검을 실행하고, 다음으로 의도한 연결을 불러오고, 그다음 협상을 평가하고, 마지막으로 보호된 트래픽 경로를 평가하세요. 각 단계는 실패 신호가 다릅니다.

두 제어 경로는 불러오기 질문에 직접 답합니다:

swanctl --list-conns
ipsec statusall

그 명령 중 하나만 당신의 호스트에 속합니다. 둘 다 실행해 출력을 비교하는 것은 어느 쪽이 거짓말을 하는지 알아내는 방법이지 진단 방법이 아닙니다.

패키지 소유, 설정 불러오기, 프로토콜 호환성을 세 가지 별개의 질문으로 다루세요. 한 프런트엔드에 유효한 파일은 다른 데몬이 실행되는 동안 계속해서 편집되기 마련입니다.