Не удается изменить маршруты с VPN-клиентом

Мое VPN-соединение пропускает весь интернет-трафик через туннель, и это очень медленно. Я хочу иметь возможность туннелировать только определенные IP-адреса и делать это на моей стороне (на стороне клиента).

Я подключаюсь к VPN с клиентом FortiSSL , таблица маршрутов выглядит так до установления соединения:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.101     40
        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.0.0    255.255.255.0         On-link     192.168.0.101    276
    192.168.0.101  255.255.255.255         On-link     192.168.0.101    276
    192.168.0.255  255.255.255.255         On-link     192.168.0.101    276
    192.168.119.0    255.255.255.0         On-link     192.168.119.1    276
    192.168.119.1  255.255.255.255         On-link     192.168.119.1    276
  192.168.119.255  255.255.255.255         On-link     192.168.119.1    276
    192.168.221.0    255.255.255.0         On-link     192.168.221.1    276
    192.168.221.1  255.255.255.255         On-link     192.168.221.1    276
  192.168.221.255  255.255.255.255         On-link     192.168.221.1    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.119.1    276
        224.0.0.0        240.0.0.0         On-link     192.168.221.1    276
        224.0.0.0        240.0.0.0         On-link     192.168.0.101    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.119.1    276
  255.255.255.255  255.255.255.255         On-link     192.168.221.1    276
  255.255.255.255  255.255.255.255         On-link     192.168.0.101    276

После подключения это выглядит так:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.101   4265
          0.0.0.0          0.0.0.0         On-link        172.16.0.1     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
       172.16.0.1  255.255.255.255         On-link        172.16.0.1    276
      192.168.0.0    255.255.255.0         On-link     192.168.0.101   4501
    192.168.0.101  255.255.255.255         On-link     192.168.0.101   4501
    192.168.0.255  255.255.255.255         On-link     192.168.0.101   4501
    192.168.119.0    255.255.255.0         On-link     192.168.119.1   4501
    192.168.119.1  255.255.255.255         On-link     192.168.119.1   4501
  192.168.119.255  255.255.255.255         On-link     192.168.119.1   4501
    192.168.221.0    255.255.255.0         On-link     192.168.221.1   4501
    192.168.221.1  255.255.255.255         On-link     192.168.221.1   4501
  192.168.221.255  255.255.255.255         On-link     192.168.221.1   4501
   200.250.246.74  255.255.255.255      192.168.0.1    192.168.0.101   4245
        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.119.1   4502
        224.0.0.0        240.0.0.0         On-link     192.168.221.1   4502
        224.0.0.0        240.0.0.0         On-link     192.168.0.101   4502
        224.0.0.0        240.0.0.0         On-link        172.16.0.1     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.119.1   4501
  255.255.255.255  255.255.255.255         On-link     192.168.221.1   4501
  255.255.255.255  255.255.255.255         On-link     192.168.0.101   4501
  255.255.255.255  255.255.255.255         On-link        172.16.0.1    276

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

C:\Windows\system32>route change 0.0.0.0 mask 0.0.0.0 192.168.0.1 metric 10 if 13
OK!

Но ничего не изменилось.

Затем я попытался удалить «всеобъемлющий» маршрут VPN, тот, у которого метрика 21 выше:

C:\Windows\system32>route delete 0.0.0.0 mask 0.0.0.0 if 50
OK!

И это сломало все

C:\Windows\system32>ping 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
PING: transmit failed. General failure.

Я также попытался изменить метрику на адаптерах, но клиент FortiSSL переопределяет все настройки при подключении, поэтому это не помогло.

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

Я использую Windows 7 x64, если это поможет.

- ОБНОВЛЕНИЕ (2013-12-24) -

Благодаря совету mbrownnyc я изучил проблему с Rohitab и выяснил, что клиент FortiSSL просматривает таблицу маршрутов с помощью NotifyRouteChangeвызова API Helper API.

Я установил NotifyRouteChangeточку останова перед вызовами и использовал опцию «Пропустить вызов», чтобы успешно запретить FortiSSL сбрасывать метрики маршрута, и теперь у меня есть:

Маршруты с метриками в пользу моего адаптера Wifi

Тем не менее, когда я запускаю tracert, мой маршрут все еще проходит через VPN:

C:\Windows\system32>tracert www.google.com

Tracing route to www.google.com [173.194.118.83]
over a maximum of 30 hops:

  1    45 ms    47 ms    45 ms  Jurema [172.16.0.1]

Есть ли какой-то аспект работы в сети Windows, о котором я не знаю, который может способствовать определенному маршруту, даже если метрики маршрутной печати говорят об обратном?

windows vpn

— Жулиано
источник

Разве для вашего VPN-клиента не имеет смысла применять эту политику? У компании, вероятно, есть политика безопасности, которая требует, чтобы вы не использовали раздельное туннелирование, и обход этой политики был бы угрозой безопасности.

— Райан Райс

Наоборот. Теперь у меня есть доступ к веб-сервисам партнеров этой компании с ограниченным IP-адресом, поскольку мой веб-трафик поступает через их интернет-IP-адреса. Это очень ленивая конфигурация с их стороны, как в «Я буду туннелировать все через VPN, поэтому мне никогда не придется добавлять другой IP или подсеть в таблицу маршрутизации».

@Juliano Смысл избегания разделенного туннелирования состоит в том, чтобы запретить пользователям входить в один туннель и затем иметь доступ к данным в другом туннеле. Я ожидаю, что у вас будет тот же доступ к сети, к которой вы туннелируете, который вы бы имели, если бы были в сети. Однако вы не хотите использовать разделенный туннель для предоставления доступа к миру.

— BillThor

На самом деле, если бы я был в этой сети, я мог бы настроить свои маршруты и метрики, чтобы отдавать приоритет желаемому интернет-соединению (3g / 4g т.е.). У меня был бы такой вариант, потому что я не подвергался бы смехотворно ограничивающему VPN-клиенту. Предотвращение раздельного туннелирования звучит нормально в теории, но это ограничивает меня ПУТЬ больше, чем если бы я был физически в этой сети. Вы, ребята, оправдываете реализацию системы безопасности, которая причиняет мне боль, вместо того, чтобы помогать мне найти выход, и этот вопрос под рукой. Как мне обойти это?

Существуют также метрики интерфейса: ncpa.cpl> свойства сетевой карты> свойства записи стека IP v4> вкладка «Общие» / «Дополнительно»> «Автоматическая метрика». Посмотри там на обоих интерфейсах. Также смотрите этот пост в блоге о многосетевой Windows .

— mbrownnyc

Обратите внимание, что я не использую обычную сетевую нотацию для адресации здесь (например, CIDR или даже host/maskнотацию, чтобы не перепутать спрашивающего).

Вместо удаления вашего маршрута «шлюз по умолчанию» ( 0.0.0.0 mask 0.0.0.0), чтобы ваш сетевой стек не знал, куда отправлять большинство пакетов, попробуйте поднять метрику VPN-маршрута ниже, чем у вашего маршрута по умолчанию (в данном случае 4265).

После соединения с клиентом Fortigate:

route change 0.0.0.0 mask 0.0.0.0 172.16.0.1 metric 4266 if N

Где N - номер интерфейса для fortisslинтерфейса, возвращенного в начале route print.

Сетевой стек должен относиться к этому правильно:

Маршрут , который «включает в себя адрес назначения» будет обрабатывать пакеты (маршрут сообщает сетевую стек для отправки пакетов , предназначенных для , this IPчтобы this gatewayдля дальнейшей маршрутизации).
Все пакеты с IP-адресом назначения 172.16.*.*будут отправлены в VPN; поскольку сетевой стек Windows знает, что если к интерфейсу подключен адрес, то этот интерфейс используется для доступа к другим IP-адресам в этом диапазоне адресов. Я могу получить более подробные сведения о диапазоне, если вы разместите «Маска подсети» для 172.16.0.1.

Вы должны определить IP-адреса ресурсов, к которым вам нужен доступ через VPN. Вы можете сделать это легко с помощью nslookup [hostname of resource]подключения без настройки маршрутов.

[Напыщенный]

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

Доступ VPN-клиентов к ресурсам должен быть изолирован и строго ограничен, как если бы к ним обращались через Интернет (потому что активы, где вы не устанавливаете полный контроль, представляют более высокий риск, чем активы, где вы можете утверждать некоторые из них).
Они должны интегрировать механизм контроля доступа к сети для клиентов VPN. Это может позволить им применять некоторые политики на клиентских компьютерах (например, «устарели ли антивирусные определения?» И т. Д. И т. Д.).
Подумайте об использовании жесткого решения, такого как виртуальный рабочий стол Fortigate SSL VPN (которое довольно легко настроить и бесплатно [мне кажется] с лицензией SSL VPN).

[/ Напыщенная]

— mbrownnyc
источник

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

— Джулиано

В таблице «после» было два маршрута по умолчанию для шлюза. VPN 4.0.0.0 и Wi-Fi 0.0.0.0. Я удалил шлюз VPN по умолчанию, но оставил шлюз Wi-Fi, который должен сделать его таким, каким он был раньше, но он сломал все. Либо fortissl что-то делает со стеком, чтобы люди не делали то, что я пытаюсь сделать, либо я делаю это неправильно.

— Джулиано

Это разные интерфейсы, поэтому вы должны иметь возможность настраивать стоимость маршрутов отдельно. Если клиент следит за таблицей маршрутизации, вам ничто не поможет. Клиент Cisco VPN настроен с файлом PRF, которым можно управлять в системе. Клиент Fortigate SSL, вероятно, одинаковый, либо реестр, либо файл. Я просто не уверен, где будет настройка. Поэкспериментируйте немного, и вы можете найти что-то, что позволит вам настроить клиент. Кроме того, «поддержка раздельного туннелирования» настраивается «на стороне сервера» / на устройстве Fortigate.

— mbrownnyc

Посмотрите внутрь: HKEY_CURRENT_USER\Software\Fortinet\SslvpnClient. Tunnelдолжно быть интересно. Пожалуйста, отправьте обратно, что вы найдете. Или ответьте и отметьте как community wikiтак, чтобы вы могли помочь другим.

— mbrownnyc

Очень плохо. Не уверен в вашей ситуации, но стоит ли подавать запрос на разделенное туннелирование? В противном случае, похоже, вам придется перехватывать некоторые вызовы API с помощью чего-то вроде обходных путей rohitab или MSFT. Это может быть веселый проект выходного дня!

— mbrownnyc