PPTP는 연결된 뒤 Linux NAT 뒤에서 멈춘다: GRE 헬퍼
TCP 1723은 연결되지만 데이터 경로가 죽는다. PPTP는 포트가 없는 GRE 안으로 흐른다. 헬퍼를 적재하고 명시적으로 연결한 뒤 프로토콜 47을 열어라.
누군가 1723을 포워딩하면 클라이언트가 서버에 닿고 인증이 시작되다가, 그다음 아무 오류 없이 모든 것이 멈춘다. 자연스러운 결론은 잘못된 비밀번호라서 비밀번호를 세 번 다시 입력한다. 포워딩은 정상이었고 자격 증명도 정상이었다. 깨진 것은 포워딩이 한 번도 다루지 않았던 두 번째 프로토콜과, 그에 대한 도움을 조용히 멈춘 커널 기본값이었다.
포워딩은 처음부터 문제가 아니었다
포트 포워딩 규칙은 TCP 또는 UDP 트래픽을 설명한다. 세션 도중 다른 IP 프로토콜로 전환하는 페이로드는 설명할 수 없고, PPTP는 정확히 그렇게 한다.
그래서 연결은 멈추는 순간까지 건강해 보인다. 포트 규칙이 관리할 수 있는 부분은 성공했고, 관리할 수 없는 부분이 바로 실패한 부분이다.
제어는 TCP, 데이터는 GRE
호출은 TCP 1723에서 협상된다. 연결이 수립되면 페이로드는 GRE, 즉 IP 프로토콜 47로 넘어가며, 이는 포트 번호를 전혀 나르지 않는다. 포트에 의존하는 규칙에는 맞춰 볼 것이 없다.
GRE가 나르는 것은 헤더 안의 호출 식별자이며, NAT 변환기는 그 필드를 양방향으로 일관되게 다시 써야 한다. 그렇지 않으면 세션의 두 절반이 서로 맞지 않게 된다. 한 방향만 다시 쓰면 인증은 통과하지만 모든 데이터 패킷을 버리는 세션이 되고, 증상의 형태가 정확히 이것이다: 성공, 그리고 침묵.
PPTP 없는 순수 GRE는 그런 재작성이 필요 없으며, 그래서 같은 경로에서 PPTP 클라이언트에 실패하는 라우터를 순수 GRE 터널은 통과할 수 있다.
네 개의 모듈과 그것들을 껐던 sysctl
두 모듈이 프레이밍을 처리하고, nf_conntrack_proto_gre 와 nf_nat_proto_gre 이다. 또 두 개가 호출 식별자를 처리하고, nf_conntrack_pptp 와 nf_nat_pptp 이다. 마지막 것을 적재하면 의존성으로 나머지가 끌려오므로, 모듈 목록에는 네 개가 모두 보여야 한다.
오래된 지침은 2.6 시대의 ip_ 접두사를 사용한다. 그 명령들은 아무것도 적재하지 않으면서 실행되는 것처럼 보일 수 있으므로, 종료 상태가 아니라 적재된 목록을 확인하라.
적재되어 있는 것만으로는 더 이상 충분하지 않다. Linux 4.7부터 net.netfilter.nf_conntrack_helper sysctl의 기본값은 0이며, 이는 새 흐름에 대한 헬퍼 자동 할당을 비활성화한다. 라우터에 모든 모듈이 있어도 아무것도 변환되지 않을 수 있다. 모듈 목록을 다시 보기 전에 실제 값을 확인하라.
자동 할당을 전역으로 다시 켜거나, 필요한 흐름에 헬퍼를 붙이고 나머지는 그대로 두라:
iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp선호할 만한 것은 두 번째 선택지다. 라우터 전체에서 자동 할당을 다시 활성화하는 대신 동작을 PPTP 트래픽으로 한정한다.
포트가 없는 프로토콜 열기
1723을 허용하는 방화벽 규칙은 프로토콜 47에 대해 아무것도 말하지 않는다. firewalld에서는 클라이언트를 향한 영역에서 프로토콜을 허용하라. 일반 iptables에서는 입력 체인에서 gre 프로토콜을 받아들여라.
그다음 양쪽에서 캡처하라. 클라이언트를 떠나는 패킷에 응답이 오지 않는다면 반환 경로가 필터링된 것이며, 그것은 자격 증명 거부와 다른 결함이다.
연결된 뒤의 크기 한계
GRE는 헤더를 삽입하고 그 안의 PPP가 더 붙이므로, 동작하는 링크는 1500보다 훨씬 낮은 MTU를 보고한다. 작은 응답은 로드되고 큰 응답은 멈추며, 이는 첫 번째 문제가 풀리는 순간 나타나는 두 번째의 무관한 문제처럼 보인다.
클라이언트의 PPP 어댑터에서 MTU를 읽고 라우터 자체의 계산과 맞춰라 무언가 동작할 때까지 숫자를 낮추는 대신에. 전체 크기 패킷이 나가고 아무것도 돌아오지 않는다면 그것은 변환이 아니라 그 한계를 가리킨다.
경로를 고치면 사용자는 다시 일하게 되지만, 그것이 PPTP를 좋은 선택으로 만들지는 않는다. MS-CHAPv2와 RC4는 오래전에 폐기되었으므로 모듈 적재를 임시 수정으로 취급하고 유지 관리되는 프로토콜로 옮길 계획을 세워라.