Решения о маршрутизации для 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
Настройка маршрутизации в сети с неподконтрольным роутером
Я ненавижу рекламу, но постоянно на нее покупаюсь. Увидел в подъезде объявление МГТС — GPON 500 мегабит за 500 рублей в месяц, настоящий IP, IPv6. Из минусов — всего лишь необходимость сверлить стену и вешать в квартире чужой роутер. Думаю надо брать — разберемся как-нибудь. (На самом деле нет, но об этом позже). Гигабитный роутер с WiFi 802.11ас (5ГГц), но без возможности модификации прошивки, установки софта и с минимальными возможностями настройки через веб-интерфейс. Задача — настроить VPN с другой сетью и прозрачное для клиентов использование ресурсов из луковой сети (The Onion Router aka TOR) с использованием своего сервера в локальной сети.
Думаю данная статья не потянет на полноценное руководство. Слишком разные возможности и потребности у людей — разное железо. Скорее некоторый указатель пути по которому можно пойти. Например для сервера можно использовать популярную малину. Возможно даже с pi-hole. Я, например, поставил недорогой x86 сервер с распаянным на материнской плате процессором, поставил ubuntu и использую его, в том числе как файловый, home assistant, веб и сервер приложений.
В общем я хотел, чтобы была возможность использовать WiFi интерфейсы роутера, а также, чтобы клиенты локальной сети получили прозрачный доступ к некоторым ресурсам через vpn или tor без дополнительной настройки на стороне клиента. И не хотелось понапрасну пропускать весь трафик через сторонний сервер — хотелось, чтобы обычный интернет трафик шел напрямую на роутер, а специальный (tor, vpn) обрабатывался сервером. Решил, что отключу на маршрутизаторе DHCP и DNS server, поставлю DHCP на свой сервер, который будет анонсировать правильные маршруты по DHCP и на котором будет крутиться dns, vpn и tor daemon. С vpn все понятно — если другая локальная сеть имеет другие адреса, то достаточно просто настроить маршрутизацию. Для прозрачного доступа к ресурсам через луковый маршрутизатор решил использовать связку dnsmasq + tor.VirtualAddrNetwork + tor.DNS. Настраиваем dnsmasq для предопределенных доменов из списка, чтобы для их разрешения он использовал tor. После этого домены из луковой сети будут иметь специфичные адреса из специального выделенного диапазона частных адресов и можно использовать обычные правила маршрутизации для перенаправления этого трафика в tor.TransPort с использованием правил iptables. Для соединения локальных сетей по vpn использовал wireguard. В другой локалке стоит обычный роутер пока с прошивкой padavan + entware.
Ключевые параметры моей конфигурации:
- Локальная сеть — 192.168.2.0/24. У роутера статический белый IP
- Другая локальная сеть (доступ к которой получаем через vpn) — 192.168.3.0/24
- Роутер — 192.168.2.1
- Сервер ubuntu — 192.168.2.4, имя ethernet интерфейс — enp1s0
- tor
- private network (VirtualAddrNetwork) — 10.254.0.0/16
- dns server (DNSPort) — 127.0.0.1:9053
- transparent proxy address (TransPort) — 0.0.0.0:9040
- сервер wireguard address — 10.253.1.2
- android клиент — 10.253.1.10
- vpn сервер другой локалки — 10.253.1.3
Сервер
Мой сервер — обычный x86 с Ubuntu 20.04 LTS.
Установливаем пакеты ( apt install ):
- iptables-persistent — сохранение и восстановление правил iptables
- tor
- dnsmasq — DNS + DHCP сервер
- dnscrypt-proxy — DoH DNS клиент
- systemd + netplan.io — были установлены по умолчанию и используются для настройки сетевого интерфейса
- wireguard — vpn
Настраиваем статический сетевой интерфейс — /etc/netplan/eth0-static.yaml и запускаем netplan apply для применения изменений.
Для включения маршрутизации установливаем параметры ядра:
sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv6.conf.all.forwarding=1и правим файл /etc/sysctl.conf для сохранения изменений после перезагрузки.
Настроиваем iptables — для таблицы filter установливаем default policy ACCEPT для цепочек INPUT и FORWARD — /etc/iptables/rules.v4. И перезагружаем правила netfilter-persistent start или iptables-restore < /etc/iptables/rules.v4 .
Настройки dnsmasq
В /etc/default/dnsmasq добавляем опцию для игнорирования файлов с расширением *.i.
Локальные устройства прописываем в /etc/dnsmasq.d/src/lan_hosts.csv.i для задания фиксированных IP адресов.
Домены для доступа к которым будем использовать tor прописываем в /etc/dnsmasq.d/src/dns_tor_domains.txt.i
Для анонса маршрутов используется DHCP опция classless-static-route и microsoft-classless-static-route — 249 (на всякий случай). В принципе можно было бы попробовать и не отключать DHCP сервер на роутере, а просто анонсировать дополнительные маршруты. Проблема возникла на телефоне Android Xiaomi Mi 9T. Он не использовал маршруты с DHCP, использовал только один маршрут по умолчанию. Не уверен, что на всех андроидах есть такая проблема. Пришлось для андроидов сделать специальные настройки и перенаправлять весь трафик от андроид клиентов на сервер.
Специальные настройки для android — нет маршрутов, сервер используется в качестве основного маршрутизатора.
Для примения настроек запускаем `dnsmasq_reconfig.sh` — более подробно описано в разделе «Обновление конфигурации».
Настройки tor
- Порт для socks5 proxy — SocksPort
- Запрещаем выходные ноды в некоторых странах — ExcludeExitNodes
- Порт для transparent proxy — TransPort
- Порт DNS — DNSPort
- Частный диапазон адресов из которых будут назначаться IP для серверов к которым мы будем ходить через tor — VirtualAddrNetwork
Список доменов которые мы будем резолвить через tor и которые будут иметь адреса из нашего частного диапазона (см. VirtualAddrNetwork) — AutomapHostsSuffixes — настраивается скриптом dnsmasq_reconfig.sh и сохраняется в файл /etc/tor/hosts_suffixes.cfg.
DoH
DNS over HTTPS — это протокол для выполнения разрешения DNS по протоколу HTTPS. Для меня целью его использование является защита от подмены DNS провайдером.
Для реализации используем dnscrypt-proxy. Для установки выполняем apt install dnscrypt-proxy .
Примечание: я немного изменил способ запуска dnscrypt-proxy потому что мне показалось, что он у меня не работал. В настройках по умолчанию он запускается через systemd.socket — то есть порт слушает systemd и запускает dnscrypt-proxy когда нужно. Я изменил конфигурацию. В моей конфигурации я запускаю dnscrypt-proxy напрямую. Порт слушает dnscrypt-proxy. Не думаю что это нужно. Для смены порта в конфигурации по умолчанию — когда dnscrypt активируется через systemd.socket надо выполнить systemctl edit dnscrypt-proxy.socket и установить
Обновление конфигурации
Добавляем домен на который хотим ходить через tor в файл /etc/dnsmasq.d/src/dns_tor_domains.txt.i
Добавляем статический адрес устройства локальной сети в файл /etc/dnsmasq.d/src/lan_hosts.csv.i
Запускаем скрипт dnsmasq_reconfig.sh, который сгеренрирует файлы настройки для dnsmasq (/etc/dnsmasq.d/ lan_hosts.cfg.i, resolv.conf.i), tor (/etc/tor/hosts_suffixes.cfg) и все перезапустит для обновления конфигурации.
Cброс DNS кэша
Допустим вы зашли на сайт напрямую, но посмотрели и решили, что стоит зайти через tor. Просто обновить конфигурацию недостаточно — происходить кэширование DNS адресов в разных местах. Поэтому после обновления конфигурации кэши надо сбросить.
На клиенте с линуксом с systemd-resolve запускаем sudo systemd-resolve —flush-caches .
На клиенте с windows запускаем ipconfig /flushdns в командной строке с правами администратора.
В google chrome открываем страничку chrome://net-internals/#dns и сбрасываем кэш браузера.
Настройка Wireguard VPN
Про настройку wireguard я написал в отдельной статье.
Плач Ярославны
Ну и напоследок напишу почему всё это оказалось ненужным
Во-первых в какой-то момент МГТС отобрала настоящий IP и посадила всех за NAT. Почему-то в этот момент отвалился корпоративный VPN и в службе поддержки порекомендовали подключить выделенный IP.
Во-вторых после подключения выделенного IP перестал работать IPv6. Служба поддержки сообщила, что МГТС в принципе никогда и не поддерживал IPv6. Ну то есть IPv6 как-бы работает, но его работу не гарантируют. На форумах есть объяснение на эту тему — типа выделяют статический IP, но IPv6 статический выделить не могут и чтобы никого не смущать при подключении статического IP тупо обрубают v6.
Повысили тариф на 100 рубей, но это меньшее из зол, даже не в счет.
В-третьих тех поддержка МГТС ужасна. Сначала у меня был роутер sercomm rv6699 — вроде все более-менее работало. И это был не самый плохой вариант — там был telnet и доступ к iptables. Говорят его даже можно перепрошить. Был косяк — к внешнему IP адресу нельзя было достучаться из локальной сети по http и https — но это решалось удалениеми двух правил iptables. Но потом я решил назначить фиксированный канал сети WiFi 5ГГц. Канал не назначился — начал прыгать, я обратился в техподдержку и мне заменили роутер на ZTE ZXHN F680. И это оказалось полным концом. Он не пробрасывал DHCP пакеты из локальной сети в WiFi. Мою схему я использовать уже не мог. Техподдержкой был послан с заключением «в конфигурации по умолчанию странички грузятся, все остальное не наши проблемы». Думал может попробую использовать DNS от роутера, но там совсем шлак. Максимум можно настроить — 10 статических адресов в локальной сети. Статические и динамические адреса должны быть в одном диапазоне. В общем WiFi роутера не используется.
В-четрвертых у МГТС есть полный доступ к вашему роутеру. А иметь третье лицо, а вернее даже целую компанию в своей локальной сети — это как-то даже негигиенично.
Вывод — можно и МГТС, но отключать WiFi и переводить роутер в режим моста (не факт, что это можно сделать, не факт, что это не слетит после неотключаемого автообновления, не факт, что это не запретят).
Говорят, что роутер Sercomm RV6699 v4 можно перепрошить. Хотел попробовать, но не могу — у меня этого роутера больше нет — мне его заменили на ZTE ZXHN F680.
Еще говорят, что можно купить коробочку мене чем за 1.5 тыс. рублей и она будет работать бриджом — думаю это хороший вариант.
Как настроить маршрутизацию VPN-соединений?
Все машины клиентской сети сети имеют прозрачный VPN до сервера через роутер.
Клиент (192.168.100.102) может пинговать внутренний IP VPN сервера, но не может пинговать другие адреса из этой сети (например 172.16.0.4).
Лог с клиентской машины
D:\>ping 172.16.0.5 Pinging 172.16.0.5 with 32 bytes of data: Reply from 172.16.0.5: bytes=32 time=19ms TTL=62 Reply from 172.16.0.5: bytes=32 time=11ms TTL=62 Reply from 172.16.0.5: bytes=32 time=9ms TTL=62 Reply from 172.16.0.5: bytes=32 time=10ms TTL=62 Ping statistics for 172.16.0.5: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 9ms, Maximum = 19ms, Average = 12ms D:\>ping 172.16.0.4 Pinging 172.16.0.4 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 172.16.0.4: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), D:\>tracert -d 172.16.0.5 Tracing route to 172.16.0.5 over a maximum of 30 hops 1 tracert -d 172.16.0.4 Tracing route to 172.16.0.4 over a maximum of 30 hops 1
В тоже время сам роутер может достучаться до любой машины сети 172.16.0.0/24. Но в двух случаях роутинг разный.
Лог с роутера
root@vt-gw0:~# traceroute 172.16.0.5 traceroute to 172.16.0.5 (172.16.0.5), 30 hops max, 38 byte packets 1 172.16.0.5 (172.16.0.5) 3.592 ms 2.815 ms 2.808 ms root@vt-gw0:~# traceroute 172.16.0.4 traceroute to 172.16.0.4 (172.16.0.4), 30 hops max, 38 byte packets 1 10.8.0.1 (10.8.0.1) 11.759 ms 8.433 ms 4.442 ms 2 172.16.0.4 (172.16.0.4) 3.630 ms 2.962 ms 2.387 ms root@vt-gw0:~# root@vt-gw0:~# ping 172.16.0.5 PING 172.16.0.5 (172.16.0.5): 56 data bytes 64 bytes from 172.16.0.5: seq=0 ttl=64 time=9.557 ms 64 bytes from 172.16.0.5: seq=1 ttl=64 time=4.015 ms --- 172.16.0.5 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 4.015/6.786/9.557 ms root@vt-gw0:~# ping 172.16.0.4 PING 172.16.0.4 (172.16.0.4): 56 data bytes 64 bytes from 172.16.0.4: seq=0 ttl=63 time=14.421 ms 64 bytes from 172.16.0.4: seq=1 ttl=63 time=4.235 ms --- 172.16.0.4 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 4.235/9.328/14.421 ms root@vt-gw0:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun1 172.16.0.0 10.8.0.5 255.255.255.252 UG 0 0 0 tun1 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun1 172.16.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun1 192.168.10.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun1 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan2 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 vlan2 root@vt-gw0:~# ip route list 10.8.0.5 dev tun1 proto kernel scope link src 10.8.0.6 192.168.100.0/24 dev br0 proto kernel scope link src 192.168.100.1 10.8.0.0/24 via 10.8.0.5 dev tun1 172.16.0.0/24 via 10.8.0.5 dev tun1 192.168.10.0/24 via 10.8.0.5 dev tun1 192.168.10.0/24 dev vlan2 proto kernel scope link src 192.168.10.79 169.254.0.0/16 dev br0 proto kernel scope link src 169.254.255.1 127.0.0.0/8 dev lo scope link default via 192.168.10.1 dev vlan2Что бы такое сделать, чтобы клиентские машины видели IP адреса со всей сети 172.16.0.0/24, а не только адрес VPN сервера?
- Вопрос задан более трёх лет назад
- 16696 просмотров
Автоматическое добавление статических маршрутов после подключения к VPN
27.12.2022
itpro
Windows 10, Windows Server 2016
комментариев 14
В современных версиях Windows есть интересная возможность автоматического добавления статических маршрутов при активации определённого VPN подключения. Когда VPN подключение разрывается, данный маршрут автоматически удаляется из таблицы маршрутизации Windows. Для добавления IPv4 или IPv6 маршрута для VPN подключения используется PowerShell командлет Add-VpnConnectionRoute.
Вы конечно, можете вручную в командной строке добавлять нужные маршруты для VPN подключения, но главная проблема в том, что такие маршруты очищаются после отключения от VPN. Поэтому при следующем подключении, вам придется опять руками прописывать маршруты.
Допустим, вы хотите, чтобы через ваше VPN подключение маршрутизировались только пакеты для двух подсетей (192.168.111.24/ и 10.1.0.0/16), а весь основной трафик должен идти через вашего провайдера.
Откройте консоль PowerShell и выведите список всех настроенных VPN подключений в Windows:
Подробнее про управление VPN подключепиями в Windows с помощью PowerShell.
В первую очередь нужно отключить опцию “Use default gateway in remote network” (Использовать основной шлюз в удаленной сети). Это можно сделать в свойствах VPN подключения в панели управления или командой:
Set-VpnConnection –Name workVPN -SplitTunneling $True
Подробнее про SplitTunneling здесь.
Добавим два статических маршрута для нашего VPN-соединения:
Add-VpnConnectionRoute -ConnectionName «workVPN» -DestinationPrefix 192.168.111.0/24 –PassThru
Add-VpnConnectionRoute -ConnectionName «workVPN» -DestinationPrefix 10.1.0.0/16 –PassThruВ параметре DestinationPrefix нужно указать подсеть, или конкретный IP адрес хоста, трафик к которому нужно маршрутизировать через VPN. Для добавления одного IP адреса используйте формат 10.1.1.26/32.
DestinationPrefix : 192.168.111.0/24 InterfaceIndex : InterfaceAlias : workVPN AddressFamily : IPv4 NextHop : 0.0.0.0 Publish : 0 RouteMetric : 1
Если у вас активно VPN подключение, вам нужно переподключиться, чтобы новые маршруты добавились в таблицу маршрутизации.
Новые маршруты привязаны к VPN подключению и добавляются при его запуске. Когда вы отключаетесь от VPN сервера, маршруты автоматически удаляются.
Отключитесь от VPN и проверьте таблицу маршрутизации. Маршрут к вашей удаленной сети удалился автоматически, а Get-NetRoute вернет, что маршрут не найден:
Get-NetRoute : No MSFT_NetRoute objects found with property 'DestinationPrefix' equal to '192.168.111.0/24'. Verify the value of the property and retry. CmdletizationQuery_NotFound_DestinationPrefix,Get-NetRoute
Вывести список статических маршрутов для подключения:
(Get-VpnConnection -ConnectionName workVPN).RoutesЧтобы полностью удалить статических маршрут для VPN подключения, используйте команду:
Remove-VpnConnectionRoute -ConnectionName workVPN -DestinationPrefix 192.168.111.0/24 -PassThruЕсли вам нужно изменить порядок разрешения DNS имен при активном VPN, познакомьтесь со статьей.
В предыдущих версиях Windows (Windows 7/ Server 2008R2) для динамического добавления маршрутов после установления VPN подключений приходилось использовать CMAK и различные скрипты с командами add route .
Например, можно создать командный файл vpn_route.netsh для добавления маршрутов.
interface ipv4
add route prefix=192.168.111.24 interface=»workVPN» store=active
add route prefix=10.1.0.0/16 interface=»workVPN» store=active
exitДанный файл нужно запускать через задание планировщика, которое срабатывает на событие установки VPN подключения в Event Viewer (RasMan 20225)
schtasks /create /F /TN «Add VPN routes» /TR «netsh -f C:\PS\vpn_route.netsh» /SC ONEVENT /EC Application /RL HIGHEST /MO «*[System[(Level=4 or Level=0) and (EventID=20225)]] and *[EventData[Data=’My VPN’]]»
Предыдущая статья Следующая статья 