L2TP는 연결되지만 PPP 협상이 실패한다: 어느 단계인가?

IPsec 터널이 맺어지고 클라이언트가 보호된 피어를 표시한 다음, 무언가 사설 서브넷에 도달하기 전에 연결이 끊긴다. 그 틈은 PPP가 자기 일을 하는 것이다: 링크 옵션, 사용자 인증, 주소 할당은 모두 암호화된 터널이 존재한 뒤에 일어난다. 첫 단계 교환이 성공해도 비밀번호나 내부 주소가 주어지지는 않는다. 단계를 순서대로 읽으면 실패는 대개 스스로를 지목한다.

터널은 첫 번째 계층일 뿐이다

L2TP는 IPsec으로 보호된 터널 안에서 PPP 프레임을 운반하므로, 패킷이 라우팅되려면 독립적인 두 협상이 성공해야 한다. 바깥 협상은 양 끝이 키와 신원에 합의했음을 증명한다. 안쪽 협상은 링크 매개변수, 사용자가 인증되는지, 클라이언트가 어떤 주소를 받는지를 결정한다.

PPP 내부의 실패는 상태등을 하나만 표시하는 모든 클라이언트에서 고장난 터널처럼 보인다. 이를 터널 문제로 다루면 키를 다시 만들고 서비스를 재시작하며 결국 한 번도 틀린 적 없는 공유 비밀을 교체하게 된다. 쓸모 있는 구별은 값싸다: 피어 교환이 끝났고 클라이언트가 사용자 이름 입력이나 인증 단계로 넘어갔다면 터널은 정상이다. 그 지점 이후의 모든 것은 PPP에 속한다.

성공한 마지막 단계를 읽어라

로그를 앞으로 훑어 완료되지 않은 첫 단계에서 멈춰라. 먼저 LCP, 다음 인증, 다음으로 IPv4 매개변수를 위한 IPCP가 온다.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

LCP 시간 초과는 양 끝이 기본 링크 옵션에 합의하지 못했다는 뜻이며, 나쁜 비밀번호가 아니라 프로필 불일치나 내부 프로토콜 차단이다. 명시적 인증 거부는 반대 경우다: 링크는 올라왔고 한쪽이 자격 증명을 거부했다. 인증 성공 후의 IPCP 시간 초과는 주소 풀이나 서버 정책을 가리킨다. 각각 담당자도 수리 방법도 다르기 때문에 마지막 오류 문구보다 단계가 더 중요하다.

티켓에 단계 이름과 함께 로그 발췌를 남겨라. 단계 경계 없이 붙인 꼬리는 다음 읽는 사람에게 추측을 부추기고, 여기서의 추측은 한 시간을 쓴다.

클라이언트와 서버 사이의 합의

양 끝이 같은 인증 방식을 받아들여야 하고, 저장된 프로필은 서버가 지난 분기에 폐기한 방식을 요구할 수 있다. 관리형 배포는 서버 쪽도 감추며, 거기서는 거부 사유가 보통 장치가 아니라 사용자에게 기록된다.

다섯 가지 방식을 제시하는 클라이언트는 어느 것이 실패했는지 가리므로, 모든 레거시 옵션 대신 지원되는 방식을 하나만 켜라. 관리자에게 서버 쪽 정책과 정확한 거부 사유를 요청하되, 이는 누구도 비밀번호를 공개할 것을 요구하지 않는다. 클라이언트 하나를 구하려고 켠 레거시 방식은 그 파일을 복사한 모든 프로필로 퍼지는 경향이 있다.

로그인이 아니라 주소를 확인하라

로그인이 끝났다고 쓸 수 있는 세션이 아니다. IPCP가 내부 주소를 협상하며, 고갈된 풀이나 클라이언트를 거부하는 정책은 여전히 연결된 터널에 라우팅할 대상을 남기지 않을 수 있다.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

먼저 내부 주소를 확인하고, 그다음 실제로 필요한 자원의 경로와 리졸버를 보라. 내부 주소는 웹사이트가 보고하는 공용 출구가 아니며, 둘을 혼동하면 없는 유출을 찾아 나서게 된다. 사설 자원은 DNS 실패가 라우팅 실패로 오해되지 않도록 이름보다 주소로 먼저 시험하라.

단계와 방식과 주소를 한 메모에 적고 날짜를 붙여라. 같은 계정이 한 달 뒤 다시 실패하면 그 메모가 오 분 점검과 새 조사의 차이다. 다른 단계의 실패는 클라이언트가 하나의 대화상자만 보여도 서로 다른 사건이다.