MikroTik PPTP 总掉线？修好到服务器的路由

RouterOS 的 PPTP 客户端连上后能传一点流量，然后就没了动静，日志看起来像是凭据或服务器的问题。通常两者都不是。隧道在承载自己的传输报文，因为到服务器的路由同时也匹配了隧道装上的那条路由。对端再也听不到路由器，会话随即死亡，而接口还宣称自己是 up 的。

修法是一条路由或一项设置，让服务器始终经由物理 WAN 可达。选哪一种，取决于这台路由器是否要做全隧道的网关。

症状：连上、传流量、然后死掉

每次重连都重复同样的模式，这是第一个有用的线索。密码被拒会在接口起来之前就失败，防火墙配错通常只挡一个方向，而路由环会让接口建立成功再把它掐死。看计数器：隧道先冒出一阵初始报文，然后归零，而 WAN 接口仍在不停发送封装后的副本。这就是路由器把自己的输出又喂回了自己。

PPTP 特别容易触发这一点，因为传输就是发往服务器地址的普通 IP，而不是一条远端落在别的子网的隧道。任何把该地址改道的东西，都会连传输一起改道。

隧道为什么吞掉自己的报文

客户端一连上，就装一条以隧道接口为网关的路由。如果配置文件还装了默认路由，那么所有没有更确切匹配的目的地，包括服务器的公网地址，都会解析到隧道。路由器把报文封装起来，外层报文仍然发往服务器，然后再查一次路由：同一个目的地，同一条默认路由，同一条隧道。视版本而定，这种递归会被丢弃、排队，或者一直循环，直到对端放弃并拆掉会话。

设备厂商往往自动给自己的服务器加一条主机路由，正是为了避免这件事。RouterOS 不会替你假设这一条，所以运维者必须把例外写出来，或者一开始就避开默认路由。

把服务器地址钉在 WAN 上

加一条尽可能窄的路由：针对服务器公网地址的 /32，下一跳是 ISP 网关，出口是能上互联网的那个接口。/32 靠前缀长度胜过任何默认路由；如果同一前缀已经有别的路由，距离更小的那条赢。然后重连，确认这条路由是 active 的，而不是仅仅出现在列表里。

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

如果 ISP 网关是 DHCP 学来的，就用 DHCP 装上的那个网关地址，或者在这个版本支持时把路由绑到接口上。写死一个下次租约就会变的网关，是延迟发作的故障。WAN 重连之后要再查一次这个地址，因为过期网关正是在那时候冒出来，隧道又开始掉。

或者不让隧道抢走默认路由

只需要一个远端 LAN 的分支，就该让 PPTP 配置文件完全不碰默认路由。在客户端配置里关掉那个选项，改成经隧道接口为远端前缀加一条具体路由。普通流量留在 WAN 上，隧道自己的传输走它自然的路，路由表也变得更好解释。对只需要一个子网的分支，这是更好的设计；对本来该做站点出口的路由器则不是。

全隧道有它自己的要求：为选定的源做策略路由，为回程流量做规划，还要决定隧道断开时怎么办。这些都不是主机路由能解决的，它只负责让传输活着。

分层验证，再堵上管理口子

分层测：连接前 ping 服务器的公网地址，连接后 ping 远端网关，再 ping 远端 LAN 上的一台主机。如果路由器后面的主机需要回包从它这里回来，就在隧道接口上加 masquerade。

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

然后重启路由器，或者强制 WAN 重连，把三次 ping 重做一遍，因为只存在于运行配置里的路由活不过这一步。另一个会坏的地方是导出到备份文件、之后再恢复的配置：如果路由是运行时加的，导出里可能就没有它。

最后，在发布任何 VPN 或路由变更之前，把 Winbox 和 Web 管理限制在已知源地址上。终结隧道的路由器就是管理目标，而对全世界开放的 80 端口，比你刚修好的那条路由是更大的问题。