IKEv1과 XAuth·OTP: 각 프롬프트가 실제로 요구하는 것
그룹 PSK, 사용자 XAuth 교환, OTP 챌린지는 서로 다른 세 가지 입력입니다. 다른 클라이언트를 설치하기 전에 각 프롬프트를 그 주인과 맞춰 두세요.
PSK, XAuth, OTP를 함께 쓰는 IKEv1이 요구하는 것은 복잡한 비밀번호 하나가 아닙니다. 피어 사이의 공유 키, 사용자 교환, 그리고 백엔드가 요청 방식을 정하는 두 번째 요소를 층으로 쌓아 둘 뿐입니다. 각 층에는 저마다의 주인과 저마다의 실패 메시지가 있습니다. 이들을 혼동하면 그룹 비밀을 저장하는 필드에 일회용 코드를 다시 입력하게 됩니다.
다른 클라이언트를 설치하거나 자격 증명을 재설정하기 전에, 각 프롬프트를 그것을 요구하는 층과 맞춰 두세요.
세 가지 비밀, 세 명의 주인
사전 공유 키는 피어 관계에 속하며 양쪽 끝을 관리하는 사람이 한 번 설정합니다. 사용자 자격 증명은 인증 백엔드에 속하고 로그인할 때마다 검증됩니다. 두 번째 요소는 토큰 시스템에 속하며 그 응답은 시도할 때마다 달라집니다. 어느 것도 다른 것을 대신하지 못하며, 셋을 하나의 비밀번호로 취급하는 배포는 아무도 문서화하지 않은 층에서 실패합니다.
주인, 수명, 그리고 각자가 만들어 내는 실패 메시지, 이 세 열을 적어 두세요. 진단 도구는 그 표이지 클라이언트의 필드 이름이 아닙니다.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: 사람이 아니라 피어의 것
이 레거시 구성에서 사전 공유 키는 게이트웨이 쌍을 인증하므로 사용자의 로그인이 그것을 대신하지 못합니다. 또한 프롬프트 대신 일반적인 협상 오류를 만들어 내는 방식으로 틀리기 쉬운 값이기도 합니다. 사용자 프롬프트가 뜨기 전에 터널이 실패한다면 의심할 대상은 키나 제안입니다.
사용자 자격 증명으로는 첫 단계 실패를 고칠 수 없습니다. 그것을 교체해 봐야 안전하게 교체할 수 있는 유일한 자격 증명만 낭비되고, 잘못된 가설만 굳어집니다.
XAuth: 레거시 사용자 교환
XAuth는 IKEv1 피어 인증 위에 사용자 인증 교환을 추가하며, 어느 백엔드가 검증할지는 게이트웨이가 정합니다. 그 백엔드에 따라 교환은 디렉터리 비밀번호, RADIUS 자격 증명 또는 토큰 응답을 받아들일 수 있습니다. XAuth라는 말은 교환의 전송 방식을 가리킬 뿐 자격 증명 유형을 가리키지 않습니다.
게이트웨이 프로필이 어느 백엔드를 가리키는지 확인하세요. 그러면 사용자가 무엇을 요구받는지, 비밀번호 재설정이 실제로 무엇을 바꾸는지 알 수 있지만, 둘 다 클라이언트 프로필에서는 보이지 않습니다.
OTP: 백엔드가 요구하는 것
일부 배포는 비밀번호 뒤에 일회용 코드를 따로 요구하고, 다른 배포는 문서화된 구분자를 쓰는 결합 입력 형식을 정의합니다. 둘 다 존재하며 눈앞의 프로필이 어느 쪽인지 정합니다. 다른 사이트에서 통했다고 연결 방식을 만들어 내는 것이 등록 토큰을 태우는 가장 흔한 방법입니다. 이것을 정리해 주는 자료는 게이트웨이 자체 문서뿐입니다.
게이트웨이가 제공하는 교환을 완료할 수 있는 클라이언트로 문서화된 형식을 사용하세요.
클라이언트 경계가 문제가 되는 지점
Fortinet은 FortiClient 7.4.4 이후 버전이 IPsec VPN용 IKEv1을 더 이상 지원하지 않는다고 설명하는데, 이는 전면 삭제가 아니라 제품과 버전의 경계라고 FortiClient 호환성 안내에 기록되어 있습니다. 다른 클라이언트도 서로 호환되지 않으며, OpenConnect와 openfortivpn은 임의의 IKEv1 프로필이 아니라 특정 게이트웨이 프로토콜을 사용합니다. 설치된 클라이언트의 IKE 버전, PSK 모드, XAuth 지원, 상호 작용 모델을 각각 확인하세요. 다른 방식으로 연결하는 클라이언트는 원래 요구 사항을 충족했다는 것을 증명하지 못합니다.
IKEv1은 지원 중단되었으므로 지원되지 않는 구형 클라이언트 위에 세운 새 배포는 수명이 짧은 해법입니다. 두 번째 요소를 그곳에서 어떻게 처리할지 포함해 지원되는 마이그레이션 경로를 게이트웨이 관리자에게 요청하세요.
요소를 끄지 않고 진단하기
로그에서는 피어 협상, 사용자 교환, 두 번째 요소 결과, 그다음 주소와 경로 할당이라는 단계를 나눠 보세요. 코드를 모든 필드에서 시도하는 대신 어느 구성 요소의 어느 단계인지 기록하세요. 테스트를 통과시키려고 요소를 끄면 그 터널은 배포에 대해 아무것도 증명하지 못합니다.
등록 비밀과 공유 키는 조직의 절차에 따라 보호된 저장소에 보관하세요. 상시 파일에 들어 있는 일회용 코드는 더 이상 두 번째 요소가 아닙니다.