Разделить виды трафика (vpn от не-vpn)
Приветствую всех знающих и неравнодушных. Запросы снаружи с ip-адреса 91.227.16.11 на порт 90 перенаправляются во внутрь на 192.168.0.15 порт 8888. Там сидит локальный Аппач. Перенаправление настроено в роутере. Когда на локальной машине Windows10 192.168.0.15 запускаю VPN, то запрос к Аппачу извне уже не проходит. Нужно как-то разделить эти два вида трафика: чтобы трафик с 91.227.16.11 на локальную машину ходил без vpn, а всё остальное — через vpn. Подозреваю, нужно прописывать маршруты на локальной машине, но сам не могу сообразить, как это должно выглядеть. Не так много опыта. Помогите, пожалуйста, инструкциями.
Отслеживать
задан 11 авг 2023 в 14:22
Egelschnecke Egelschnecke
11 1 1 бронзовый знак
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Подключение перестаёт устанавливаться, потому что возникает асимметричная маршрутизация: ответный трафик с сервера до IP-адреса подключающегося начинает маршрутизироваться через VPN, с IP-адреса сервера VPN, а не адреса вашего сервера.
Пакет даже может дойти до получателя (зависит от настроек VPN-сервера), но его компьютер не может связать запрос и ответ из-за несовпадения IP-адресов.
Необходимо в Apache настроить bind к физическому (не-VPN) интерфейсу либо адресу, и убедиться, что у вас сохраняется маршрут по умолчанию через не-VPN-интерфейс, но при этом имеет метрику выше.
чтобы трафик с 91.227.16.11 на локальную машину ходил без vpn, а всё остальное — через vpn
Если имеется в виду, что указанный адрес — IP клиента, то это совсем просто — добавьте маршрут до 91.227.16.11/32 через физический интерфейс, Apache перенастраивать не потребуется.
VPN MikroTik — как разделить трафик?
Добрый день, товарищи.
Дело в следующем:
Есть основной микротик с белой статикой(точнее его еще нет, думаю какой будет лучше). И много филиалов — более 30, в каждом тоже стоят микротики типа RB750. Подсети в каждом филиале разные.
Хочется поднять VPN с основным микротиком в качестве сервера, остальные микротики — клиентами. Но хочется чтобы не весь трафик ходил через туннель, а только с определенных ip-адресов локальной сети клиента. Т.е. основной трафик ходил также через провайдера, а только некоторые ip адреса через VPN. Также есть мысль пускать весь http трафик через проксю на proxy-сервер поднятый на том же основном микротике.
Прошу помощи в настройке и совета модели основного микротика.
- Вопрос задан более трёх лет назад
- 5216 просмотров
Комментировать
Решения вопроса 1
Пишу интересное в теллеграмм канале @cooladmin
Коллега, в целом настроить туннели и поднять маршрутизацию можно без особых проблем. Используйте l2tp (если со стороны клиента «серость») или GRE (если со стороны клиента белые адреса), плюс шифрование IPSec в транспортном режиме. Маршруты делаете либо статикой (но на 30+ это то ещё занятие), либо поднимите OSPF (в целом это просто).
Для маршрутизации отдельных клиентов или отдельного типа трафика — просто используйте отдельные таблицы маршрутизации и маркировку трафика в mangle. Никакой прокси в таком случае будет не нужно.
Если подробнее, то:
1. Туннели подняли, настроили маршруты.
2. Создали отдельную таблицу маршрутизации, где шлюзом по умолчанию будет адрес из туннеля центрального микротика
3. Создали mangle правило mark route где в критериях выбираете нужный вам трафик (либо весь, либо конкретный от конкретного клиента \ протокола \ порта) и в действии указываете вот ту самую таблицу маршрутизации. Такое действие отправит отмеченый трафик в центр, откуда он уйдёт наружу через провайдера в центре.
Ответ написан более трёх лет назад
Нравится 3 9 комментариев
JaHher @JaHher Автор вопроса
Спасибо за оперативный ответ. Я только начинаю использовать микротики, по этому хочу попросить больше конкретики. Желательно кодом)
Допустим:
Основной MikroT1 — внешний ip 11.11.11.11, локалка — 192.168.0.0/24
Клиент MikroT2 — внешний ip 22.22.22.22, локалка 10.0.0.0/24
-ip который пойдет через туннель 10.0.0.10 и будет доступен всем из 192.168.0.0/24
-весь http трафик также пойдет через тоннель
Клиент MikroT2 — внешний ip 33.33.33.33, локалка 20.0.0.0/24
-ip который пойдет через туннель 20.0.0.20 и будет доступен всем из 192.168.0.0/24
-весь http трафик также пойдет через тоннель
А прокся была задумана для того чтобы блокировать сайты, можно ли это делать с помощью VPN? Еще хочу резать скорость скачивания и блокировать скачивание допустим все *.exe.
Заранее спасибо
JaHher @JaHher Автор вопроса
Забыл добавить: везде статика и «белость»
Евгений Быченко вы заикались по статьям на тему микротика, у меня есть похожая ситуация по этому хотелось бы на тему OSPF
JaHher: такс, давай код я не буду писать, мне лень сверяться с консолью, но вот что нужно сделать:
На основном:
1. Поднимает l2tp сервер (или GRE туннель), настаиваем профиль подключения, добавляем пользователя или пользователей ppp
2. Разрешаем трафик до VPN сервера (входящий на 1701 порт для l2tp, 4500 и 500 для ipsec, GRE — для угадай чего)
3. Разрешаем исходящий
4. Исключаем из NAT трафик между сетями (всеми локальными и транзитными)
5. Добавляешь маршрут до сети клиентского устройства, где шлюз, через которую эта сеть достижима будет адрес клиентского микротика внутри туннеля
На любом клиентском ситуация такая:
1. Если у тебя локальная сеть 10.0.0.0/24, то транзитная сеть (та что будет идти в туннеле) должны быть иной, например 10.1.0.0/24.
2. Создаёшь в интерфейсах l2tp клиента (или GRE туннель), натравливаешь его на основной белый адрес, указываешь реквизиты доступа. Для l2tp адреса сети в туннели он получить от основного, для GRE прописываешь адреса с обоих сторон сам.
3. Разрешаешь трафик входящий, исходящий и выкидываешь такой трафик из НАТ.
4. Добавляешь маршрут на клиентском до сети основного устройства, где шлюз, через которую эта сеть достижима будет адрес основного микротика внутри туннеля
Всё для начала готово, трафик между устройствами внутри сети клиентского микротика и устройствами внутри сети основного должен пойти.
Второй этап это поворот нужного тебе трафика через интернет на основном, к нему подойдём после того как это сейчас сделаешь.
JaHher @JaHher Автор вопроса
Евгений Быченко: К сожалению сделать этого не могу, потому как основного еще нет. Хочу быть готовым и умелым до покупки основного.
VPN соединение я поднимал. Проблема в том, что весь интрнет начинает ходить через сервер VPN.
Как выкинуть трафик из NAT?
JaHher: создать правило в таблице NAT с действием Accept.
Берёте виртуалку и начинаете учиться. Микротик прекрасно работает внутри виртуалбокса. Каждая машина сможет работать 40-к часов непрерывно (или кучу времени с откатом назад или приостановками).
Задавая вопросы (просто задавая вопросы) на тостере не научится настраивать маршрутизацию по туннелям. Нужно обязательно пробовать и черпать знания в других источниках.
Как разделить трафик vpn на роутере
Как правило, после подключения по VPN весь трафик перенаправляется через это соединение.
Если на компьютере, например, были загрузка данных, клиент-серверные взаимодействия или авторизация доступа, то они прекращаются. Torrent и браузеры также начинают работать только через VPN.
Чтобы этого не происходило и VPN-подключение использовалось только для доступа в корпоративную сеть, в настройках VPN необходимо снять галочку в пункте:
«Использовать основной шлюз в удаленной сети» (см. рисунок)
Заворачиваем весь трафик локальной сети в 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
- Информационная безопасность