strongSwan EAP: IKE ID와 기대되는 AAA 이름

strongSwan EAP 클라이언트는 두 개의 서버 이름을 검증할 수 있습니다. remote.id는 IKE 게이트웨이를, local.aaa_id는 EAP 서버를 대상으로 하며, 둘은 같은 필드가 아닙니다.

IKEv2 기반 EAP 인증은 하나의 연결에서 서로 다른 두 서버 이름을 검증하도록 클라이언트에 요구할 수 있습니다. IKE를 종료하는 게이트웨이는 하나의 ID를 제시하고, 내부 TLS 교환을 종료하는 EAP 백엔드는 다른 ID를 제시할 수 있습니다. strongSwan에서 이들은 서로 다른 설정 블록에 있으며, 이름을 잘못된 블록에 두면 인증서 문제처럼 보이는 실패가 발생합니다. 어느 검증이 실패했는지 읽는 것이 어느 블록을 고쳐야 하는지 알려줍니다.

하나의 연결, 두 개의 서버 ID

첫 번째 ID는 IKE 교환에 속합니다. 클라이언트는 주소로 접속하고 상대가 특정 ID, 보통 게이트웨이 인증서의 이름을 증명하기를 기대합니다.

두 번째는 EAP에 속합니다. PEAP나 TTLS에서는 클라이언트가 IKE SA 내부의 인증 서버로 TLS 터널을 만들고, 그 내부 서버가 자체 인증서를 제시합니다. 백엔드가 별도 호스트라면 그 이름은 게이트웨이의 이름과 다릅니다. 첫 번째 이름만 확인하는 클라이언트는 두 번째가 주장하는 것을 그대로 받아들입니다. 그리고 두 위치에 같은 이름을 설정한 클라이언트는 둘이 실제로 달라지는 순간 실패합니다.

두 이름 모두 운영자의 설정에서 나오며, 오류를 없애 주는 인증서에서 나오지 않습니다. 운영자에게 배포 세부 정보를 묻는 것이 두 호스트 이름을 추측하는 것보다 빠릅니다.

어느 필드가 어느 계층에 속하는가

swanctl에서 주소와 IKE ID는 별도 설정이고, EAP ID는 세 번째입니다.

원격 주소는 패킷이 어디로 갈지 정하고, 원격 ID는 상대가 무엇을 증명해야 하는지 말합니다. EAP 기대값은 local 블록 아래에 쓰는데, 상대의 IKE 동작이 아니라 이 클라이언트의 EAP 교환을 설명하기 때문입니다. 바로 이 배치가 잘못 읽히는 부분입니다. 이름은 서버를 설명하면서 클라이언트 설정에 있으므로, 그래서 정확히 잘못된 위치처럼 보입니다.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

이 조각은 완전한 연결이 아니며, 신뢰 자료, 자격 증명, 자식 연결 정책이 아직 있어야 합니다. 이를 작업 파일에 그대로 복사하면 아직 필요한 설정을 대체하게 됩니다.

aaa_id가 local 아래에 있는 이유

local 블록은 인증 중에 이쪽이 하는 일을 설명하며, 사용할 방법과 그 방법에 대해 상대가 제시하기를 기대하는 ID를 포함합니다. AAA 서버가 같은 머신에서 실행된다고 주장하는 내용은 없습니다.

기본값이 함정을 더 날카롭게 만듭니다. 명시적 값이 설정되지 않으면 기대되는 AAA ID는 원격 ID를 따르므로, 단일 이름 배포가 동작하고 차이를 숨깁니다. 명시적 값은 EAP 배포가 실제로 다른 곳에서 종료될 때만 의미가 있습니다. 그 이유 없이 다른 이름으로 설정하면 운영자가 재현할 수 없는 실패가 생깁니다. 두 번째 이름을 만들기 전에 배포를 읽으십시오.

값은 백엔드 인증서가 실제로 주장하는 것과 동일하게 유지하고, 이름의 형식도 포함하십시오. 끝의 점이나 호스트를 포함하지 않는 와일드카드만으로도 검증은 실패합니다.

분리를 표현할 수 없는 프런트엔드

NetworkManager 프로필은 swanctl과 같은 설정 인터페이스가 아닙니다. 그 뒤의 플러그인은 더 좁은 ID 제어 집합을 노출하며, 어떤 것이 있는지는 설치된 버전에 따라 다릅니다.

배포에 실제로 두 이름이 필요할 때 이것이 문제입니다. 서버 ID로 표시된 필드는 한 계층만 설정하고 다른 계층은 설정하지 않을 수 있어, 프로필이 올바르게 보여도 내부 검증에서 실패합니다. 프로필이 이 구성을 표현할 수 있다고 가정하기 전에 설치된 플러그인이 무엇을 지원하는지 확인하십시오. 할 수 없다면 선택은 운영자의 몫이며, 다른 프로비저닝 경로나 수정된 서버 ID 설계입니다. PEAP를 약화하거나 아무 이름이나 받아들이는 것은 인증 정책을 고치는 대신 바꾸는 것입니다.

대안은 클라이언트에서 만들어 낼 것이 아닙니다. 지원되는 구성을 서면으로 요청하고, 그 답변을 프로필과 함께 보관하십시오.

ID 불일치와 만료된 인증서를 구분하십시오

이름 불일치와 만료된 인증서는 다른 실패이며, 로그는 이를 구분합니다. 어느 필드를 바꿀지 정하기 전에 메시지를 읽으십시오.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

의도한 AAA ID를 설정해도 인증서가 갱신되지 않고 발급자에 대한 신뢰가 생기지 않으며, 인증서를 갱신해도 잘못된 기대 이름이 고쳐지지 않습니다. 다른 ID 필드를 편집하기 전에 어느 검증이 실패했는지 읽으십시오. 그런 다음 설정을 다시 로드하고, 한 번도 로드되지 않은 편집 파일은 아무것도 바꾸지 않으므로 로드된 연결이 설정한 값을 보여 주는지 확인하십시오. 두 이름과 그 계층을 배포 노트에 기록하십시오.

관련 글