Check Point 또는 Nortel에 대한 vpnc: 왜 멈추는가

vpnc는 XAuth와 함께 IKEv1만 사용합니다. Check Point SNX 또는 Nortel Aventail 게이트웨이는 자격 증명 단계에 도달하지 않으므로 먼저 제품을 식별하십시오.

증상은 쉽게 오독됩니다: vpnc가 시작되고 그룹 암호를 묻고 나서, 대상에서 응답이 없다고 보고할 때까지 협상 단계에 머뭅니다. 출력 어디에도 게이트웨이 제품이 언급되지 않고 계정은 브라우저에서는 동작하므로, 잘못된 암호나 차단된 포트라는 결론으로 이어지기 쉽습니다. 이런 경우 대부분 게이트웨이는 애초에 IPsec 피어가 아니므로, 교환이 자격 증명을 시험하는 단계까지 가지 못합니다. 프로필의 다른 무엇을 바꾸기 전에 이 패턴을 시험해 볼 가치가 있습니다.

프로필의 다른 항목을 편집하기 전에 제품을 식별하십시오.

실패는 잘못된 자격 증명처럼 보인다

vpnc는 UDP 500으로 IKE를 보내는 것으로 시작하고, NAT 통과가 제시되면 UDP 4500으로도 보냅니다. IPsec 대신 SSL을 종료하는 게이트웨이는 둘 다에 응답하지 않으므로 클라이언트는 재시도하고 결국 일반 오류와 함께 포기합니다. 같은 계정이 작은 도우미 응용 프로그램을 불러오는 브라우저 포털을 통해 동작한다면, 터널이 SSL 기반이고 클라이언트가 잘못된 질문을 하고 있다는 강한 단서입니다.

여기서의 실패한 시도는 사용자 계정에 대해 아무것도 말해 주지 않습니다, 자격 증명이 게이트웨이에 제시된 적이 없기 때문입니다.

게이트웨이가 어떤 프로토콜을 제공하는지 확인하십시오

몇 분의 조사로 IPsec 피어와 SSL 포털이 구분됩니다. 클라이언트가 사용할 동일한 네트워크에서 실행하고, 문서에 어떤 포트가 적혀 있는지가 아니라 어떤 포트가 응답하는지 읽으십시오. 결과를 보관하십시오, 바로 그 포트가 게이트웨이 소유자가 어떤 클라이언트를 지원해야 하는지를 결정하기 때문입니다. 게이트웨이 옆의 호스트가 아니라 클라이언트 네트워크에서 조사하십시오.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

로그인 페이지로 리디렉션되는 열린 443과 500 및 4500에서의 침묵은 SSL VPN을 가리킵니다. 443에서 제공되는 인증서와 함께 500과 4500이 열려 있다면 웹 프런트엔드도 운영하는 IPsec 게이트웨이를 시사하며, vpnc가 바로 이 경우를 위해 만들어졌습니다.

Check Point의 SSL Network Extender와 Nortel의 Aventail 클라이언트는 둘 다 두 번째 범주에 속하며, 어느 쪽도 IKEv1 그룹 비밀을 받아들이지 않습니다.

vpnc 프로필이 표현할 수 있는 것과 없는 것

내부에서 vpnc는 그룹 사전 공유 키에 대해 IKEv1을 실행하고, 그다음 XAuth를 통해 개별 사용자의 자격 증명을 보냅니다. 구성 파일의 모든 것은 그 교환에 속합니다: 게이트웨이, 그룹 이름, 그룹 비밀, 사용자 이름, 사용자 암호입니다. 이 항목들은 하나의 프로토콜을 기술하며, 어떤 조합도 클라이언트가 다른 프로토콜을 말하게 할 수 없습니다.

그래서 암호 목록을 넓히거나 인증서 검사를 끄는 것으로는 이런 종류의 실패가 절대 고쳐지지 않습니다. 그런 변경은 게이트웨이가 듣지 않는 협상을 약화시킬 뿐입니다.

게이트웨이에 맞는 클라이언트 선택

Check Point 게이트웨이에는 공급업체가 원격 액세스 문서와 함께 게시하는 해당 게이트웨이 릴리스용으로 빌드된 SNX 패키지를 사용하십시오. 오래된 SNX 빌드는 더 이상 설치되지 않은 32-bit 라이브러리를 기대하기 때문에 현재 배포판에서 자주 실패하며, 버려진 패키지를 패치하는 것보다 지원되는 플랫폼에서 지원되는 클라이언트를 실행하는 편이 보통 낫습니다.

Aventail 클라이언트는 오래전에 지원이 끊겼습니다. 그런 게이트웨이가 아직 운영 중이라면 현실적인 선택은 조직이 활성화한 경우 브라우저 포털, 또는 지원되는 운영 체제에서 공급업체의 지원 클라이언트입니다.

게이트웨이 소유자에게 제품과 버전, Linux에서 지원하는 클라이언트, IPsec 프로필이 있는지 물어보십시오. 있다면, 사용자 암호와 다르고 뒤바뀐 조합이 실패한 터널의 또 다른 흔한 원인이기 때문에, 그룹 식별자와 그룹 비밀을 별도 항목으로 요청하십시오. 연결이 마침내 성공하면 어떤 프로토콜이 협상되었는지 기록하여, 다음 사람이 같은 추측을 반복하지 않고 사실에서 시작할 수 있게 하십시오.

관련 글