Решения о маршрутизации для VPN
Сетевые маршруты необходимы сетевому стеку, чтобы понять, какой интерфейс использовать для исходящего трафика. Один из важнейших критериев принятия решений о конфигурация VPN состоит в том, хотите ли вы отправлять все данные по VPN (принудительное использование тоннеля) или передавать только часть данных по VPN (разделение туннеля). Это решение влияет на конфигурацию, планирование емкости и ожидания безопасности подключения.
Конфигурация разделение туннеля
В конфигурации с разделением туннеля можно указать маршруты, которые будут проходить через VPN, а весь другой трафик будут проходить через физический интерфейс.
Маршруты можно настроить с помощью VPNv2//RouteList параметра поставщика службы конфигурации VPNv2 (CSP).
Для каждого элемента маршрута в списке можно настроить следующие параметры:
С помощью WINDOWS VPN можно указать маршруты исключения, которые не должны проходить через физический интерфейс.
Для приложений VPN платформы UWP маршруты также можно добавить во время подключении через сервер.
Конфигурация принудительного использования туннеля
В конфигурации с принудительным туннелированием весь трафик проходит через VPN. Принудительное туннелирование является конфигурацией по умолчанию и вступает в силу, если маршруты не указаны.
Единственным последствием принудительного туннеля является обработка записей маршрутизации: маршруты VPN версии 4 и 6 по умолчанию (например , 0.0.0.0/0) добавляются в таблицу маршрутизации с более низкой метрикой, чем для других интерфейсов. Эта конфигурация отправляет трафик через VPN при условии, что в физическом интерфейсе нет определенного маршрута:
- Для встроенной VPN решение контролируется с помощью параметра MDM VPNv2/ProfileName/NativeProfile/RoutingPolicyType
- Для подключаемого модуля VPN UWP приложение управляет свойством . Если подключаемый модуль VPN указывает маршрут по умолчанию для IPv4 и IPv6 в качестве двух маршрутов включения, платформа VPN помечает подключение как Принудительное туннелирование.
Настройка маршрутизации
Сведения о настройке XML см. в разделе Параметры профиля VPN и VPNv2 CSP.
При настройке профиля VPN в Microsoft Intune можно включить конфигурацию разделенного туннеля:
После включения можно добавить маршруты, которые должны использовать VPN-подключение.
Связанные статьи
- Технический справочник по VPN
- Типы VPN-подключений
- Параметры проверки подлинности для VPN
- VPN и условный доступ
- Разрешение имен VPN
- Автоматически инициируемые параметры профиля VPN
- Функции безопасности VPN
- Параметры профиля VPN
Как пустить весь трафик через OpenVPN?
Есть компьютер, который находится в другой стране и работает под управлением WINDOWS Server; Пытаюсь поднять на этом компьютере свой персональный VPN сервис. Скачал дистрибутив openvpn http://openvpn.net/release/openvpn-2.1_rc20-install.exe и установил его как на WINDOWS Server, где поднимаю VPN, так и на свой персональный компьютер, с которого планирую подключаться. Сделал следующие конфигурационные файлы: # Для сервера: dev tun ifconfig 192.168.0.1 192.168.0.2 secret static.key #Для клиента remote 173.255.193.241 dev tun ifconfig 192.168.0.2 192.168.0.1 secret static.key После чего сгерил static.key выполнив команду: openvpn —genkey —secret static.key на сервере Запустил VPN на сервере, и на своем компьютере. Ура — мониторчики загорели зеленым, подключились. Как теперь весь трафик со своего компьютера пустить именно через VPN сервер. Прочитал, что нужно делать посредством маршрутизации. Но не знаю как, с маршрутизацией вообще никогда не работал. Помогите пожалуйста
На сайте с 19.02.2005
18 апреля 2012, 03:08
Поставить в свойствах vpn соединения маршрут по умолчанию.
Не стоит плодить сущности без необходимости
На сайте с 19.03.2012
18 апреля 2012, 07:27
А можно немного подробней, как это сделать. Перерыл тучу материалов, но как это сделать, так и не сообразил.
На сайте с 01.12.2009
18 апреля 2012, 08:26
man route, ip route Только не понятно зачем вам маршрут, когда есть, сервер — клиент. там достаточно и дефолтных настроек + nat
Администратор Linux,Freebsd. (/ru/forum/494299) построения крупных проектов. ICQ#: 241606.
На сайте с 26.11.2005
20 апреля 2012, 11:56
Поробуйте в эту сторону покопать. Изменение маршрута по умолчанию Есть возможность установить маршрут по умолчанию (default route) через созданный туннель OpenVPN. Для этого можно использовать директиву ‘redirect-gateway’, в т.ч. с автоматической передачей её клиенту через механизм push-pull. Однако при работе клиента под непривилегированным пользователем и в chroot-окружении возникают проблемы с восстановлением старого маршрута при закрытии соединения, т.к. клиенту не хватает прав внести изменения в таблицу маршрутизации. Для обхода этой ситуации следует использовать параметр ‘def1’ директивы ‘redirect-gateway’. При этом на сервере в файле конфигурации (глобальном или конкретного клиента) переназначение маршрута задаётся строкой вида
push "redirect-gateway def1"
Получив эту директиву (при наличии ‘pull’ в своей конфигурации), клиент не удаляет старый маршрут, а добавляет в таблицу маршрутизации записи вида:
0.0.0.0/1 via 192.168.231.5 dev tun0
128.0.0.0/1 via 192.168.231.5 dev tun0
Как разделить VPN трафик в MacOS
VPN (англ. Virtual Private Network — виртуальная частная сеть — обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет) WikiPedia
Предположим, вы разработчик и часть ресурсов (например база данных) находятся в корпоративной сети, доступ в которую осуществляется через VPN.
Если вы посмотрите на все доступные инструкции как настраивать VPN на Mac OS, то увидите что авторы говорят вам ставить галку «отправлять весь трафик через VPN», что приводит к тому, что (Капитан Очевидность) весь трафик идет через VPN, что в свою очередь накладывает все ограничения корпоративной сети (запрет на посещение отдельных ресурсов, закрытые порты и т.д.) или ограничения сервиса анонимизации (узкий канал, долгий ping и т.д.).
Возникает вопрос — нельзя ли через VPN пускать только определенный трафик, а весь остальной (основной) трафик пусть идет по обычному каналу без ограничений.
Делается это довольно просто.
Кратко пройдемся по настройке VPN соединения.
Нажимаем на «яблочко» в левом верхнем углу экрана и выбираем «Системные настройки».
Выбираем «Сеть»
Нажимаем на «плюсик» в списке сетевых соединений.
Выбираем «VPN»
Тип VPN (в моем случае это L2TP через IPSec)
Заполняем параметры соединения
Галку «Отправлять весь трафик через VPN» не ставим
Теперь нам надо узнать интерфейс через который идет VPN-трафик.
Запускаем ifconfig без подключенного VPN
Подключаем VPN и снова запускаем ifconfig
Видим что появился интерфейс ppp0
Теперь по умолчанию весь трафик идет по обычному соединению (не VPN).
Далее, мне нужно чтобы коннекты к моему серверу, расположенному по адресу 192.168.0.20 шли через VPN. Для этого нам нужно построить сетевой маршрут. Воспользуемся штатной unix-командой route.
sudo /sbin/route add -host 192.168.0.20 -interface ppp0 Теперь весь трафик идет через мое обычное соединение, а трафик к корпоративному серверу идет через VPN.
Для удобства в файле ~/.profile создаем алиасы на команду добавления маршрутов
alias server-vpn-up='sudo /sbin/route add -host 192.168.0.20 -interface ppp0' Теперь чтобы поднять соединение, необходимо подключиться к VPN и выполнить команду server-vpn-up.
Альтернативный вариант, это создать файл /etc/ppp/ip-up, прописать в него [в моем случае]
#!/bin/sh /sbin/route add 192.168.0.0/24 -interface $1 и дать права на выполнение
sudo chmod +x /etc/ppp/ip-up После этого маршрут будет прописываться автоматически после соединения с VPN.
Какие могут встретиться подводные камни.
1. Может быть конфликт IP-адресов, если внутренняя и внешняя сеть используют одно адресное пространство (возможно я использую не правильный термин, поправьте в комментариях пожалуйста). Т.е. у вас и VPN и внутренняя домашняя сеть находятся в 192.168.0… В моем случае решением было перенастройка домашней сети на 10.0.1…
2. При подключении VPN автоматически ставился корпоративный DNS 192.168.0.7. И хотя весь трафик должен был идти вроде как не через VPN, все сайты переставали открываться. Решилось это добавлением Google-ового DNS 8.8.8.8 и поднятии его в самый верх.
Заворачиваем весь трафик локальной сети в vpn без ограничения скорости
В прошлой статье мы разбирали, как анонимизировать весь Интернет-трафик одного хоста. Теперь давайте повысим уровень безопасности, обернув всю локальную сеть VPN-ом. При этом мы избавимся от опасности выйти в интернет с еще не настроенного девайса и ассоциировать адрес своего провайдера с этим устройством.
Для этой цели можно просто настроить VPN-клиент на шлюзе, если это позволяет роутер. Но такое решение черевато последствиями в виде уменьшения скорости работы Интернета, повышенной нагрузки на роутер, к тому же некоторые клиенты отправляют весь трафик через основное соединение сразу же в случае отключения от VPN. Не стоит забывать, что даже ведущие VPN-провайдеры не могут обеспечить 100% аптайм своих серверов.
Итак, каковы наши цели:
- пропускать через VPN весь без исключения исходящий трафик
- делать это с максимально возможной скоростью
- не зависеть от временных неполадок VPN-провайдера
- максимум анонимности в Интернете
Подготовка
Нам нужен мощный роутер, способный шифровать трафик на высокой скорости. Он будет выступать в роли VPN-шлюза. Мы нашли замечательные мини-ПК на AliExpress, которые подошли под эту задачу: четырехъядерный Intel Celeron, нативная поддержка AES-CBC, AES-XTS, AES-GCM, AES-ICM и аж четыре RJ-45 порта. И по умолчанию на них была установлена pfSense. С ней и будем работать.
Если ваш Интернет-провайдер требует особой настройки соединения, вы можете взять еще два роутера и разделить доступ к интернету и локальную сеть, а между ними поставить VPN-шлюз. В другом случае, можете напрямую подключить провод провайдера к VPN-шлюзу, а за ним разместить ваш домашний роутер с локальной сетью. Первоначальная настройка Интернет-соединения на pfSense выходит за рамки этой статьи.
Настройка
Статья предполагает, что интернет подключен к первому порту, ваш ПК или домашняя сеть — ко второму, и что до настройки VPN вы смогли выйти в интернет.
Во избежание дальнейших проблем давайте авторизуемся у любимого VPN-провайдера и найдем инструкцию по настройке pfSense. Если ваш провайдер не предоставляет инструкцию по ручной настройке в pfSense, можно воспользоваться вот этой от моего любимого провайдера: www.expressvpn.com/support/vpn-setup/pfsense-with-expressvpn-openvpn — основная суть не изменится. Приведенная статья с картинками расписывает, как полностью настроить только что купленный роутер с pfSense.
Вот краткий чеклист настройки нового VPN-а:
- System — Cert. Manager — CAs. Добавляем сертификат VPN CA
- System — Cert. Manager — Certificates. Добавляем сертификат VPN сервера
- VPN — OpenVPN — Clients. Создаем нового клиента по инструкции от VPN-провайдера
- Interfaces — Assignment. Добавляем клиентов как интерфейсы
- System — Routing. Проверяем что появился шлюз.
- Firewall — NAT. Добавляем правила NAT для каждого клиента
- Firewall — Rules — LAN. Добавляем перенаправление всего трафика из сети через Gateway
- System — Routing. Для активного VPN-a в настройках шлюза указываем Monitor IP, пингом до которого будет проверяться работоспособность VPN-а
На этом этапе останавливаемся и проверяем, что доступ в интернет через VPN есть, и что при отключении от VPN доступ пропадает вовсе. Если интернета нет — где-то ошиблись, смотрим логи VPN, проверяем настройки заново. Если после отключения VPN трафик начинает идти через основной шлюз, значит накосячили в Firewall — Rules — LAN.
Теперь интересная часть. Если ваш провайдер выдает 20 Мбит в секунду, и то ночью — то на этом этапе вы уже получили локальную сеть, полностью закрытую VPN-ом, который работает с максимально возможной скоростью. Но что, если у вас канал пошире?
Масштабируемся
Настраиваем еще пару-тройку VPN клиентов для разных серверов по инструкции выше. Добавлять сертификаты CA и сервера не нужно, выбираем уже добавленные. Также не выполняем шаг с Firewall — Rules — LAN, его мы сделаем позже. Необходимое количество клиентов устанавливается эмпирическим путем по результатам замеров скорости через каждый отдельный сервер.
После того как завершили, у нас должна быть следующая картина:
— В VPN — OpenVPN — Clients созданы и активированы клиенты
— В Interfaces — Assignment созданы и активированы интерфейсы для каждого клиента
— В Status — OpenVPN все клиенты находятся в состоянии «up»
— В System — Routing появились шлюзы, и для них указаны пингуемые IP-адреса.
(Если не можете придумать, кого попинговать — откройте shodan.io и найдите все IP google)
Теперь зайдем в System — Routing — Gateway Groups. Нажмите Add. Укажите запоминающееся имя в Group Name.
Теперь обратите внимание на таблицу Gateway Priority. Группы шлюзов работают следующим образом: failover по уровням, балансировка внутри уровня. Столбец Tier указывает, в каком уровне будет использоваться данный шлюз. Простейший вариант — указываем все активные VPN-шлюзы в первом уровне. Вариант для медленного интернета — создаем двух клиентов и размещаем их на первом и втором уровне, но в этом случае будет только отказоустойчивость.
Ниже найдите Trigger Level. Это условие, при котором произойдет временное исключение шлюза из группы. Варианты кроме Member Down позволяют перестать отправлять пакеты шлюзу чуть раньше, чем он упадет полностью — по превышению порога потери пакетов и/или по высокому пингу. Пороги потерь и пинга задаются для каждого шлюза индивидуально в System — Routing — Gateway.
Как только выбрали удобный вариант расстановки шлюзов по уровням, нажмите Save.
Пришло время направить трафик в новую группу шлюзов. Идем в Firewall — Rules — LAN, открываем созданное ранее правило перенаправления, спускаемся до списка со шлюзами и видим в этом списке созданную нами группу. Выбираем её, сохраняем правило и применяем изменения. Всё, теперь каждое новое соединение будет идти через новый VPN-клиент в группе.
Время тестирования: открываем api.ipify.me, отключаем кэш и keep-alive, и перезагружаем страницу. Если вы единственный пользователь в сети, на каждое обновление страницы вы должны видеть новый IP адрес, отличающийся от вашего домашнего. Если вы видите один и тот же адрес, полностью обновите страницу при помощи Ctrl+F5 (Command+Shift+R на маках), или откройте новую приватную вкладку. Если не помогло — значит где-то ошиблись в настройках группы, или не сменили шлюз в правилах фаерволла.
Теперь о плохом. К сожалению, у данного решения есть небольшой трудноуловимый баг, если использовать его перед роутером локальной сети (а не коммутатором). Рано или поздно у вас отваливается один из VPN-клиентов, срабатывает исключение его из группы, и всё хорошо до того момента, пока VPN не поднимется обратно. Так как все пользователи находятся за NAT, а VPN-роутер видит только один IP-адрес и 65 тысяч портов, со временем он ассоциирует все порты с теми VPN-клиентами, которые никогда не падали. Соответственно, как только VPN-клиент поднимается, через него не идет никакой трафик. Клиент полностью жив, через него идут пинги и некоторое стабильное количество служебного трафика, но через него не идет трафик клиентов. По идее это решалось бы сбросом таблицы соединений, и для этого даже есть галочка в настройках pfSense, но в моих исследованиях эта галочка напрочь блокировала всякий доступ к роутеру, так как клиенты начинали валиться циклично, при этом роняя только-только установленные соединения с веб-интерфейсом, что сильно затрудняло исправление проблемы. Без этой галочки при наличии более двух VPN-ов они уравновешивали себя, так что доступ хотя бы через один всегда был. В конце концов я настроил в мониторинге условие «если пять минут на интерфейсе было меньше 1000 байт трафика в секунду, сообщить мне», и в особо запущенных случаях перезагружаю зомби-VPN-клиента вручную с целью сбросить таблицу соединений.
Итак, мы получили сеть, полностью пропускаемую через несколько распределенных VPN-ов. За счет сочетания нескольких разных VPN-серверов мы не зависим от доступности каждого из них в отдельности, а скорость сети ограничена только вашим каналом за вычетом шифрования. Если вдруг вам не хватит одного роутера — их тоже можно масштабировать, но это тема для отдельной статьи.
- Блог компании Postuf
- Информационная безопасность