가정용 라우터 뒤의 PPTP 서버: 먼저 1723과 GRE를 고치세요

가정용 라우터 뒤에서 PPTP는 서로 무관한 두 가지 방식으로 실패하며, 둘을 혼동하면 저녁 하나가 통째로 날아간다. 하나는 전달의 구멍으로, 라우터가 TCP 1723은 통과시키고 IP 프로토콜 47은 버리므로 클라이언트는 오류 619에서 멈춘다. 다른 하나는 크기 문제로, 터널은 올라가고 인증도 되지만 전체 크기 패킷이 지나가야 할 때 멈춘다. 둘 중 어느 쪽인지 가려내는 것이 첫 번째 실제 단계이며, 나머지는 어느 브랜드가 나은지가 아니라 내 라우터가 무엇을 표현할 수 있는지의 비교다.

두 개의 전송, 그리고 포트를 가진 쪽은 하나뿐

PPTP는 TCP 1723의 제어 연결과 확장 GRE에 싸인 PPP 프레임, 즉 IP 프로토콜 47이라는 두 전송으로 나뉜다. GRE에는 포트 번호가 없으므로 웹 화면이 그 항목을 무엇이라 부르든 포트 1723 전달로 쓰인 규칙은 그것을 덮을 수 없다. 가정용 라우터는 보통 프로토콜 규칙 대신 PPTP 패스스루라는 체크상자를 제공하며, 그 상자는 프로토콜 47을 방화벽 너머로 통과시키고 NAT에 GRE 흐름을 추적하는 방법을 가르치는 두 가지 일을 한다. 리눅스 라우터에서는 이 두 가지가 별도 모듈과 별도 규칙이므로 반만 설정한 패스스루도 제어 채널은 동작한다. 무엇이든 바꾸기 전에 어느 절반이 있는지 확인하라.

서버 자체의 방화벽도 라우터 주소에서 오는 프로토콜 47을 허용해야 한다. 1723/tcp만 받아들이는 호스트 방화벽은 LAN 안쪽에서 오류 619를 재현하므로, 끊긴 전달과 끊긴 호스트 규칙이 똑같아 보인다.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

모듈이 없다면 sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre 로 불러오고, 도우미를 잊는 재부팅이 동작하던 터널을 다시 오류 619로 되돌리므로 그 로딩을 영구화하라. 전달 규칙은 프로토콜 47을 서버 주소 방향으로만 허용하면 되고 LAN 전체일 필요는 없다. RFC 2637 정의가 제어 경로와 데이터 경로를 분리하기 때문에 단일 포트 전달 화면으로는 PPTP를 온전히 설명할 수 없다.

패스스루 체크상자냐, 명시적 프로토콜 규칙이냐

방화벽만 여는 패스스루 체크상자가 호출 식별자를 다시 쓰는 ALG보다 정답에 가깝다. 방화벽 쪽은 예측 가능하고, 프로토콜 47은 통과시키거나 버리는 둘 중 하나이며 카운터가 어느 쪽인지 알려준다. 다시 쓰는 쪽이 제조사마다 다른 지점으로, PPTP의 호출 식별자는 터널마다 다르고 그것을 편집하는 NAT는 손대는 모든 호출을 추적해야 한다. 클라이언트 하나는 붙고 둘은 붙지 않을 때 ALG가 첫 번째 용의자다.

1723에 대한 목적지 NAT 규칙에도 소유권 문제가 있다. 오래된 규칙이 아직도 서버를 멈춘 호스트로 1723을 보내면 패킷은 닫힌 포트로 떨어지고 라우터 자체의 PPTP 서비스가 응답을 멈춘다. 방화벽 장애처럼 읽히지만 실체는 낡은 목적지이므로, 다음 규칙을 더하기 전에 규칙과 목적지를 읽어라. PPTP를 스스로 종단하는 라우터에서는 WAN 규칙이 내장 서비스와 경쟁하므로 1723과 프로토콜 47의 소유자를 하나로 정하라.

같은 NAT 뒤의 클라이언트 두 대가 단순한 전달과 영리한 전달을 가르는 사례다. 호출 식별자를 다시 쓰지 않고 프로토콜 47을 전달하는 쪽이, 그것을 고치려는 도우미보다 대개 더 잘 동작한다.

라우터를 탓하기 전에 터널을 측정하라

PPTP는 쓸 수 있는 페이로드를 줄이며, 그 축소는 수수께끼가 아니라 산수다. 터널 패킷마다 바깥 IP 헤더, 확장 GRE 헤더, PPP 헤더, 암호화가 있으면 MPPE 헤더가 붙는다. 경로가 그 결과 프레임을 나르지 못하면 작은 패킷은 지나가고 로그인은 끝나지만, 파일 전송이나 TLS 핸드셰이크가 전체 크기 패킷을 보내는 첫 순간 세션이 멈춘다.

추측하지 말고 계산하라. 확장 GRE는 8바이트, PPP는 4바이트, MPPE는 4바이트, 바깥 IP 헤더는 20바이트이므로 터널은 어떤 페이로드보다도 먼저 36바이트를 먹는다. 1492에서 끝나는 PPPoE WAN에서는 들어가는 가장 큰 PPP MTU가 1492 빼기 36, 즉 1456이다. PPP 옵션에서 mtu 와 mru 를 그 값으로 설정하고 단편화하지 않는 핑으로 다시 시험하라.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

핑이 재는 것은 경로이지 터널이 아니며, 1464바이트 페이로드에 28바이트의 IP와 ICMP 헤더를 더하면 1492바이트 프레임을 정확히 채운다. 그 핑이 실패하면 통과할 때까지 숫자를 낮추고 결과에서 36을 빼라. 경로 한계를 넘겨 설정한 터널 MTU는 크기를 언급하는 로그 한 줄도 없이 멈춤을 만든다.

같은 라우터에서 PPTP, L2TP/IPsec, OpenVPN

같은 라우터가 세 가지 흔한 터널 중 무엇이든 나를 수 있고, 차이는 무엇을 표현해야 하는가에 있다. PPTP는 서로 다른 두 계층에 두 규칙이 필요하다. IPsec 위의 L2TP는 키 교환에 UDP 500과 4500이, NAT-T가 나르지 않으면 페이로드에 프로토콜 50이 필요하다. OpenVPN은 UDP 포트 하나면 되고 도우미는 전혀 필요 없다.

L2TP 열이 GRE보다 자동으로 친절한 것은 아니다. ESP는 IP 프로토콜 50이고 이것도 포트가 없으므로, 프로토콜 47에서 고생하는 라우터는 같은 이유로 프로토콜 50에서도 고생할 수 있다. NAT-T는 ESP를 UDP 4500 안에 감싸기 위해 존재하고, 양쪽 끝이 지원하면 프로토콜 50 규칙은 불필요해진다. 그것은 끝단의 성질이지 라우터의 PPTP 상자 성질이 아니다. 양쪽 규칙을 쓰기 전에 클라이언트가 실제로 협상한 캡슐화가 무엇인지 확인하라.

OpenVPN은 라우터 쪽에서 움직이는 부품이 가장 적은 선택지다. UDP 포트 하나, 전달 하나, 연결 추적 도우미 없음, 호출 식별자 재작성 없음. 대신 내장 다이얼러가 아니라 설치해야 하는 클라이언트가 따르며, 그래도 PPTP가 대화에 남는 이유는 대개 이것 하나다.

고칠 것과 바꿀 것

전달과 MTU를 고치면 동작하는 터널이 생기지만, 계속 들고 있어야 할 터널은 아니다. PPTP의 MSCHAPv2 인증은 수년째 공격 가능하고, 동작하는 터널은 오프라인에서 복원할 수 있는 자격 증명을 옮긴다. 원격 장치가 L2TP/IPsec이나 OpenVPN을 돌릴 수 있다면 수리는 날짜가 붙은 임시 조치로 보라.

결정은 원격 끝이 무엇을 지원하는지와 그 구성이 얼마나 버텨야 하는지에 달려 있다. PPTP만 말하는 구형 장비는 수리를 받고, 클라이언트를 설치할 수 있는 것은 이전한다.

티켓을 닫기 전에 클라이언트가 로그인이 아니라 큰 전송을 견디는지, 재부팅 뒤에도 라우터가 프로토콜 47 규칙을 유지하는지 확인하라. 파일 복사 한 번을 통과하고 다음 펌웨어 업데이트 뒤에 죽는 터널은 애초에 끝난 적이 없다.