vpnc 그룹 시크릿 아니면 로그인: 어느 칸에 무엇을 넣나?
vpnc 프로필은 그룹 ID, 그룹 시크릿, XAuth 로그인을 요구하고, 사람들은 계정 비밀번호를 잘못된 칸에 넣습니다. 역할에 따라 각 칸을 정리하세요.
누군가 처음 vpnc 프로필을 건네면, 자격 증명 대화상자는 네 가지를 묻고 마치 비밀번호 하나를 원하는 것처럼 읽힌다. 그렇지 않다: 그룹 사전 공유 시크릿과 개별 XAuth 로그인은 소유자가 다른 별개의 값이며, 계정 비밀번호를 그룹 칸에 넣으면 잘못된 칸이 아니라 잘못된 비밀번호처럼 보이는 실패가 난다. 이 대응을 제대로 잡는 것이 여기서의 전부다. 밑에 깔린 프로토콜은 다른 사람의 마이그레이션 프로젝트이므로, 이 중 어느 것도 새 IKEv1 터널을 만들 근거가 아니다.
두 개의 시크릿, 두 명의 소유자, 하나의 대화상자
그룹 시크릿은 게이트웨이 프로필에 속한다. 그 프로필로 접속하는 모든 사람이 같은 값을 쓰며, 바로 그래서 그것은 사람을 식별할 수 없고 프로필의 다른 모든 사용자를 위해 바꾸지 않고서는 노트북 한 대에서 회수할 수도 없다. XAuth 사용자 이름과 비밀번호는 대신 사람에게 속하며, 게이트웨이는 IPsec 연결이 이미 올라간 뒤 두 번째 단계에서 그것들을 평가한다.
사람들이 놓치는 것이 바로 이 두 단계 형태다. 터널 수립과 사용자 인증은 입력이 다른 별개의 교환이므로, 자격 증명 요청에 결코 도달하지 않는 클라이언트는 로그인에서 실패한 것이 전혀 아니다. 대화상자를 하나가 아니라 두 개의 열로 읽어라: 왼쪽은 프로필 전체의 값, 오른쪽은 개인 값이다. 연결이 실패했을 때 마지막으로 채운 열이 자동으로 범인 열은 아니다.
칸은 라벨이 아니라 역할로 대응시켜라
vpnc는 프로젝트 문서에서 지시자를 이름 붙이고, 모든 그래픽 프런트엔드는 그것을 다시 이름 붙인다. 각 값의 역할을 번역하면 라벨은 더 이상 문제가 되지 않는다:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
그룹 칸 옆에 «사용자 이름»과 «비밀번호»를 보여 주는 프런트엔드는 틀리지 않았다 — 같은 세 값을 다른 이름으로 보여 줄 뿐이다. 깨지는 것은 값이 들어맞는다는 이유로 칸을 채우는 일이다. 사용자 비밀번호로 붙여 넣은 그룹 시크릿은 프로필을 인증한 뒤 사용자 단계에서 실패하고, 그룹 시크릿으로 붙여 넣은 계정 비밀번호는 더 일찍, 어떤 요청보다도 먼저 실패하며, 텍스트 칸에 사는 문제를 방화벽에서 찾게 만든다.
그룹 식별자가 아닌 것
그룹이라는 단어는 잘못된 읽기를 부른다. 여기서 그룹 식별자는 게이트웨이에 어떤 프로필 구성을 적용할지 알려 주는 선택자이며, 디렉터리 소속에 대해서는 아무 말도 하지 않고, 양쪽의 이름이 일치하는 것은 운영자가 확인하기 전까지 우연이다. 권한 부여는 XAuth가 성공한 뒤에 일어나며, 게이트웨이가 무엇을 참조하도록 구성되었는지가 결정하고, 그중 어느 것도 클라이언트 대화상자에 보이지 않는다.
같은 주의가 그룹 시크릿에도 적용된다. 그것을 아는 것은 신원이 아니며, 하나의 시크릿을 팀에 돌리는 것은 클라이언트가 보여 줄 수 없는 결과를 낳는 운영 결정이다.
연결하기 전에 모호한 지시를 풀어라
오래된 인계 메모에는 «전용 공인 IP를 사용하라» 같은 줄이 자주 있다. 그 표현은 반대편 허용 목록이 당신의 트래픽이 어디서 도착하기를 기대하는지 그 주소를 뜻할 수 있으며, 이는 운영자 네트워크의 출구 속성이고 게이트웨이 칸에 입력하는 종단점과는 아무 관계가 없다. 값이 어디로 가기 전에 둘 중 어느 쪽인지 물어라. 거꾸로 채우면 모든 패킷을 결코 응답하지 않는 주소로 보내고, 그 결과인 시간 초과는 차단된 포트처럼 읽힌다.
조직의 검증된 채널로 네 가지를 요청하라: 어떤 클라이언트와 프로토콜이 지원되는지, 어떤 종단점을 쓸지, 게이트웨이가 어떤 신원을 제시할지, 자격 증명을 어떻게 넘기는지. 진짜 시크릿은 스크린샷, 티켓, 공유 문제 해결 메모 밖에 두어라. 인증서 검사를 끄거나 오래된 암호 목록을 붙여 다른 구성의 서비스를 호환처럼 보이게 하지 말라 — 검증을 약화시켜야만 동작하는 연결은 요청받은 연결이 아니다.
레거시 프로필을 정직하게 유지하라
IKEv1은 폐기되었고, 마이그레이션 문제가 나올 때 인용할 문서는 RFC 9395다. 성공적인 칸 대응은 그 프로토콜이 새 설계에 속한다는 증거가 아니다 — 그것이 사 주는 것은 교체가 예정될 때까지 동작하는 연결과, 그 마이그레이션의 서면 범위 및 담당자다.
그다음 대화상자가 아니라 요구사항에 대해 검증하라. 연결한 뒤 터널 인터페이스가 기대한 주소를 가지는지, 내부 목적지가 그를 통해 라우팅되는지 확인하고, 원래 요구사항이 허용 목록용 출구 주소를 지목했다면 그 주소도 확인하라 — 터널이 올라와 있다는 것과는 다른 사실이기 때문이다. 올바로 인증하고 아무것도 라우팅하지 않는 프로필은 만들어진 목적을 여전히 달성하지 못한 것이다.