L2TP VPN "Получен пакет L2TP UDP от" снова и снова.

Для людей будущего, которые гуглят эту проблему. Варианта решения, если вы хотите настроить L2TP, я не нашел. L2TP хорош для пользователей (ноутбуков/удаленных рабочих столов), которым нужен VPN, но не очень надежен для соединения между сайтами. В итоге я настроил OVPN (родной для Mikrotiks, как сервер, так и клиент) с сертификатами, и соединение VPN между моими двумя локациями работает уже больше двух недель. Так что ваше решение для Site-to-Site VPN с использованием двух Mikrotiks — это использовать PPTP (быстрый, стабильный, но не безопасный) или OVPN (быстрый, стабильный, безопасный) вместо L2TP (самый медленный вариант, нестабильный, супер безопасный).

Это зависит от того, как вы определяете надежность и каковы ваши требования и качество сети. L2TP отправляет пакет LCP EchoReq каждые 30 секунд и ожидает ответа EchoRep; если его нет, он делает еще 4 попытки с интервалом в 1 секунду, и если ответа по-прежнему нет, туннель разрывается (клиент начинает подключаться снова, что на сервере отображается как получение L2TP UDP пакета из …). Так что, если уровень потерь связи между вашими площадками может быть очень высоким на протяжении 6 последовательных секунд хотя бы в одном направлении, и кампания LCP EchoReq попадает в этот интервал, это происходит с L2TP. В то время как VPN-протокол, который использует TCP в качестве транспорта (например, OpenVPN или SSTP) или не так чувствителен к качеству транспортной сети (например, вероятно, PPTP, хотя я не анализировал его методы проверки доступности и их таймауты), может показаться "надежным" при том же уровне качества канала. Я не говорю, что у TCP нет проблем с 6-секундной полной остановкой передачи, я просто отмечаю, что поскольку VPN использует TCP, он может не беспокоиться о том, жив ли другой конец, когда у него нет данных для отправки, полагаясь на TCP, чтобы это выяснить. А если это не полная остановка, а просто высокий уровень потерь (что может быть вызвано банальным перегрузом канала), TCP может поддерживать соединение из-за переменного таймаута между повторными отправками. Так что "надежный" в смысле "я не паникую, если не слышу с другого конца долгое время" и "надежный" в смысле "я постоянно мониторю доступность удаленного конца и принимаю меры для восстановления соединения, если что-то пошло не так" - это разные понимания слова. В надежной сети никому нет дела до значения "надежный"; когда транспортная сеть случайным образом перестает доставлять пакеты на секунды, разница становится важной. Сказав это, я должен вернуться к своему предыдущему утверждению - использование TCP для туннелирования другого TCP причиняет немного проблем, когда уровень потерь низкий, но в таких случаях UDP, ESP или GRE как VPN-транспорты также не имеют проблем. Где уровень потерь высокий, TCP по отношению к TCP создает headaches и может быть недостаточно для спасения ситуации. Так что если ваша транспортная сеть так плоха, но у вас нет другого варианта, вам придется экспериментировать с различными типами VPN и выяснить, какой из них лучше всего подходит для вашей конкретной ситуации и потребностей. Конечно, любая передача в реальном времени (например, VoIP) на такой плохой сети - это не то, о чем стоит даже мечтать. Но ваша сеть может на самом деле не быть такой плохой; возможно, что часть вашего трафика исчерпывает доступную пропускную способность вашего последнего звена, потому что не используется управление QoS.

В этой ситуации я бы использовал IKEv2, а не L2TP/IPsec. С IPsec в одиночку (без L2TP) вы можете выбрать интервал DPD и скорость реакции (сколько обменов DPD должно провалиться, чтобы принять меры). Между двумя Mikrotik вы можете выбрать аутентификацию с помощью предустановленного ключа или сертификата. Теоретически, вы могли бы сэкономить еще больше, используя встроенный VPN-клиент Windows вместо клиентского устройства Mikrotik, но я не нашел другого способа заставить его переподключиться в случае сбоя, кроме как с помощью скрипта PowerShell, который следит за доступностью удаленной сети. У меня нет информации, можно ли настроить параметры DPD там, так что маленькая коробка Tik, такая как hAP ac², вероятно, обойдется дешевле, чем время, потраченное на возню с этим на стороне Windows, даже если она не выполняет другую функцию на клиентской стороне.