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, бо саме тоді з’являється застарілий шлюз і тунель знову починає обриватися.

Або не дайте тунелю захопити типовий маршрут

Філія, якій потрібна одна віддалена LAN, має тримати профіль PPTP зовсім осторонь типового маршруту. Вимкніть цю опцію в профілі клієнта і натомість додайте окремий маршрут для віддаленого префікса через інтерфейс тунелю. Звичайний трафік залишається на WAN, власний транспорт тунелю зберігає природний шлях, а таблицю маршрутизації стає легше пояснити. Це кращий дизайн для філії, якій потрібна одна підмережа, а не для маршрутизатора, що має бути виходом майданчика.

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

Перевіряйте пошарово, потім закрийте діру в керуванні

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

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

Потім перезавантажте маршрутизатор або примусово перепідключіть WAN і повторіть три пінги, бо маршрут, який існує лише в поточній конфігурації, не переживе. Інше місце, де це ламається, — конфігурація, експортована у файл резервної копії і згодом відновлена, бо маршрут може бути відсутній в експорті, якщо його додали під час роботи.

Насамкінець обмежте Winbox і вебкерування відомими вихідними адресами, перш ніж публікувати будь-яку зміну VPN або маршруту. Маршрутизатор, що завершує тунелі, є ціллю керування, і порт 80, відкритий для світу, — більша знахідка, ніж маршрут, який ви щойно виправили.