L2TP/IPsec 실패: IPsec, 터널 인증, PPP 로그인을 분리하세요

하나의 L2TP/IPsec 연결 안에서는 세 가지가 인증되며, 그중 사람이 관여하는 것은 하나뿐입니다. IPsec은 터널 끝점을 증명하고, L2TP 제어 연결은 자체 비밀값으로 피어를 다시 증명할 수 있으며, 그다음 PPP가 세션 안의 사용자 계정을 증명합니다. 어느 단계에서 실패하든 클라이언트 대화 상자에서는 일반적인 로그인 오류처럼 보이지만 서버 로그에서는 전혀 다르게 보입니다. 검증되지 않은 단계 아래의 모든 단계도 검증되지 않았으므로, 단계를 순서대로 진행하고 처음 실패한 단계에서 멈추세요.

세 가지 인증 단계, 세 가지 서로 다른 신원

IPsec은 사전 공유 키나 인증서를 사용해 끝점의 소유자를 증명합니다. 그 신원은 장비나 게이트웨이의 것이며 키보드 앞의 사람의 것은 결코 아닙니다. 이 단계에서 피어가 합의하지 못하면 L2TP 패킷은 전혀 교환되지 않습니다.

L2TP 제어 연결은 양쪽 끝이 반드시 보유해야 하는 공유 비밀값으로 구동되는 두 번째의 별도 질의응답 교환을 추가할 수 있습니다.

RFC 2661은 그 제어 연결 인증을 선택 사항으로 만들며, 이는 같은 실수가 두 서버에서 다른 증상을 만드는 이유를 설명합니다. 터널 비밀값을 한 번도 설정하지 않은 배포는 이 단계를 완전히 건너뛰고, 한쪽에만 설정한 배포는 PPP가 제안되기도 전에 실패합니다. 그다음 PPP가 PAP, CHAP 또는 MSCHAPv2로 사용자를 인증하고 그 이름을 로컬, chap-secrets 또는 RADIUS에 있는 계정 저장소로 넘깁니다. 그 시점의 잘못된 비밀번호는 여전히 작동하는 터널과 실패한 세션을 남깁니다.

설정을 편집하기 전에 멈출 지점을 읽으세요

먼저 ipsec --version을 실행해 상태 출력이 strongSwan의 것인지 Libreswan의 것인지 확인한 다음, 클라이언트 대화 상자가 아니라 서버 로그를 읽으세요. 서버가 어느 단계가 거부했는지 기록하기 때문입니다.

보통 IKE나 제안에 대한 불만이 첫 번째 단계, 제어 연결 메시지가 두 번째 단계, PPP 방식이나 계정 거부가 세 번째 단계라는 한 줄이 티켓을 정리합니다. 그 줄을 타임스탬프와 함께 티켓에 복사하세요. 클라이언트 쪽에서 추측하는 것은 이미 가진 유일한 증거를 낭비합니다.

키 자료와 비밀번호는 그 붙여넣기에서 빼고, 단계 이름이 작업을 배분하며, 유출된 사전 공유 키는 더 나쁜 결과로 티켓을 다시 열게 됩니다.

첫 번째 단계: IPsec에 연관이 있습니까?

strongSwan에서는 ipsec statusall을, Libreswan에서는 ipsec whack --status을 실행하고 카운터가 영이 아닌 자식 연관이 성립했는지 찾으세요. ip xfrm state은 둘 다에서 커널의 관점을 보여줍니다. 카운터가 증가하는 SA 쌍이 설치되어 있으면 첫 번째 단계가 끝난 것이므로 계속 진행할 수 있습니다.

연관이 전혀 없으면 피어 주소, 제안 집합 또는 사전 공유 키를 가리키며, 때로는 UDP 500을 다시 쓰면서 UDP 4500을 버리는 장비를 가리킵니다. 성립한 뒤 몇 초 만에 사라지는 연관은 보통 자격 증명 문제가 아니라 양쪽 끝의 수명 불일치입니다. 무엇이든 다시 입력하기 전에 양쪽이 같은 암호화 및 해시 제안을 나열하는지 확인하세요. 그렇지 않으면 어떤 키도 영원히 작동하지 않습니다.

연관이 없는 동안에는 멈추세요. 그 시점에 PPP 옵션을 편집해도 아무것도 바뀌지 않으며 진짜 결함을 다음 사람에게서 숨길 뿐입니다.

두 번째 단계: L2TP 제어 연결이 인증되었습니까?

IPsec이 올라오면 그전에는 PPP가 시작될 수 없으므로, L2TP 데몬이 성립 상태에 도달하는 제어 연결을 관찰하세요. 제어 연결에서의 거부는 양쪽 끝의 터널 비밀값이 다르거나, 한쪽이 다른 쪽이 절대 보내지 않는 비밀값을 요구한다는 뜻입니다. 클라이언트는 흔히 shared secret이라는 라벨이 붙은 하나의 필드를 노출하며, 그것은 보통 L2TP가 아니라 IPsec에 속합니다. 그것을 채워도 터널 비밀값이 설정되지 않고, 비워도 비활성화되지 않습니다.

어느 쪽도 터널 비밀값을 설정하지 않았다면 이 단계를 건너뛰고 제어 연결 실패를 대신 도달성 문제로 다루세요. UDP 1701이 데몬에 도달하는지, 양쪽 끝이 같은 캡슐화에 합의하는지 확인하세요. 그 두 조건 중 하나만을 위해 작성된 방화벽 규칙은 절반만 열리는 연결의 흔한 원인입니다.

PPP 협상을 시작하는 세션만이 실제로 터널 단계를 통과한 것입니다.

세 번째 단계: PPP가 계정을 거부하고 있습니까?

PPP 실패는 밖에서 보면 다르게 보이며, 터널은 성립하고 세션은 시작되고, 데몬은 인증 방식 실패나 계정 거부를 기록합니다. 그 메시지에 명시된 방식을 읽으세요. PAP와 CHAP은 서로 다른 이유로 실패하며, 하나를 거부하는 서버는 그것만 제안하는 클라이언트를 거부합니다.

Linux 서버에서는 데몬이 PPP에 넘기는 옵션 파일, 보통 /etc/ppp/options.xl2tpd을 확인하고 어떤 방식이 허용되며 계정이 어디에서 해석되는지 확정하세요. RADIUS에는 있지만 로컬 비밀 파일에는 없는 이름은 깔끔하게 실패하며 잘못된 비밀번호처럼 보입니다. 그다음 클라이언트가 서버가 허용하는 방식을 제안하는지, 서버가 협상을 거부하는 더 강한 방식을 제안하지는 않는지 확인하세요. 이 단계를 고치려고 사전 공유 키를 바꾸는 것은 오후를 낭비할 뿐 아무것도 바꾸지 않습니다.

세션이 마침내 올라오면 주소 할당, DNS, 경로는 아직 확인되지 않았습니다, 그리고 각각은 자기 방식으로 조용히 실패합니다. 메모에서 세 계층을 분리해 두고, 올바른 키와 잘못된 계정은 항상 실패하며, 한 계층을 고쳐도 다른 계층은 고쳐지지 않는다는 점을 기억하세요.