어느 VPN 단계에서 실패했는가: IPsec, L2TP 제어, PPP 인증
마지막으로 성공한 단계를 찾고 그 계층만 고치십시오: IPsec, L2TP 제어 채널, PPP 인증 또는 주소 할당.
암호를 바꿨는데 아무것도 움직이지 않았다면 실패는 PPP에 있지 않았습니다. L2TP/IPsec는 다섯 가지 전혀 다른 인계에 대해 하나의 연결 오류를 보고하며, 각 인계에는 고유한 수리가 있습니다. 거꾸로 진행하십시오: 마지막으로 성공한 단계를 찾아 그 뒤에 오는 것만 바꾸십시오. 아래 순서는 어떤 증거를 먼저 모을지도 결정합니다.
네 가지 질문에 순서대로 답하십시오
일부 클라이언트는 프로필을 끊었다 다시 연결할 때까지 이전 오류를 계속 보여 주므로 새 시도를 강제하십시오. 그다음 이렇게 답하십시오: IPsec 보안 연관이 있었는지, L2TP 제어 연결과 호출이 나타났는지, PPP가 인증 판정에 도달했는지, IPCP가 클라이언트에 주소를 주었는지. 첫 번째 아니오가 고칠 단계입니다. 그 뒤는 모두 검증되지 않았으므로 연관이 없었다면 거부된 사용자 이름은 아무것도 증명하지 못합니다.
비교하기 전에 양쪽 시계를 동기화하십시오. IPsec을 통과하고 PPP에서 실패한 재시도는 클라이언트가 마지막 메시지만 보여 주고 서버 로그가 이전 시도를 아직 보관하고 있을 때 하나의 실패처럼 보입니다. 가장 시끄러운 줄이 아니라 타임스탬프로 읽으십시오.
사용자의 스크린숏만 있을 때는 가장 값싼 구분에 기대십시오. 잘못된 사전 공유 키와 절대 응답하지 않는 xl2tpd는 Windows 대화 상자에 같은 문구를 만들지만, 하나는 양쪽에서 바꿔야 하는 비밀이 필요하고 다른 하나는 서버 자체에서 데몬을 시작하거나 방화벽 규칙이 필요합니다, 중간 장치는 전송 모드 IPsec이 감싼 뒤에는 내부 1701을 버릴 수 없으므로 없는 경로 필터를 찾지 마십시오.
각 계층이 실제로 맡는 것
IPsec은 두 피어 사이의 패킷을 보호하고, L2TP는 그 보호된 경로 안에서 PPP 세션을 운반하므로 RFC 3193은 자체 터널 대신 전송 모드를 규정합니다. 클라이언트 레이블은 L2TP라고 하므로 터널과 로그인이 하나의 메커니즘처럼 느껴집니다. 그렇지 않습니다, L2TP 제어 연결은 배포가 활성화한 곳에서 터널 끝점을 인증하고, PPP는 서버 정책에 따라 CHAP, PAP 또는 MS-CHAPv2로 사용자를 별도로 인증합니다.
이 구분이 사람들이 계속 혼동하는 두 비밀을 설명합니다. 사전 공유 키는 IPsec 피어를 인증합니다. 사용자 이름과 암호는 PPP에 사용자를 식별시킵니다. 인증서로 인증하는 프로필에 Windows 공유 비밀을 다시 입력해도 실패 단계에서는 아무것도 바뀌지 않으며, PPP 암호를 편집해도 빠진 보호 채널을 제공할 수 없습니다. 같은 자제가 신원 확인에도 적용됩니다, 터널을 얻기 위해 피어 신원이나 인증서 검증을 끄지 마십시오, 그때 연결되는 것은 피어가 아니라 경로입니다.
인증도 PPP의 끝이 아닙니다. 사용자가 수락된 뒤 IPCP는 클라이언트 주소와 서버가 내주려는 DNS 및 WINS 옵션을 협상합니다. 클라이언트는 CHAP나 MS-CHAPv2를 통과하고도 주소 없이 끝날 수 있으며, 이는 라우팅 문제가 아니라 PPP 내부의 실패입니다. IPsec 없는 순수 L2TP는 유효하고 보호되지 않은 채로 남으므로 연결 성공은 트래픽이 보호된다는 것을 결코 증명하지 못합니다, 클라이언트 레이블이 아니라 서버가 무엇을 요구하는지 확인하십시오.
처음 빠진 단계에서 결정하십시오
표를 처음 빠진 항목 기준으로 왼쪽에서 오른쪽으로 읽으십시오. 오른쪽 열이 그 시점에서 가치 있는 유일한 작업이며, 그 왼쪽은 모두 이미 증명되었으므로 다시 시험하면 정보를 더하지 않고 장애 대응 시간만 태웁니다.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
세 행은 경고가 필요합니다. 1701 행은 NAT 뒤의 Windows 클라이언트가 보통 떨어지는 곳으로, 연관이 완료된 뒤 아무것도 도착하지 않으며 원인은 나쁜 암호가 아니라 캡슐화입니다. IPCP 행은 경로 문제로 잘못 읽히는 행으로, Windows가 빠진 주소를 오류 720에 싸고 트레이 아이콘은 연결이 실패했다고만 말합니다. 이 실패는 인증 뒤, 라우팅 앞에 있습니다, 마지막 행은 트레이 아이콘이 끊김이라고 말해도 IPsec 실패가 전혀 아닙니다.
계층을 분리하는 명령
strongSwan을 쓰는 Linux 서버에서 swanctl --list-sas는 설정된 연관을 피어 신원과 함께 나열하고, ipsec statusall는 더 오래된 strongSwan 및 libreswan 호스트를 포함합니다. 그 아래 ip xfrm state는 커널의 실제 연관을 보여 주고, ss -lunp | grep 1701는 xl2tpd가 어디에 묶였는지 증명합니다. 제어 연결과 호출이 나타나는 것을 보려면 xl2tpd -D를 전면에서 실행하고, 제안된 방식과 응답을 보려면 /etc/ppp/options.xl2tpd에서 pppd 디버그를 켜십시오.
로그가 성공적인 인증을 보여 주면 다음 질문은 IPCP가 완료되었는지입니다. /etc/xl2tpd/xl2tpd.conf의 [lns default] 절에 있는 ip range에 아직 빈 주소가 있는지, 클라이언트가 기대한다면 /etc/ppp/options.xl2tpd가 정말 ms-dns와 ms-wins를 담고 있는지 확인하십시오. 고갈된 풀과 빠진 DNS 옵션은 회선에서 다르게 보입니다. 전자는 주소 없이 720을 남기고, 후자는 주소는 주지만 해석기가 없어 이름이 실패하는 동안 원시 주소로의 ping은 됩니다, 둘 다 암호를 다시 입력해서 고쳐지지 않습니다.
클라이언트에서 NetworkManager의 L2TP 플러그인이 pppd 대화를 저널에 쓰므로 journalctl -u NetworkManager -b는 보통 터널은 올라갔고 인증은 거부됨 상태와 터널이 전혀 없음 상태를 구분합니다. Windows에서는 Get-VpnConnection가 프로필의 실제 인증 설정을 보고하고, 이벤트 뷰어의 Application 아래 RasClient 이벤트가 실패한 구성 요소를 지목합니다. 대화 상자가 너무 모호하면 netsh ras set tracing * enable를 켜십시오.
캡처에는 한 가지 주의가 필요합니다. 전송 모드 IPsec에서는 내부 UDP 1701이 암호화되므로 외부 인터페이스의 캡처에는 ESP 또는 NAT-T의 경우 UDP 4500이 보이고 L2TP는 전혀 보이지 않습니다. 캡처에 1701이 없는 것은 예상된 일이며 포트 차단의 증거가 아닙니다, ESP나 4500 카운터가 움직이는지 보십시오.
NAT, MTU, 경로: 스택이 당신을 오도하는 곳
NAT는 무언가 인증되기 전에 가정을 깨뜨립니다. ESP는 자체 IP 프로토콜이므로 피어가 캡슐화하지 않으면 변환 장치가 이를 버리며, UDP 4500이 바로 그것을 제공합니다. 자체가 가정용 공유기나 클라우드 NAT 게이트웨이 뒤에 있는 Windows 서버에서는 PolicyAgent 키 아래 AssumeUDPEncapsulationContextOnSendRule를 2로 설정하고 컴퓨터를 다시 시작할 때까지 IPsec 단계가 오류 789로 실패하며, 그 실패는 닫힌 포트와 구별되지 않습니다. NAT 뒤의 클라이언트는 더 쉽습니다, 서버에 공인 주소가 있으면 UDP 4500의 NAT-T가 이들을 운반하며 그 값은 관여하지 않습니다.
PPP가 올라오면 블랙홀 MTU가 죽은 터널을 흉내 냅니다. 작은 패킷은 지나가고, TLS 핸드셰이크나 페이지 로드가 멈추며, 클라이언트는 여전히 연결됨을 표시할 수 있습니다. 서버를 탓하기 전에 인터페이스 MTU를 낮추거나 게이트웨이에서 MSS를 조이십시오. 분할 터널 라우팅도 사기꾼입니다, 잘못된 마스크로 밀어낸 서브넷은 터널을 건강하게 두고 한 응용 프로그램을 도달 불가능하게 만듭니다, 사설 호스트 이름은 자체 홉을 더합니다, 질의가 로컬 해석기를 통해 나가면 어떤 경로도 시험되기 전에 이름 확인이 실패합니다.
자격 증명을 만지기 전의 점검 목록
목록을 순서대로 진행하고 처음 실패하는 항목에서 멈추십시오. 모든 단계가 값싸고, 각 단계는 편집의 한 종류를 통째로 배제합니다.
- 연관이 양쪽에 있는지, 연결됨 레이블이 아니라 피어 신원으로 맞춰 확인하십시오.
- UDP 1701이 xl2tpd에 도달하는지 확인하십시오, 호출 없는 연관이 당신의 실패입니다.
- 암호가 틀렸다고 가정하기 전에 PPP의 판정을, 인증되었다면 IPCP 결과를 읽으십시오.
- 이제서야 서버가 기대하는 형식으로 자격 증명을 다시 입력하십시오, 도메인 접두사는 계정을 바꿉니다.
- 그래도 실패하면 양쪽을 정렬된 타임스탬프로 캡처하고 단계별로 비교하십시오.
두 번째 단계에서 멈춘다는 것은 경로나 캡슐화 문제이며 어떤 암호 편집도 그것을 움직이지 않습니다. 세 번째 단계에서 멈춘다는 것은 로그가 이미 고칠 방식이나 주소 풀을 지목했다는 뜻입니다. 어느 경우든 다음 변경은 정당화할 수 있는 것이 되고, 관여한 적 없는 설정을 맴도는 일을 그치게 됩니다.