PPTP와 L2TP/IPsec이 사용자 이름 입력 전에 멈추는 이유는 무엇인가요?

사용자 이름 입력 요청이 없다는 것은 진단상 선물입니다: PPP가 아직 시작되지 않았으므로 계정, 비밀번호, 도메인 정책은 아직 조회되지 않았습니다. PPTP 또는 L2TP/IPsec 연결에서 클라이언트가 자격 증명을 요구하는 시점은 터널이 존재하고 서버가 PPP 세션을 시작한 뒤입니다. 그 순간 이전에 실패할 수 있는 것은 전송, 키 교환, 터널 설정이며, 이는 «VPN이 고장 났다»보다 훨씬 작은 범위입니다.

요청이 없다는 것은 장애를 세 단계로 좁혀 줍니다

눈에 띄게 성공한 마지막 단계는 단계마다 담당과 해결책이 다르므로 적어 두세요. 두 단계 앞에서 막혀 있는데 계정 설정을 추측하는 것이 오후를 날리는 방법입니다.

요청 없이 시간이 초과된 클라이언트는 IPsec 연결을 얻지 못한 것이므로, 장애는 IKE에 있거나 패킷이 게이트웨이에 도달하는지 여부에 있습니다. 자격 증명을 확인 중이라고 알린 뒤 끊기는 경우는 메시지가 시사하는 것보다 더 나아간 것입니다. 요청 뒤에 거부가 오는 것은 PPP 인증이며, 그 내용은 이 글이 아니라 계정 글에 속합니다.

첫 단계: 방화벽이 조용히 버리는 프로토콜

PPTP는 제어 채널에 TCP 1723을, 데이터 경로에 IP 프로토콜 47을 필요로 하며 둘은 따로 이동합니다. 많은 네트워크가 1723은 전달하고 프로토콜 47은 버리기 때문에, 협상은 되지만 아무것도 나르지 않는 터널이 만들어집니다. NAT를 수행하는 라우터에는 GRE 지원 통과도 필요하며, IPv6만 있는 접속 경로는 어떤 구성에서도 PPTP를 나를 수 없습니다.

IPsec 위의 L2TP는 IKE에 포트 500을, NAT 통과에 포트 4500을 쓰고, 그다음 L2TP 트래픽 자체를 1701에 감싸며, 연결이 생긴 뒤에는 ESP가 보호된 페이로드를 나릅니다. 제어 포트 두 개만 허용하고 ESP를 허용하지 않으면 정확히 제목의 증상이 나타납니다: 눈에 보이는 진행 뒤, 자격 증명 대화상자 이전에 클라이언트가 죽습니다. 휴대폰 핫스폿에서 시험하는 것은 클라이언트 문제와 경로 문제를 가르는 저렴한 방법입니다.

둘째 단계: 키가 아닌 키, 제시되지 않는 제안

일치하지 않는 사전 공유 키는 빠르고 조용히 실패하며, 흔한 형태는 화면에서는 맞아 보이지만 붙여넣은 줄 바꿈이나 끝의 공백을 품은 키입니다. Linux 클라이언트에서는 대화상자가 반드시 진실의 근원은 아닙니다: NetworkManager의 L2TP 플러그인은 비밀을 /etc/ipsec.d/ 아래 파일에 보관하고, /etc/ipsec.secrets 이 아직 포함하는 오래된 연결별 파일이 방금 입력한 파일 대신 사용됩니다. 그 파일을 안전한 곳에 복사하고 포함 경로에서 빼낸 뒤, 키를 손으로 다시 입력하세요.

이 단계의 나머지 절반은 제안입니다. 양쪽이 같은 1단계 알고리즘 집합 — 암호화, 무결성, Diffie-Hellman 그룹 — 과 2단계에 맞는 ESP 변환에 합의해야 하며, 그렇지 않으면 연결이 아예 형성되지 않습니다. 3DES, SHA1, MODP1024만 제시하는 게이트웨이는 더 강한 알고리즘으로 설정된 클라이언트를 거부하고, 그 로그는 거부된 변환을 지목합니다. 서비스를 다시 시작하는 대신 로그를 읽으면 로그가 불일치를 지목합니다. 포럼 스레드에서 알고리즘 문자열을 복사하는 대신 게이트웨이에 실제로 어떤 변환을 협상할지 물으세요: 그 주소를 향한 ike-scan 이 협상할 변환을 돌려줍니다. 유일한 제안이 정책상 더는 허용되지 않는 암호라면, 수정은 클라이언트를 낮추는 것이 아니라 게이트웨이 쪽에 있습니다.

Windows에서는 키와 인증 방법이 VPN 프로필에 있고, 불일치는 자격 증명 요청 이후가 아니라 그 이전에 드러납니다. 수신 측이 Windows Server라면 원격 액세스 역할이 설치되어 있는지, 인증서가 클라이언트가 접속하는 이름과 일치하는지, 어떤 포트 필터도 위 프로토콜보다 좁지 않은지 확인하세요.

셋째 단계: 터널은 있는데 PPP가 시작되지 않음

IKE가 끝났는데도 요청이 나타나지 않으면 방화벽이 아니라 터널 데몬을 보세요. L2TP에는 Linux의 xl2tpd나 kl2tpd, Windows의 원격 액세스 서비스처럼 UDP 1701에서 수신하는 무언가가 필요하며, 설치되었지만 중지된 서비스는 클라이언트 쪽에서 버려진 패킷과 똑같이 보입니다. 이미 확인한 규칙을 다시 열기 전에 수신자를 확인하세요. 그다음 PPP가 협상해야 하며, 첫 LCP 교환이 조용한 실패가 보통 내려앉는 지점입니다.

이 단계의 함정 하나는 네트워크 장애가 전혀 아닙니다: Windows는 특정 VPN 유형의 연결을 한 번에 하나만 허용하므로 두 번째 시도는 오류 937, «이 유형의 다른 연결이 사용 중입니다»를 돌려줍니다. 이는 로컬 규칙이며, 우회 방법은 다른 기기, 다른 터널 유형, 또는 이미 존재하는 하나의 연결을 공유하는 것입니다.

추측하지 말고 단계 순서대로 로그를 읽으세요

클라이언트를 중지하고 다시 시작한 뒤, 구성 요소가 로그를 쓰는 순서대로 읽으세요. 즉 먼저 IPsec 데몬 — strongSwan 또는 Libreswan이며, ipsec --version 가 어느 것인지 알려 줍니다 — 다음 L2TP 데몬, 다음 pppd입니다. 장애 직전에 마지막으로 기록한 구성 요소가, 그 순서에서 뒤에 오는 것은 아예 실행되지 않았기 때문에, 조사할 단계를 표시합니다.

캐시에서 다시 연결하는 클라이언트는 교환의 일부를 건너뛰고 오래된 결과를 재현할 수 있으므로, 저장된 세션이 아니라 새 연결로 확인하세요. 도달성, 키 교환, 터널, PPP를 하나씩, 이 순서로 확인하세요. 그러면 나타나지 않던 요청은 수수께끼가 아니라 실제로 따라갈 수 있는 목록의 둘째 줄이 됩니다. 그 목록은 네트워크 팀에 넘기는 것이기도 하며, 그렇지 않으면 시작되지 않은 데몬에 사는 장애 때문에 방화벽을 조사하라는 요청을 받게 됩니다.