Mikrotik: Маршрутизация к удалённой сети через L2TP без костылей

После того, как был настроен L2TP сервер на Mikrotik, клиенты могут успешно подключаться и работать с удалёнными ресурсами, включая другие подсети, т.к. обычно в настройках L2TP-клиента (Windows) используется удалённый шлюз по-умолчанию и весь трафик клиента идёт через удалённый сервер L2TP, создавая дополнительную нагрузку. Напрашивается логичный вопрос: как этого избежать и что нужно для этого сделать? Ниже я расскажу простые и правильные решения без использования костылей.

Во многих мануалах встречаются такие советы, как ручное прописывание маршрутов на клиентских машинах. Например:

  • сеть для VPN – 192.168.10.0/24
  • Удалённый шлюз, соответственно, из этой же подсети 192.16.10.1
  • Иные подсети, например, основная для офиса – 192.168.20.0/24, до которой необходим доступ.

Пользователь устанавливает соединение, получает адрес из пула 192.168.10.0/24, маршрут по умолчанию – 192.16.10.1 и весь трафик бежит через удалённый сервер и, казалось бы, всё хорошо. Но если на маршрутизаторе настроены лимиты по скорости, какие-то ограничения или же пользователь просто не хочет, чтобы его трафик, который адресован не в удалённую сеть, шёл через VPN? Оно и логично, а потому снимается галочка “Использовать удалённый шлюз” в настройках VPN-соединения под Windows.

Но тут пользователь сталкивается с тем, что остается доступ только до сети 192.168.10.0/24 , а до нужной 192.168.20.0/24 теряется, т.к. маршрут до неё L2TP не передал. Некоторые системные администраторы пишут bat-скрипты, которые пользователи должны запускать: в результате маршруты прописаны и снова всё хорошо.

Но я считаю такой подход костылями: пользователь ничего не должен у себя прописывать, а просто подключается по готовой отлаженной инструкции без всяких скриптов и прописывания чего-то там для него непонятного. Ведь может поменяться сеть, кто-то просто не умеет запускать консоль, у кого-то нет нужных прав на выполнение скрипта – много нюансов может быть.

Думаю, основная проблема понятна. Решений есть несколько:

  • использование динамической маршрутизации RIP на клиенте
  • использование классовой маршрутизации

Первый случай является более сложным и правильным – этому можно посвятить отдельную статью. Но в таком случае пользователю так или иначе придётся что-то дополнительно настроить. А потому стоит рассмотреть второй вариант, который более простой, на мой взгляд.

Вся адресация переводится на новую сеть 172.16.0.0/16, в которой может быть 256 подсетей по /24. Среди них нарезаются новые подсети, например:

  • 172.16.1.0/24 – офисная сеть
  • 172.16.2.0/24 – пользователи VPN
  • 172.16.3.0/24 – сервера
  • & etc…

Теперь пользователь, установив соединение с VPN-сервером, получает маршрут до всей 172.16.0.0/16. Можно спокойно пользоваться ресурсами и в офисной подсети и в серверной и во всех других в рамках 172.16.0.0/16 , т.к. строится классовый маршрут.

В итоге получается всё очень удобно и просто, особенно при планировании сети организации с нуля.

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: