MikroTik PPTP가 끊기나요? 서버로 가는 경로를 고치세요

RouterOS의 PPTP 클라이언트가 연결되고 조금 트래픽을 보낸 뒤 멈추며, 로그는 자격 증명이나 서버 문제처럼 보입니다. 보통은 둘 다 아닙니다. 터널이 자기 전송 패킷을 나르고 있는데, 서버로 가는 경로가 터널이 설치한 경로와도 일치하기 때문입니다. 상대 측은 라우터의 소리를 듣지 못하고, 인터페이스는 여전히 살아 있다고 주장하는 사이 세션이 죽습니다.

해법은 경로 하나, 또는 설정 하나로 서버를 물리 WAN을 통해 도달 가능하게 유지하는 것입니다. 어느 쪽이 필요한지는 라우터가 전체 터널 게이트웨이가 되어야 하는지에 달려 있습니다.

증상: 연결되고, 트래픽을 보내고, 죽는다

재연결마다 같은 패턴이 반복되며, 그것이 첫 번째 유용한 단서입니다. 거부된 비밀번호는 인터페이스가 올라오기 전에 실패하고, 방화벽 설정 오류는 보통 한 방향을 막으며, 라우팅 루프는 인터페이스가 올라오게 둔 뒤 목을 조릅니다. 카운터를 보면 터널은 초기 패킷의 폭발을 보인 뒤 아무것도 없고, WAN 인터페이스는 캡슐화된 사본을 계속 보냅니다. 이것은 자기 출력을 다시 자기에 넣는 라우터입니다.

PPTP에서 이것이 쉬운 이유는 전송이 서버 주소로 가는 평범한 IP이고, 상대 끝이 다른 서브넷에 있는 터널이 아니기 때문입니다. 그 주소를 우회시키는 것은 전송도 함께 우회시킵니다.

터널이 자기 패킷을 삼키는 이유

클라이언트가 연결되면 게이트웨이가 터널 인터페이스인 경로를 설치합니다. 프로필이 기본 경로도 설치하면, 더 구체적인 일치가 없는 모든 목적지, 서버의 공인 주소까지도 터널로 해석됩니다. 라우터는 패킷을 캡슐화하고 바깥 패킷을 서버로 보낸 뒤 다시 경로를 조회하는데, 같은 목적지, 같은 기본, 같은 터널입니다. 릴리스에 따라 그 재귀는 버려지거나, 대기열에 들어가거나, 상대가 포기하고 세션을 끊을 때까지 루프합니다.

어플라이언스 제조사는 흔히 바로 이것을 피하려고 자기 서버용 호스트 경로를 자동으로 추가합니다. RouterOS는 그것을 가정하지 않으므로, 운영자는 예외를 표현하거나 처음부터 기본 경로를 피해야 합니다.

서버 주소를 WAN에 고정하세요

가능한 한 좁은 경로를 추가하세요: 서버의 공인 주소에 /32, 다음 홉은 공급자 게이트웨이로, 인터넷에 닿는 인터페이스에 둡니다. /32는 프리픽스 길이로 어떤 기본 경로도 이기고, 같은 프리픽스의 다른 경로가 이미 있으면 더 작은 거리가 이깁니다. 그런 다음 다시 연결해 경로가 목록에만 있는 것이 아니라 활성인지 확인하세요.

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

공급자 게이트웨이를 DHCP로 배우면 DHCP가 설치한 게이트웨이 주소를 쓰거나, 릴리스가 지원하면 경로를 인터페이스에 묶으세요. 다음 임대에서 바뀌는 하드코딩된 게이트웨이는 지연된 고장입니다. WAN 재연결 후 주소를 확인하세요, 그때 낡은 게이트웨이가 나타나 터널이 다시 끊기기 시작하기 때문입니다.

또는 터널이 기본 경로를 차지하지 못하게 하세요

원격 LAN 하나만 필요한 지사라면 PPTP 프로필을 기본 경로에서 완전히 떼어 놓아야 합니다. 클라이언트 프로필에서 그 옵션을 끄고, 대신 터널 인터페이스를 통해 원격 프리픽스에 대한 특정 경로를 추가하세요. 일반 트래픽은 WAN에 남고, 터널 자체의 전송은 자연스러운 길을 지키며, 라우팅 테이블은 설명하기 쉬워집니다. 이것은 서브넷 하나가 필요한 지사에 맞는 설계이고, 사이트의 출구가 되어야 하는 라우터에 맞는 설계가 아닙니다.

전체 터널에는 선택한 소스에 대한 정책 라우팅, 반환 트래픽 계획, 터널이 끊길 때 어떻게 할지에 대한 결정이라는 자체 요구 사항이 있습니다. 이 가운데 어느 것도 전송을 살려 둘 뿐인 호스트 경로로 해결되지 않습니다.

계층별로 확인한 뒤 관리 구멍을 막으세요

계층별로 시험하세요: 연결 전에 서버의 공인 주소로 ping하고, 연결 후 원격 게이트웨이로 ping하고, 그다음 원격 LAN의 호스트로 ping합니다. 라우터 뒤의 호스트가 응답을 이 인터페이스로 돌려받아야 한다면 터널 인터페이스에 masquerade를 추가하세요.

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

그런 다음 라우터를 재부팅하거나 WAN 재연결을 강제하고 세 번의 ping을 반복하세요, 실행 중인 구성에만 있는 경로는 살아남지 않기 때문입니다. 백업 파일로 내보낸 뒤 나중에 복원한 구성도 이것이 깨지는 또 다른 지점입니다, 런타임에 추가한 경로는 내보내기에 없을 수 있기 때문입니다.

마지막으로 VPN이나 경로 변경을 공개하기 전에 Winbox와 웹 관리를 알려진 소스 주소로 제한하세요. 터널을 종단하는 라우터는 관리 대상이고, 전 세계에 열린 포트 80은 방금 고친 경로보다 큰 발견입니다.