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, отворен за света, е по-голяма находка от маршрута, който току-що поправихте.