Как организовать VPN для удаленных сотрудников без маршрутизации лишнего трафика?
Добрый день!
Такая ситуация.
Есть сервер с FreeBSD в качестве маршрутизатора. За ним сеть, в которой есть сервер терминалов под Windows.
До недавнего времени на FreeBSD был проброшен порт на сервер терминалов, чтобы сотрудники работающие вне офиса (дома, например), могли подключаться к серверу терминалов.
Пришли к тому, что это не безопасно.
Решили поднять VPN и убрать проброс порта.
Сделали так.
1. На FreeBSD подняли IKEv2-сервер net/strongswan с авторизацией через RADIUS.
2. Каждому сотруднику на домашнем компьютере настроили VPN-подключение встроенными средствами Windows (от 7 и выше, так как ниже нет поддержки IKEv2). В настройках подключения поставили галочку "использовать шлюз в удаленной сети".
Вопрос: как без граблей уйти от маршрутизации лишнего трафика сервером FreeBSD?
Уточню: хочу чтобы юзер с подключенным VPNом мог спокойно качать торренты через его канал интернета, минуя рабочий VPN-сервер, но при этом доступ к ресурсам внутренней сети предприятия (например, к серверу терминалов) должен осуществляться через VPN.
Понимаю, что смотреть нужно в сторону маршрутизации. Знаю, что можно вручную прописать маршруты на клиентских компьютерах, но не считаю, что это красивое решение. Может быть, возможно передать маршруты с сервера? На любую ли ОС?
Может быть, мы изначально выбрали некорректный путь?
В IPsec есть политики -- какой трафик заворачивать в туннель. Пропишите на серверной стороне IP-подсеть, в которых находятся ваши корпоративные ресурсы, и этот трафик автоматом у клиентов будет заворачиваться в туннель. Всё остальное будет идти мимо туннеля, напрямую через канал клиента.
Копать в сторону параметров leftsubnet/rightsubnet в конфиге strongswan.
До недавнего времени на FreeBSD был проброшен порт на сервер терминалов, чтобы сотрудники работающие вне офиса (дома, например), могли подключаться к серверу терминалов.
Пришли к тому, что это не безопасно.
Решили поднять VPN и убрать проброс порта.
Зачем VPN для подключения к серверу терминалов?!Читайте
Знаем, юзали такое раньше. Но эта штука крайне криво работает с просроченными паролями. Она не предлагает их поменять. Она просто не дает залогиниться юзеру. Решение так и не нашли тогда.
И пароли у всех вида "123", контора небольшая, сотрудники работают годами - никаких проблем подобная сниженная безопасность не доставляет.
Доставляли бы реально строгие пароли - их хрен запомнишь и их записывали бы на бумажках и клали возле монитора...
Однако:
При удаленном подключении - такие пароли как "123" нельзя использовать
Потому и хочется лишний слой безопасности в виде ВПН.
Про галку вам написали.
А далее, чтобы был маршрут до севера терминалов на клиентском устройстве
1. создавать у них соединение через CMAK ( https://habr.com/post/186674/ ), и в нём настроить любые статические маршруты.
2. Включить у всех клиентов слушателя RIP а на фряхе запустить демона рип, чтобы раздавал маршруты.
Плюс второго решения - клиентам ничего не надо будет делать если у вас что-то поменялось.
athacker, в самом RIP в 2018 не вижу ничего плохого. Более того ни квагга, ни фрр не смогли нормально работать с тунелями MPD и OSPF, к которому цеплялись удалённые точки с одной /24 сеткой каждый, а RIP завёлся без проблем. Да и им проще в этом случае, чем из пушки по воробьям.
Ну а раз в strongswan засунули маршрутизацю под названием "политкики" то им, как вы посоветовали лучше всего и обойтись, не городя ничего лишнего у клиента, в первую очередь.
athacker написал правильную мысль, но, к сожалению, винда это винда.
windows клиент для VPN(кроме W10, судя по документации) по умолчанию направляет весь (0.0.0.0/0) трафик в туннель и это может привести к некоторым неработоспособным ситуациям.
По факту, с Windows единственное гарантированное работающее(без сюрпризов) решение - это использовать powershell коммандлет add-vpnconnectionroute который при поднятии VPN соединения подцепит правильный роут к нему.
Ну и соответственно создавать VPN соединение не руками а powershell скриптом.
Подробнее - в доках стронгсван https://wiki.strongswan.org/projects/strongswan/wi...
у клиентов в свойствах подключения есть галка "использовать основной шлюз в удалённой сети". она должна быть снята. соответствующая команда в netsh тоже вроде как имеется. ну и совершенно точно имеется параметр для PS: -splittunneling.
Так проблема в том, что дальше впн траффик не уйдет тогда. У предприятия скорее всего подсеть отличная от той что использует впн. И если не прописать или не пропушить маршрут, то ничего не получится.
Артём Смирнов, для начала проверьте по факту. даже если подсеть отличная, но обе в одном классе, то по идее должно работать без допнастроек или с минимумом их.
если окажется, что нужна раздача маршрутов - используйте DHCP-сервер.
grigoriyb, 192.168.100.1 - это наверное все таки адрес vpn сервера, а не клиента. Так как прописывается сначала подсеть куда надо маршрут построить, потом маска, а потом шлюз через который в эту сеть надо ходить,
Артём Смирнов, нет, это адрес клиента. Проверил даже, у всех клиентов он разный в состоянии подключения.
У меня вот такой статус vpn-подключения.
192.168.1.127 - это мой адрес в локальной сети моего домашнего провайдера.
А зачем вы поставили галочку "использовать шлюз в удаленной сети"? Если вам нужен доступ только к одному серверу терминалов или определенной подсети, то проще прописать один маршрут, а не использовать шлюз впн. В Windows это делается как "route add" и далее синтаксис команды можно почитать.
У меня правда была проблема, если добавлять статический маршрут, и впн обрывается по какой-то причине, то после восстановления соединения маршрут не работал. Я решил это просто планировщиком. На событие подключения впн в журнале событий, запускался скрипт, который удалял старые маршруты и прописывал новые.
Но это было давно. Может сейчас такой проблемы и нет.
Еще некоторые впн серверы сами могут пушить маршруты. Но не знаю как это будет работать со стандартным впн подключением Windows. Вроде OpenVPN такое умеет.
PS. Можно еще port knocking использовать. Если доступ нужен только к терминальному серверу.
Читайте 
