Route add windows пример для vpn

Добрый день, уважаемые читатели. Недавно столкнулся с одной проблемой, один из моих клиентов попросил настроить VPN тоннель на роутере для связи с одним из его серверов, я это настроил, но заметил, что после добавления VPN соединения на ПК с которого я подключаюсь к VPN серверу, доступ в интернет начинает по умолчанию идти через VPN подключение (что напрочь убивает скорость интернета на ПК). Я долго искал в интернете способы решения данного вопроса, но ничего толкового я не нашел.  Однако я понимал что дело в маршруте через который идет доступ в Интернет. Я долго копался в метриках и маршрутах и решил данную проблему следующим образом:

1. Заходим в центр управления сетями и общим доступом и переходим во вкладку изменение параметров адаптера:

2. Кликаем правой клавишей по ранее созданному VPN подключению, заходим в свойства, в свойствах находим раздел Сеть и заходим в настройки протокола Интернет версии 4.

О том как создать VPN подключение на ПК под управлением ОС семейства Windows я писал в своей статье.

3. Далее переходим во вкладку дополнительно:

4. Чтобы не использовать VPN сервер основным маршрутом выхода в Интернет ставим галочку на пункте «Отключить добавление маршрута основанное на классе» и сохраняем изменения.

Для доступа к серверу через VPN подключение добавляем маршрут в командной строке, открытой от имени Администратора.

route add 192.168.9.0 mask 255.255.255.0 192.168.2.1, где 192.168.9.0 — сетевой адрес, 255.255.255.0 — сетевая маска, 192.168.9.0 — сетевой шлюз (IP адреса настроенные на VPN сервере)

После этого при работе с VPN выход в интернет будет осуществляться через наш основной шлюз, т.е. проблема решена.

Организация каналов между удаленными сетями посредством VPN-соединения одна из самых популярных тем на нашем сайте. В тоже время, как показывает читательский отклик, наибольшие затруднения вызывает правильная настройка маршрутизации, хотя мы специально уделяли внимание этому моменту. Проанализировав наиболее часто задаваемые вопросы, мы решили посвятить теме маршрутизации отдельную статью. Есть вопросы? Надеемся, что после прочтения данного материала их станет меньше.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Прежде всего разберемся, что такое маршрутизация. Маршрутизация — это процесс определения маршрута следования информации в сетях связи. Скажем честно, тема эта весьма глубокая и требующая солидного багажа теоретических знаний, поэтому в рамках данной статьи мы сознательно упростим картину и коснемся теории ровно в той мере, которой будет достаточно для осмысления происходящих процессов и получения практических результатов.

Возьмем произвольную рабочую станцию, подключенную к сети, каким образом она определяет куда посылать тот или иной пакет? Для этой цели предназначена таблица маршрутизации, которая содержит перечень правил для всех возможных адресов назначения. На основании этой таблицы хост (или маршрутизатор) принимают решение, на какой интерфейс и адрес назначения отправить пакет, адресованный определенному получателю.

Чтобы не быть голословными рассмотрим таблицу маршрутов самой обыкновенной рабочей станции. В Windows системах это можно сделать командой:

route print

В итоге мы увидим следующую таблицу:

Все очень просто, нас интересует секция IPv4 таблица маршрута, первые две колонки содержат адрес назначения и маску сети, затем следует шлюз — узел которому следует перенаправить пакеты для указанного назначения, интерфейс и метрика. Если в колонке Шлюз указано On-link, то это означает что адрес назначения находится в одной сети с хостом и доступен без маршрутизации. Метрика определяет приоритет правил маршрутизации, если адрес назначения имеет в таблице маршрутов несколько правил, то используется тот, что имеет меньшую метрику.

Наша рабочая станция принадлежит к сети 192.168.31.0 и, согласно таблице маршрутов, все запросы к данной сети отправляет на интерфейс 192.168.31.175, что соответствует сетевому адресу это станции. Если адрес назначения находится в одной сети с адресом источником, то доставка информации происходит без использования IP-маршрутизации (сетевой уровень L3 модели OSI), на канальном уровне (L2). В противном случае пакет отправляется узлу, указанному в соответствующему сети назначения правилу таблицы маршрутов.

Если такого правила нет, то пакет отправляется по нулевому маршруту, который содержит адрес основного шлюза сети. В нашем случае это адрес роутера 192.168.31.100. Нулевым этот маршрут называется потому, что адресом назначения для него указывается 0.0.0.0. Этот момент является очень важным для дальнейшего понимания процесса маршрутизации: все пакеты, не принадлежащие данной сети и не имеющие отдельных маршрутов, всегда отправляются основному шлюзу сети.

Что сделает маршрутизатор, получив такой пакет? Прежде всего разберемся, чем отличается маршрутизатор от обычной сетевой станции. Если говорить крайне упрощенно, то маршрутизатором (роутером) является сетевое устройство, которое настроено передавать пакеты между сетевыми интерфейсами. В Windows это достигается включением службы Маршрутизация и удаленный доступ, в Linux заданием опции ip_forward.

Решение о передаче пакетов в этом случае также принимается на основании таблицы маршрутизации. Посмотрим, что содержит данная таблица на самом обычном роутере, например, описанном нами в статье: Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3. В Linux-системах получить таблицу маршрутов можно командой:

route -n

Как видим, наш роутер содержит маршруты к известным ему сетям 192.168.31.0 и 192.168.3.0, а также нулевой маршрут к вышестоящему шлюзу 192.168.3.1.

Адрес 0.0.0.0 в колонке шлюза (Gateway) обозначает, что адрес назначения доступен без маршрутизации. Таким образом все пакеты с адресами назначения в сетях 192.168.31.0 и 192.168.3.0 будут отправлены на соответствующий интерфейс, а все остальные пакеты будут переданы дальше по нулевому маршруту.

Следующий важный момент — адреса приватных (частных) сетей, они же «серые», к ним относятся три диапазона:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Данные адреса могут свободно использоваться любым желающим и поэтому они не маршрутизируются. Что это значит? Любой пакет с адресом назначения принадлежащим одной из этих сетей будет отброшен маршрутизатором, если для него нет отдельной записи в таблице маршрутизации. Проще говоря, маршрут по умолчанию (нулевой) для таких пакетов маршрутизатором не применяется. Также следует понимать, что данное правило применяется только при маршрутизации, т.е. при передаче пакетов между интерфейсами, исходящий пакет с «серым» адресом будет отправлен по нулевому маршруту, даже если данный узел сам является маршрутизатором.

Например, если наш роутер получит входящий пакет с назначением, скажем, 10.8.0.1, то он будет отброшен, так как такая сеть ему неизвестна и адреса этого диапазона не маршрутизируются. Но если мы обратимся к этому же узлу непосредственно с роутера, то пакет будет отправлен по нулевому маршруту шлюзу 192.168.3.1 и будет отброшен уже им.

Самое время проверить, как это все работает. Попробуем с нашего узла 192.168.31.175 пропинговать узел 192.168.3.106, который находится в сети за роутером. Как видим, это нам удалось, хотя таблица маршрутов узла не содержит никаких сведений о сети 192.168.3.0.

Как это стало возможным? Так как узел-источник ничего не знает о сети назначения, то он отправит пакет на адрес шлюза. Шлюз проверит свою таблицу маршрутов, обнаружит там запись для сети 192.168.3.0 и отправит пакет на соответствующий интерфейс, в этом несложно убедиться выполнив команду трассировки, которая покажет весь путь нашего пакета:

tracert 192.168.3.106

Теперь попробуем выполнить пинг узла 192.168.31.175 с узла 192.168.3.106, т.е. в обратном направлении. У нас ничего не вышло. Почему?

Давайте внимательно посмотрим таблицу маршрутизации. Никаких записей для сети 192.168.31.0 она не содержит, поэтому пакет будет отправлен маршрутизатору 192.168.3.1, как основному шлюзу сети, который данный пакет отбросит, так как никаких данных о сети назначения не имеет. Как быть? Очевидно, что следует отправить пакет тому узлу, который содержит нужную информацию и может передать пакет по назначению, в нашем случае это роутер 192.168.31.100, который в данной сети имеет адрес 192.168.3.108.

Чтобы пакеты для сети 192.168.31.0 отправлялись именно ему, нам нужно создать отдельный маршрут.

192.168.31.0 mask 255.255.255.0 192.168.3.108

В дальнейшем мы будем придерживаться такой записи маршрутов, что она значит? Все просто, пакеты для сети 192.168.31.0 с маской 255.255.255.0 следует отправлять узлу 192.168.3.108. В Windows маршрут можно добавить командой:

route add 192.168.31.0 mask 255.255.255.0 192.168.3.108

В Linux:

route add -net 192.168.31.0 netmask 255.255.255.0 gw 192.168.3.108

Попробуем.

Давайте проанализируем результат, в таблице маршрутизации появился маршрут и все пакеты к сети 192.168.31.0 теперь отправляются роутеру этой сети, что видно из ответа команды ping, но до назначения не доходят. В чем дело? Самое время вспомнить, что одной из основных задач роутера является не только маршрутизация, но и функция сетевого экрана, который явно запрещает доступ из внешней сети внутрь. Если мы временно заменим данное правило разрешающим, то все будет работать.

Добавленные вышеуказанными командами маршруты сохраняются до перезагрузки узла, это удобно, даже если вы сильно накуролесили, достаточно просто выполнить перезагрузку, чтобы отменить внесенные изменения. Чтобы добавить постоянный маршрут в Windows выполните команду:

route add 192.168.31.0 mask 255.255.255.0 192.168.3.108 -p

В Linux в /etc/network/interfaces, после описания интерфейса, следует добавить:

post-up route add -net 192.168.31.0 netmask 255.255.255.0 gw 192.168.3.108

Кстати, это не единственный способ настроить доступ из сети 192.168.3.0 в сеть 192.168.31.0, вместо того, чтобы добавлять маршрут для каждого узла, можно «научить» правильно отправлять пакеты маршрутизатор.

В этом случае узел источник не имеет записей о сети назначения и отправит пакет шлюзу, в прошлый раз шлюз такой пакет отбросил, но теперь мы добавили в его таблицу маршрутизации нужный маршрут, и он отправит пакет узлу 192.168.3.108, который доставит его по назначению.

Мы настоятельно рекомендуем самим потренироваться на аналогичных примерах, чтобы маршрутизация перестала быть для вас черным ящиком, а маршруты — китайской грамотой. После того как возникнет понимание, можно переходит ко второй части данной статьи.

Теперь рассмотрим реальные примеры по объединению сетей офисов через VPN-соединение. Несмотря на то, что чаще всего для этих целей используется OpenVPN и в наших примерах мы также подразумеваем решения на его основе, все сказанное будет справедливо для любого типа VPN-соединения.

Самый простой случай, когда VPN-сервер (клиент) и маршрутизатор сети располагаются на одном хосте. Рассмотрим схему ниже:

Так как теорию, надеемся, вы усвоили и закрепили на практике, проанализируем маршрут пакетов из сети офиса 192.168.31.0 в сеть филиала 192.168.44.0, такой пакет будет отправлен на шлюз по умолчанию, который является также VPN-сервером. Однако данный узел ничего не знает о сети назначения и должен будет откинуть данный пакет. В тоже время мы уже можем обратиться к маршрутизатору филиала по его адресу в VPN-сети 10.8.0.2, так как данная сеть доступна с маршрутизатора офиса.

Чтобы получить доступ к сети филиала нам нужно предать пакеты для этой сети узлу, который является частью этой сети или имеет маршрут к ней. В нашем случае это маршрутизатор филиала. Поэтом на маршрутизаторе офиса добавляем маршрут:

192.168.44.0 mask 255.255.255.0 10.8.0.2

Теперь шлюз офиса, получив пакет для сети филиала, отправит его через VPN-канал маршрутизатору филиала, который, являясь узлом сети 192.168.44.0 доставит пакет по назначению. Для доступа из сети филиала в сеть офиса нужно прописать аналогичный маршрут на маршрутизаторе филиала.

Возьмем схему посложнее, когда маршрутизатор и VPN-сервер (клиент) являются разными узлами сети. Здесь возможны два варианта, передать нужный пакет непосредственно VPN-серверу (клиенту) или заставить это делать шлюз.

Сначала рассмотрим первый вариант.

Для того, чтобы пакеты для сети филиала попали в VPN-сеть мы должны добавить на каждый клиент сети маршрут к VPN-серверу (клиенту), в противном случае они будут отправлены шлюзу, который их отбросит:

192.168.44.0 mask 255.255.255.0 192.168.31.101

Однако VPN-сервер ничего не знает о сети филиала, но может отправлять пакеты в пределах VPN-сети, где есть интересующий нас узел сети филиала, поэтому направим пакет туда, добавив на VPN-сервере (клиенте) маршрут:

192.168.44.0 mask 255.255.255.0 10.8.0.2

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

В этом случае сетевые устройства офиса ничего не знают о сети филиала и отправят пакеты для него по нулевому маршруту, шлюзу сети. Теперь задача шлюза перенаправить этот пакет VPN-серверу (клиенту), это просто сделать, добавив в его таблицу маршрутизации нужный маршрут:

192.168.44.0 mask 255.255.255.0 192.168.31.101

Про задачу VPN-сервера (клиента) мы упоминали выше, он должен доставить пакеты тому узлу VPN-сети, который является частью сети назначения или имеет маршрут к ней.

192.168.44.0 mask 255.255.255.0 10.8.0.2

Для доступа из сети филиала в сеть офиса потребуется добавить соответствующие маршруты на сетевые узлы филиала. Сделать это можно любым удобным способом, не обязательно также, как это сделано в офисе. Простой реальный пример: все компьютеры филиала должны иметь доступ к сети офиса, но не все компьютеры офиса должны иметь доступ в филиал. В таком случае в филиале добавляем маршрут к VPN-серверу (клиенту) на маршрутизаторе, а в офисе добавляем его только на нужные компьютеры.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

В современных версиях 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:

Get-VpnConnection

В первую очередь нужно отключить опцию “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:PSvpn_route.netsh" /SC ONEVENT /EC Application /RL HIGHEST /MO "*[System[(Level=4 or Level=0) and (EventID=20225)]] and *[EventData[Data='My VPN']]"

A ‘short’ guide for noobs like me, who don’t know much about networks. Not much new here, but a summary of all good options described in previous answers and in other related threads. Whole procedure consists of 3 basic steps:

1) Make all traffic NOT going via VPN. For this you must uncheck Use default gateway on remote network checkbox in VPN settings. Make sure to uncheck this checkbox for both IPv4 and IPv6. Usually I simply disable IPv6 protocol completely for VPN connection.

(!) It is (sometimes) possible that unchecking that checkbox will be enough for normal work — in my experience, necessary routes (which will direct necessary traffic via VPN) can be added automatically after VPN connection is established. I don’t know exactly where and how these rules are configured, but such scenario exists — probably it is some magic done by VPN network administrators.

2) Make only necessary traffic going via VPN. For this you need to define routes. Here you have 3 options:

2.1) Add permanent route via VPN gateway:

route -p add a.b.c.d/<CIDR> w.x.y.z or route -p add a.b.c.d mask e.f.g.h w.x.y.z

where ‘VPN gateway’ = ‘your IP on VPN network’ = w.x.y.z and target address/network = a.b.c.d. You can find w.x.y.z by executing ipconfig and looking for your VPN connection name or, if you use PowerShell, you can get compact output by executing ipconfig | grep -A5 PPP (which will output 5 lines after finding each PPP connection).

Cons: you will have to re-create routes if your VPN IP will change.

2.2) Add permanent route via VPN network interface:

route -p add a.b.c.d/<CIDR> 0.0.0.0 IF <interface number>

where a.b.c.d is the target address/network and interface number is identifier of your VPN connection. This ID can be found by executing netstat -rn, or, for more compact output, netstat -rn | grep -A10 'Interface List'.

Pros: no need to change anything if your VPN address (w.x.y.z) will change.

Cons: need to re-create routes with new ID if you delete your VPN connection.

2.3) Use PowerShell cmdlet:

Add-VpnConnectionRoute -ConnectionName '<VPN connection name>' -DestinationPrefix a.b.c.d/<CIDR>

Pros: necessary routes are added each time VPN connection is established and deleted each time it is disconnected.

Cons: there is no Get-VpnConnectionRoutes cmdlet so it can be hard to manage these rules.

3) Check and ensure routing works as expected!

If you added persistent routes, you can check them by executing netstat -rn | grep -A10 'Persistent Routes'.

And, finally, run a few tracert commands against both IP addresses which are supposed to be accessed via VPN and against those which should work without VPN.

Автоматическое добавление статических маршрутов после подключения к VPN

В современных версиях Windows есть интересная возможность автоматического добавления статических маршрутов при активации определённого VPN подключения. Когда VPN подключение разрывается, данный маршрут автоматически удаляется из таблицы маршрутизации Windows. Для добавления IPv4 или IPv6 маршрута для VPN подключения используется PowerShell командлет Add-VpnConnectionRoute.

Допустим, вы хотите, чтобы через ваше VPN подключение маршрутизировались только пакеты для двух подсетей (192.168.111.24/ и 10.1.0.0/16), а весь основной трафик должен идти через вашего провайдера.

Откройте консоль PowerShell и выведите список всех настроенных VPN подключений в Windows:

В первую очередь нужно отключить опцию “Use default gateway in remote network” (Использовать основной шлюз в удаленной сети). Это можно сделать в свойствах VPN подключения в панели управления или командой:

Добавим два статических маршрута для нашего VPN-соединения:

Если у вас активно VPN подключение, вам нужно переподключиться, чтобы новые маршруты добавились в таблицу маршрутизации.

Новые маршруты привязаны к VPN подключению и добавляются при его запуске. Когда вы отключаетесь от VPN сервера, маршруты автоматически удаляются.

Отключитесь от VPN и проверьте таблицу маршрутизации. Маршрут к вашей удаленной сети удалился автоматически, а Get-NetRoute вернет, что маршрут не найден:

Например, можно создать командный файл 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)

Источник

RussianProxy.ru

Навигация

Вход на сайт

По умолчанию, после установки RussianProxy VPN соединения ВЕСЬ трафик идёт через vpn сервер, то есть адрес нашего сервера становится основным шлюзом для всего интернет трафика. Однако, иногда возникает необходимость в других настройках vpn соединения, как то:

Для того чтобы реализовать оба варианта Вам потребуется настройка таблицы маршрутизации, которую можно посмотреть выполнив команду route print.

На пакетах с динамическим выделенным IP возможен вариант прописавыния маршрута средствами CMD:

echo ===Routing=====================================================================
for /f «tokens=2 delims=:» %%a in (‘ipconfig ^| find /i «46.183.162.»‘) do (set «IP=%%a»)
route add 91.202.44.0 mask 255.255.255.0 %IP%
route add 92.63.99.78 mask 255.255.255.255 %IP%

Строка `for /f «tokens=2 delims=:» %%a in (‘ipconfig ^| find /i «46.183.162.»‘) do (set «IP=%%a»)` поместит в переменную `%IP%` текущий IP адрес, присвоенный VPN-соединению.

Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 276 127.0.0.0 255.0.0.0 On-link
127.0.0.1 306 127.0.0.1 255.255.255.255 On-link
127.0.0.1 306 127.255.255.255 255.255.255.255 On-link
127.0.0.1 306 192.168.1.0 255.255.255.0 On-link
192.168.1.100 276 192.168.1.100 255.255.255.255 On-link
192.168.1.100 276 192.168.1.255 255.255.255.255 On-link
192.168.1.100 276 224.0.0.0 240.0.0.0 On-link
127.0.0.1 306 224.0.0.0 240.0.0.0 On-link
192.168.1.100 276 255.255.255.255 255.255.255.255 On-link
127.0.0.1 306 255.255.255.255 255.255.255.255 On-link
192.168.1.100 276 ===========================================================================

Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию =========================================================================== Видно, что ВЕСЬ трафик идет через постоянный маршрут по умолчанию:

0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию

Удалим его: route delete 0.0.0.0

Теперь мы не можем достигнуть ни одного адреса за пределами локальной сети 192.1.1.* Далее нам нужно прописать маршрут до нашего впн сервера 46.183.162.5:

После этого наша таблица маршрутизации примет такой вид:

IPv4 таблица маршрута =========================================================================== Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
127.0.0.0 255.0.0.0 On-link
127.0.0.1 306 127.0.0.1 255.255.255.255 On-link
127.0.0.1 306 127.255.255.255 255.255.255.255 On-link
127.0.0.1 306 192.168.1.0 255.255.255.0 On-link
192.168.1.100 276 192.168.1.100 255.255.255.255 On-link
192.168.1.100 276 192.168.1.255 255.255.255.255 On-link
192.168.1.100 276 46.183.162.5 255.255.255.255
192.168.1.1 192.168.1.100 21 224.0.0.0 240.0.0.0 On-link
127.0.0.1 306 224.0.0.0 240.0.0.0 On-link
192.168.1.100 276 255.255.255.255 255.255.255.255 On-link
127.0.0.1 306 255.255.255.255 255.255.255.255 On-link
192.168.1.100 276 =========================================================================== Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
46.183.162.5 255.255.255.255 192.168.1.1 1 ===========================================================================

IPv4 таблица маршрута =========================================================================== Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика

0.0.0.0 0.0.0.0 On-link 46.183.162.31 21 127.0.0.0 255.0.0.0 On-link
127.0.0.1 4531 127.0.0.1 255.255.255.255 On-link
127.0.0.1 4531 127.255.255.255 255.255.255.255 On-link
127.0.0.1 4531 192.168.1.0 255.255.255.0 On-link
192.168.1.100 4501 192.168.1.100 255.255.255.255 On-link
192.168.1.100 4501 192.168.1.255 255.255.255.255 On-link
192.168.1.100 4501 46.183.162.31 255.255.255.255 On-link
46.183.162.31 276 46.183.162.5 255.255.255.255
192.168.1.1 192.168.1.100 4246 224.0.0.0 240.0.0.0 On-link
127.0.0.1 4531 224.0.0.0 240.0.0.0 On-link
192.168.1.100 4502 224.0.0.0 240.0.0.0 On-link
46.183.162.31 21 255.255.255.255 255.255.255.255 On-link
127.0.0.1 4531 255.255.255.255 255.255.255.255 On-link
192.168.1.100 4501 255.255.255.255 255.255.255.255 On-link
46.183.162.31 276 =========================================================================== Постоянные маршруты:

Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30:
1 16 ms 16 ms 17 ms AIS [46.183.162.1]
2 20 ms 21 ms 20 ms v1505.th-1.caravan.ru [212.158.160.2]
3 16 ms 17 ms 16 ms v811.m9-3.caravan.ru [212.24.42.49]
4 20 ms 25 ms 21 ms ix2-m9.yandex.net [193.232.244.93]
5 23 ms 20 ms 18 ms ya.ru [213.180.204.8] Трассировка завершена. ===============================================================

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Автоматическое добавление маршрутов для VPN-соединения в Windows

Подключение средствами ОС в этом плане более привлекательно, так как позволяет снять большую часть указанных выше проблем и подразумевает единообразие пользовательского интерфейса, что позволяет сделать простые и понятные инструкции.

Но вернемся к нашему вопросу. Для добавления маршрутов в удаленную сеть традиционно использовали несколько методов:

В тоже время начиная с Windows 8 существует штатное решение в виде командлета PowerShell, которое позволяет привязать маршруты к VPN-подключению и добавлять их при его запуске, при отключении соединения маршруты будут автоматически удалены.

Запустим консоль PowerShell и прежде всего узнаем имена имеющихся в системе VPN-подключений:

Результатом работы команды будет информация обо всех коммутируемых подключениях, нас интересует поле Name:

Теперь добавим маршрут к удаленной сети для подключения с именем L2TP MT:

Теперь проверим как это все работает. Проверим таблицу маршрутизации при отключенном VPN-подключении и убедимся, что маршруты в удаленную сеть отсутствуют:

Данная команда добавит маршрут к узлу 192.168.111.101, к другим узлам удаленной сети доступа у VPN-пользователя не будет.

Чтобы удалить маршрут следует воспользоваться командой Remove-VPNConnectionRoute, синтаксис которой полностью повторяет команду добавления маршрута:

Как видим, современные версии Windows дают нам в руки достаточно простой и удобный инструмент управления маршрутами для VPN-подключений.

Важно! Данные возможности не поддерживаются в Windows 7.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Настройка VPN в Windows, изменение параметров маршрутизации

Часто бывает, когда нам требуется VPN соединение с рабочей сетью из дома. Для начала нам требуется создать этот самый VPN, конечно при условии, что есть сервер, к которому мы будем подключаться, а так же логин и пароль для авторизации. После того как мы создаём соединение в WINDOWS, подключаемся, кроме доступа к сети мы ещё и получаем интернет, который так же работает через рабочую сеть. А это по разным причинам может быть не всегда удобно, низкая скорость каналов, большие задержки ping, есть ограничения на доступ к ресурсам и т.д.

В этой статье коротко о том, как создать подключение к VPN. А так же как настроить маршрутизацию для туннеля, созданного стандартными средствами windows (7/8/10/2012/2016), так, что бы через него шёл только тот трафик, который нам необходим.

1. Создание подключения.
1.1 Переходим в центр управления сетями и общим доступом. (нажать на значок сети правой кнопкой мыши)

1.2 Выбираем «Создание и настройка нового подключения или сети»

1.3 Выбираем «Подключение к рабочему месту»

1.4 Выбираем «Использовать мое подключение к интернету»

1.5 Указываем IP адрес или доменное имя вашего сервера. Вводим название нашего подключения

1.6 Далее (для win 8/10) нажимаем на панели задач на значок сети, выбираем подключение, нажимаем на него левой кнопкой мыши

1.7 Находим подключение с нашим названием, нажимаем левой кнопкой мыши, нажимаем кнопку подключиться.

1.8 Вводим логин и пароль.

После этого подключение должно работать.

Но что же делать, если нам надо пустить через VPN только какую-то часть трафика, например для определённых сетей?

2. Настройка маршрутизации для VPN подключения

2.1 Заходим снова в центр управления сетями и общим доступом. (нажать на значок сети правой кнопкой мыши)

2.2 Выбираем раздел «Изменение параметров адаптера»

2.3 Находим наше VPN подключение, нажимаем правой кнопкой мыши и выбираем пункт «Свойства»

2.4 Переходим на вкладку «Сеть» и нажимаем кнопку «Свойства»

2.5 Находим кнопку «Дополнительно»

2.6 На вкладке «Параметры IP» убираем галочку «Использовать основной шлюз удалённой сети»

Закрываем все окна, нажимая кнопку «ОК», пока не дойдём до окошка с вашим VPN. Как показано в пункте 1.6 подключаем соединение. Всё, теперь подключение установлено, но в удалённую сеть не будет идти никакой трафик, т.к мы отключили использование шлюза и ничего не добавили в маршрутизацию.

3. Настройка маршрутизации

3.1 Нажимаем снова на Ваше подключение правой кнопкой мыши, выбираем пункт «Подробно», если его нет, то «Состояние». Но тогда придётся сначала подключить Ваше VPN, зайти в состояние, посмотреть адрес шлюза и записать его.

3.2 В разделе «Подробно» смотрим на поле «Адрес сервера», записываем данные.

3.3 Открываем поиск, в панели задач и вводим cmd (командная строка)

route add 192.168.0.0 MASK 255.255.255.0 172.239.0.1

После введения команды нажимаем Enter.

Источник

Add-Vpn Connection Route

Adds a route to a VPN connection.

Syntax

Description

The Add-VpnConnectionRoute cmdlet adds an IPv4 or IPv6 route to a specified VPN connection.

Examples

Example 1: Add a VPN connection route for an IPv4 address

This command uses the Add-VpnConnectionRoute cmdlet to add a connection route for the connection named Contoso. The command specifies an IPv4 address for the DestinationPrefix parameter.

Example 2: Add a VPN connection for an IPv6 address

This command uses the Add-VpnConnectionRoute cmdlet to add a connection route for the connection named Contoso. The command specifies an IPv6 address for the DestinationPrefix parameter.

Parameters

Indicates that the VPN connection being modified is in the global phone book.

Runs the cmdlet as a background job. Use this parameter to run commands that take a long time to complete.

Runs the cmdlet in a remote session or on a remote computer. Enter a computer name or a session object, such as the output of a New-CimSession or Get-CimSession cmdlet. The default is the current session on the local computer.

Prompts you for confirmation before running the cmdlet.

Specifies the name of a VPN connection profile. To view existing VPN connection profiles, use the Get-VpnConnection cmdlet.

Specifies the destination prefix of the route to add.

Returns an object representing the item with which you are working. By default, this cmdlet does not generate any output. If you specify this parameter, the cmdlet returns the MSFT_NetRoute object.

Specifies the metric of the route being added to the VPN connection.

Specifies the maximum number of concurrent operations that can be established to run the cmdlet. If this parameter is omitted or a value of 0 is entered, then Windows PowerShellВ® calculates an optimum throttle limit for the cmdlet based on the number of CIM cmdlets that are running on the computer. The throttle limit applies only to the current cmdlet, not to the session or to the computer.

Shows what would happen if the cmdlet runs. The cmdlet is not run.

Источник

По умолчанию, после установки RussianProxy VPN соединения ВЕСЬ трафик идёт через vpn сервер, то есть адрес нашего сервера становится основным шлюзом для всего интернет трафика. Однако, иногда возникает необходимость в других настройках vpn соединения, как то:

• 1 вариант: после установления vpn соединения, пустить весь трафик через основного провайдера интернета, и только трафик на определённые IP адреса, например только на подсеть IP адресов игры Lineage 2, пустить напрямую, минуя впн соединение.
• 2 вариант. после установления vpn соединения, пустить весь трафик через RussianProxy VPN соединение, и только трафик для некоторых IP адресов, пустить через vpn соединение.
• 3 вариант. Вы хотите чтобы весь трафик шел через RussianProxy VPN соединение, даже в случае разрыва соединения или при старте операционной системы.

Для того чтобы реализовать оба варианта Вам потребуется настройка таблицы маршрутизации, которую можно посмотреть выполнив команду route print.

Рассмотрим пример реализации первого варианта на конкретном примере — нужно, чтобы при установленном RussianProxy VPN соединении, через него шёл трафик только для сайта http://ping.eu, весь остальной трафик бы шёл через стандартного провайдера интернет.

Неудобство такого способа заключается в том, что Вам придётся прописывать маршрут каждый раз после соединения с VPN. Однако, если у Вас тариф VPN с выделенным IP, Вы можете прописать постоянный маршрут один раз и больше не заботиться о его постоянном прописывании.
route add адрес_сайта ваш_постоянный_IP -p — постоянный маршрут для одного сайта
route add адрес_сайта mask маска_подсетки ваш_постоянный_IP -p — постоянный маршрут для подсети IP адресов

На пакетах с динамическим выделенным IP возможен вариант прописавыния маршрута средствами CMD:

echo ===Dialing=====================================================================
rasdial «VPN Connection Name» LOGIN PASSWORD

echo ===Routing=====================================================================
for /f «tokens=2 delims=:» %%a in (‘ipconfig ^| find /i «46.183.162.»‘) do (set «IP=%%a»)
route add 91.202.44.0 mask 255.255.255.0 %IP%
route add 92.63.99.78 mask 255.255.255.255 %IP%

Строка `for /f «tokens=2 delims=:» %%a in (‘ipconfig ^| find /i «46.183.162.»‘) do (set «IP=%%a»)` поместит в переменную `%IP%` текущий IP адрес, присвоенный VPN-соединению.

Теперь рассмотрим третий вариант.
Сделаем это на конкретном примере.
Имеется компьютер подключенный к интернету через роутер 192.1.1.1. Мы хотим чтобы ни один байт не ушел в интернет напрямую через роутер, минуя наше vpn соединение. Для начала определим на какой единственный адрес может идти трафик через роутер — это адрес впн сервера:
nslookup pptp-l2tp-vpn-russia-1.atomintersoft.com -> 46.183.162.5

Рассмотрим таблицу маршрутизации —
route print:

IPv4 таблица маршрута =========================================================================== Активные маршруты:

Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 276 127.0.0.0 255.0.0.0 On-link
127.0.0.1 306 127.0.0.1 255.255.255.255 On-link
127.0.0.1 306 127.255.255.255 255.255.255.255 On-link
127.0.0.1 306 192.168.1.0 255.255.255.0 On-link
192.168.1.100 276 192.168.1.100 255.255.255.255 On-link
192.168.1.100 276 192.168.1.255 255.255.255.255 On-link
192.168.1.100 276 224.0.0.0 240.0.0.0 On-link
127.0.0.1 306 224.0.0.0 240.0.0.0 On-link
192.168.1.100 276 255.255.255.255 255.255.255.255 On-link
127.0.0.1 306 255.255.255.255 255.255.255.255 On-link
192.168.1.100 276 ===========================================================================

Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию =========================================================================== Видно, что ВЕСЬ трафик идет через постоянный маршрут по умолчанию:

0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию

Удалим его: route delete 0.0.0.0

Теперь мы не можем достигнуть ни одного адреса за пределами локальной сети 192.1.1.* Далее нам нужно прописать маршрут до нашего впн сервера 46.183.162.5:

route add 46.183.162.5 192.168.1.1 -p

После этого наша таблица маршрутизации примет такой вид:

IPv4 таблица маршрута =========================================================================== Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
127.0.0.0 255.0.0.0 On-link
127.0.0.1 306 127.0.0.1 255.255.255.255 On-link
127.0.0.1 306 127.255.255.255 255.255.255.255 On-link
127.0.0.1 306 192.168.1.0 255.255.255.0 On-link
192.168.1.100 276 192.168.1.100 255.255.255.255 On-link
192.168.1.100 276 192.168.1.255 255.255.255.255 On-link
192.168.1.100 276 46.183.162.5 255.255.255.255
192.168.1.1 192.168.1.100 21 224.0.0.0 240.0.0.0 On-link
127.0.0.1 306 224.0.0.0 240.0.0.0 On-link
192.168.1.100 276 255.255.255.255 255.255.255.255 On-link
127.0.0.1 306 255.255.255.255 255.255.255.255 On-link
192.168.1.100 276 =========================================================================== Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
46.183.162.5 255.255.255.255 192.168.1.1 1 ===========================================================================

То есть доступен только один адрес в интернете — 46.183.162.5 — а это и есть адрес нашего впн сервера.
Не забудьте в настройках впн соединения вписать именно IP адрес 46.183.162.5, а не доменное имя pptp-l2tp-vpn-russia-1.atomintersoft.com. Теперь запускаем наше RussianProxy VPN соединение и весь интернет трафик, за исключением трафика до нашего впн сервера, пойдет через шифрованное со сжатием впн соединение. Итоговая таблица маршрутизации при установленном впн соединении выглядит в нашем случае так:

IPv4 таблица маршрута =========================================================================== Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика

0.0.0.0 0.0.0.0 On-link 46.183.162.31 21 127.0.0.0 255.0.0.0 On-link
127.0.0.1 4531 127.0.0.1 255.255.255.255 On-link
127.0.0.1 4531 127.255.255.255 255.255.255.255 On-link
127.0.0.1 4531 192.168.1.0 255.255.255.0 On-link
192.168.1.100 4501 192.168.1.100 255.255.255.255 On-link
192.168.1.100 4501 192.168.1.255 255.255.255.255 On-link
192.168.1.100 4501 46.183.162.31 255.255.255.255 On-link
46.183.162.31 276 46.183.162.5 255.255.255.255
192.168.1.1 192.168.1.100 4246 224.0.0.0 240.0.0.0 On-link
127.0.0.1 4531 224.0.0.0 240.0.0.0 On-link
192.168.1.100 4502 224.0.0.0 240.0.0.0 On-link
46.183.162.31 21 255.255.255.255 255.255.255.255 On-link
127.0.0.1 4531 255.255.255.255 255.255.255.255 On-link
192.168.1.100 4501 255.255.255.255 255.255.255.255 On-link
46.183.162.31 276 =========================================================================== Постоянные маршруты:

Сетевой адрес Маска Адрес шлюза Метрика
46.183.162.5 255.255.255.255 192.168.1.1 1 =========================================================================== Трассировка до сайта ya.ru выглядит так: ===============================================================

Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30:
1 16 ms 16 ms 17 ms AIS [46.183.162.1]
2 20 ms 21 ms 20 ms v1505.th-1.caravan.ru [212.158.160.2]
3 16 ms 17 ms 16 ms v811.m9-3.caravan.ru [212.24.42.49]
4 20 ms 25 ms 21 ms ix2-m9.yandex.net [193.232.244.93]
5 23 ms 20 ms 18 ms ya.ru [213.180.204.8] Трассировка завершена. ===============================================================

Если разорвать впн соединение то весь интернет пропадет, так как в таблице маршрутизации не будет шлюза по умолчанию, которым является шлюз выдаваемвый впн сервером после соединения. Если у Вас не получается настроить маршрутизацию для специального использования VPN соединения, Вы можете сообщить нам о Ваших трудностях прямо здесь, оставив комментарий, или послав личное сообщение пользователю Administrator .

Когда мы подключаемся к некой сети по VPN и при этом
нам выдается IP из отдельного пула, который в целевую сеть не входит, то мы
должны вручную прописать маршрут до нужной нам сети. Что-то вроде:

route add -p 192.168.2.0 mask 255.255.255.0 172.16.0.1

И так делать необходимо каждый раз при подключении к этому VPN, что хоть и не сложно, но
необходимость каких-то дополнительных телодвижений жутко бесит. А если у нас
нет прав администратора – выполнить эту команду вообще невозможно. Прописать
один раз статический маршрут тоже не выйдет, т.к. при отключении происходит
уничтожение соответствующего интерфейса, и маршрут хоть и почему-то остается в
списке route print,
но при последующем подключении не работает, пока не прописать его заново.

Справедливости ради, выполнить нижеследующую инструкцию без
прав админа тоже не выйдет, но это хотя бы нужно сделать лишь один раз.

Таким образом, мы хотим, чтобы при подключении к VPN нужный
нам маршрут прописывался автоматически. Microsoft не перестает удивлять, и такую
казалось бы очевидную-элементарную функцию в свою винду не удосужилась впилить
даже к версии 20H2.

Исполняется наше желание с помощью виндового же планировщика задач, который будет триггериться на события из журнала – собственно, подключения и отключения нужного нам VPN.

Допустим, что мы подключаемся к VPN-серверу, который находится в сети 192.168.2.0/24, а VPN-клиентам выдает адреса из пула 172.16.0.0/16, сам же имея при этом адрес 172.16.0.1. Таким образом, мы видим шлюз 172.16.0.1, но не знаем, что путь до 192.168.2.0/24 лежит через него.

Нужный нам журнал находится тут:

Просмотр событий – Журналы приложений и служб – Microsoft – Windows – NetworkProfile – Выполняется.

В этот журнал попадают подключения и отключения к различным сетям,
что нам и требуется.

Успешное подключение к VPN посредством стандартного rasdial генерирует событие с кодом 10000:

А отключение генерирует событие с кодом 10001:

Это мы и будем ловить. Далее нужно создать два задания в
планировщике – на подключение и отключение, которые будут отличаться всего в двух
местах.

Создаем задачу:

Создаем действие «Запуск программы» и ставим запуск C:WindowsSystem32ROUTE.EXE с параметрами add -p 192.168.2.0 mask 255.255.255.0 172.16.0.1 – получается та же самая команда на создание маршрута.

Обязательно ставим галку «Выполнить с наивысшими правами»,
т.е. от админа.

Триггером же нужно поставить событие из журнала. Создаем:

Выбираем «При событии», «Настраиваемое», «Создать фильтр событий», далее «XML», галка «Изменить запрос вручную» и копипастим туда следующее:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="Microsoft-Windows-NetworkProfile/Operational">
      *[System[(EventID=10000)]] and *[EventData[(Data[@Name="Name"]="MY-VPN")]]
    </Select>
  </Query>
</QueryList>

Где вместо MY-VPN ставим имя нашего подключения.

В «Условиях» снимаем галки про питание и батарею, а также ставим галку «Запускать только при подключении к следующей сети» и выбираем «Любое подключение». Если выбрать в этом списке что-то другое, то задача выполняться вообще не будет, а при попытке запустить ее вручную выдаст непонятную сраку:

Этот баг
известен микрософту, но делать с ним что-либо они не торопятся, по этой же
причине мы городили вышенаписанный XML, вместо того чтобы сделать простой триггер
по эвенту – в этом случае вытащить имя сети из содержимого эвента нельзя, а из-за
бага выбрать нужную сеть мы тоже не можем.

Задание на создание маршрута готово, теперь создаем задание на его удаление. Оно будет такое же, кроме пары отличий – в параметре команды ROUTE задаем delete 192.168.2.0, а в XML-копипасте ставим EventID=10001.

Теперь
подключаемся к нашему VPN
и делаем route print. Как видим, маршрут появился сам по
себе. Магия!

А теперь
отключаемся и видим, что маршрут пропал.

Спасибо за
внимание.

This entry was posted
on Пятница, 27 ноября, 2020 at 02:04 and is filed under technical.
You can follow any responses to this entry through the RSS 2.0 feed.