MikroTik PPTP обрывается? Исправьте маршрут до сервера

Клиент PPTP в RouterOS подключается, передаёт немного трафика и затем замолкает, а журнал выглядит как проблема с учётными данными или с сервером. Обычно ни то ни другое. Туннель несёт собственные транспортные пакеты, потому что маршрут до сервера совпадает и с маршрутом, который установил туннель. Противоположная сторона перестаёт слышать роутер, и сессия умирает, пока интерфейс ещё утверждает, что активен.

Исправление — один маршрут или одна настройка, которая держит сервер доступным через физический 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, потому что именно тогда появляется устаревший шлюз и туннель снова начинает обрываться.

Или не позволяйте туннелю забирать маршрут по умолчанию

Филиалу, которому нужна одна удалённая локальная сеть, следует держать профиль PPTP полностью в стороне от маршрута по умолчанию. Отключите эту опцию в профиле клиента и вместо неё добавьте конкретный маршрут для удалённого префикса через интерфейс туннеля. Обычный трафик остаётся на WAN, собственный транспорт туннеля сохраняет естественный путь, и таблицу маршрутизации становится проще объяснить. Это лучшая схема для филиала, которому нужна одна подсеть, а не для роутера, который должен быть выходом площадки.

Полный туннель имеет свои требования: маршрутизация по политике для выбранных источников, план для обратного трафика и решение о том, что происходит при падении туннеля. Ничего из этого не решает маршрут к хосту, который лишь поддерживает транспорт живым.

Проверяйте по слоям, затем закройте дыру в управлении

Проверяйте по слоям: пингуйте публичный адрес сервера до подключения, пингуйте удалённый шлюз после подключения, затем пингуйте хост в удалённой локальной сети. Добавьте masquerade на интерфейс туннеля, если хостам за роутером нужны ответы, возвращающиеся через него.

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

Затем перезагрузите роутер или принудительно переподключите WAN и повторите три пинга, потому что маршрут, существующий только в текущей конфигурации, не выживет. Конфигурация, выгруженная в файл резервной копии и позже восстановленная, — это другое место, где это ломается, поскольку маршрут может отсутствовать в выгрузке, если он был добавлен во время работы.

Наконец, ограничьте Winbox и веб-управление известными адресами источников, прежде чем публиковать любое изменение VPN или маршрута. Роутер, который завершает туннели, — это цель управления, и открытый всему миру порт 80 — находка крупнее, чем маршрут, который вы только что исправили.