Linux에서 IPsec 없이 L2TP: xl2tpd, pppd, NAT

순수 L2TP는 봉투에 담긴 PPP일 뿐 그 이상이 아닙니다. 프레임을 나르지만 암호화하지 않고 상대가 누구인지도 증명하지 않으므로, 거의 모든 배포가 그 아래에 IPsec을 깝니다. 꾸밈없는 구성을 택할 정직한 이유는 여전히 있습니다: 실험실 벤치, 마이그레이션 단계, 또는 이미 다른 보호 경로 안에 있는 회선입니다.

그래도 진행한다면 그 경고를 설계 메모에 적어 두십시오. 다음은 Debian과 RHEL 계열 호스트에서 제가 쓰는 운영 경로입니다: 어느 파일이 무엇을 맡는지, 고전적인 멈춤을 막는 MTU, 그리고 터널을 쓸모 있게 만드는 전달 규칙입니다.

세 파일이 일을 나눕니다

xl2tpd는 제어 연결을 종료하고 각 세션을 PPP 데몬에 넘기므로, 설정은 서로의 파일을 절대 읽지 않는 두 프로그램에 나뉩니다. 리스너는 /etc/xl2tpd/xl2tpd.conf에 있고, [lns default] 섹션 안에서 주소 풀을 ip range로, 서버 쪽을 local ip로, PPP 인계를 pppoptfile로 지정합니다. require authentication = yes를 켜고 length bit와 flow bit는 켜 둔 채로, 호스트의 다른 무엇도 쓰지 않는 풀을 고르십시오.

PPP 정책은 그 옵션이 가리키는 파일, 보통 /etc/ppp/options.xl2tpd에 둡니다: auth, pap·chap·mschap 거부, require-mschap-v2, MTU와 MRU 1460, 그리고 회선이 올라온 뒤 클라이언트가 닿을 수 있는 DNS 주소입니다. 자격 증명은 다시 세 번째 파일인 /etc/ppp/chap-secrets에 있으며, 두 번째 필드는 LNS 섹션 이름과 맞아야 하고 네 번째 필드는 풀에서 특정 주소를 고정할 수 있습니다.

터널이 연결된 뒤 멈추는 이유

1500바이트 Ethernet 프레임은 이미 자기 헤더에 바이트를 쓰는 경로에 들어가지 않습니다. 바깥 IPv4 헤더가 20, UDP가 8, L2TP 헤더가 약 12를 차지하므로 PPP와 그 페이로드에 1460이 남습니다. 이 작은 값을 PPP에서 알리는 것이 큰 패킷이 조각나거나 중간 어딘가에서 조용히 버려지는 것을 막습니다.

증상은 실제 트래픽이 올 때까지 건강해 보이는 터널입니다: ping과 제어 메시지는 지나가고 파일 복사는 멈추며, 로그에는 아무 설명이 없습니다. 양쪽 끝에서 MTU와 MRU를 함께 낮추십시오. 클라이언트만 조정하면 단단한 멈춤이 간헐적 멈춤으로 바뀌어 진단이 더 어려워집니다.

포트 하나가 두 대화를 나릅니다

UDP 1701은 프로토콜의 양쪽 절반 아래에 있고, 그 한 가지 사실이 설정의 다른 어느 부분보다 많은 방화벽 규칙을 깨뜨립니다. 먼저 제어 연결 시작 요청과 그 응답이 오고, 뒤따르는 세션 요청과 확인은 식별자 쌍 이상을 세우지 않습니다. 그다음 PPP가 맡아 링크 제어, 인증, 주소를 정하는 IP 제어 프로토콜로 이어집니다. 각 단계는 로그에서 자기만의 어휘를 쓰고, 어느 것도 스스로를 L2TP 장애라고 알리지 않습니다.

바로 그 순서로 캡처를 읽으면 어느 단계가 실패했는지 알 수 있고, PPP 인증 실패는 xl2tpd를 고쳐서 해결되지 않습니다. 공유 포트는 또 다른 흔한 실패를 설명합니다: 흐름의 첫 패킷만 허용하는 규칙은 세션을 세우게 두고 나서 전송을 막습니다. 1701은 대화 전체에 대해 양방향으로 허용하십시오.

터널을 쓸모 있게 만들기: 전달과 NAT

세션만으로는 서버에 닿을 뿐입니다. 클라이언트의 인터넷 접속에는 전달, 업링크에서 풀을 위한 NAT 규칙, 그리고 회선이 올라온 뒤 실제로 질의할 수 있는 DNS가 필요합니다. 풀은 LAN 범위에서 벗어나 있어야 하며, 그렇지 않으면 클라이언트로 향한 응답이 터널로 되돌아가지 않고 로컬에서 전달됩니다.

서버에서는 sysctl -w net.ipv4.ip_forward=1로 전달을 켜고, iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE로 풀을 변환한 뒤, -i ppp0 -o eth0에 대한 FORWARD 규칙으로 나가는 터널 트래픽을, 미러 규칙과 -m state --state RELATED,ESTABLISHED로 돌아오는 트래픽을 받아들입니다. 이 규칙들을 재부팅 뒤에도 유지하십시오: 그것들 없이 돌아온 서버는 고장 난 L2TP 설정과 똑같이 보입니다.

서버 자체의 LAN에 닿는 것은 다른 작업입니다: LAN 라우터에 풀을 위한 반환 경로를 추가하거나, 서버에서 proxy ARP를 쓰십시오. LAN 안의 무언가가 클라이언트를 직접 향해야 하는데 클라이언트를 NAT 뒤에 숨기는 것은 나중의 두 번째 디버깅 세션을 예약할 뿐입니다.

꾸밈없는 스택이 하지 않는 일과 확인 방법

이 스택의 어느 부분도 PPP 프레임을 암호화하지 않고, 실제로 고른 서버로서 원격 쪽을 인증하는 것도 없습니다. MS-CHAPv2는 보고만 하는 도청자로부터 자격 증명 교환을 보호하지만, 경로에 자리한 공격자는 여전히 세션을 방해할 수 있습니다. Windows 기본 클라이언트는 IPsec과 함께일 때만 L2TP를 제공하므로 Linux, 라우터 펌웨어, 서드파티 클라이언트를 상대로 계산하십시오. 꾸밈없는 구성을 진단 디딤돌로 다루고, 결코 멈출 자리로 삼지 마십시오.

정해진 순서로 확인합니다: xl2tpd -D를 포그라운드에서 실행하고, PPP 단계를 위해 저널을 지켜보고, 양쪽 끝에서 ip addr로 할당된 주소를 읽은 다음, 세션이 올라온 뒤 데이터가 흐르는지 확인하려고 UDP 1701을 캡처합니다. 네 가지가 모두 맞는데도 트래픽이 실패하면 원인은 라우팅, NAT, MTU이며 L2TP 자체가 아닙니다.