Неможливо змінити маршрути за допомогою 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 від скидання показників маршруту, і тепер у мене є:

Маршрути з показниками на користь мого адаптера Wi-Fi

Але коли я запускаю 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 застосовувати цю політику? У компанії, ймовірно, існує політика безпеки, яка вимагає, щоб ви не використовували роздільне тунелювання, а обхід цієї політики був би ризиком для безпеки.

— Ryan Ries

Зовсім навпаки. Зараз у мене є доступ до веб-сервісів партнерів цієї компанії, обмежених IP-адресами, оскільки мій веб-трафік виходить через їх IP-адресу в Інтернеті. З їх боку це дуже ледача конфігурація, оскільки в "Я буду тунелювати все через VPN, тому мені ніколи не доведеться додавати іншу IP або підмережу до таблиці маршрутів".

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

— BillThor

Насправді, якби я був у цій мережі, я мав би змогу налаштувати свої маршрути та показники, щоб надати пріоритет бажаному інтернет-з'єднанню (3 г / 4 г, тобто). Я мав би такий варіант, тому що я не зазнав б смішного обмеження клієнта VPN. Теоретичне запобігання розділеному тунелюванню звучить нормально, але це обмежує мене НАШЛИШЕ, ніж якби я фактично був фізично в цій мережі. Ви, хлопці, виправдовуєте реалізацію безпеки, яка шкодить мені, а не допомагає мені знайти вихід, і саме це питання. Як я обійти це?

Також є показники інтерфейсу: ncpa.cpl> Властивості NIC> Властивості вводу стека 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).

[/ rant]

— mbrownnyc
джерело

Коли я намагаюся змінити показник маршруту VPN 0,0.0.0 на більш високе значення, ніж Інтернет-маршрут, клієнт FortiSSL встановлює мій інтернет-маршрут на ще більш високий показник.

— Джуліано

У таблиці "після" було два маршрути шлюзу за замовчуванням. Віртуальна мережа VPN 0.0.0.0 і Wifi-карта 0.0.0.0. Я видалив шлюз VPN за замовчуванням, але залишив картку Wi-Fi, яка повинна зробити так, як було раніше, але все зламало. Або fortissl робить щось на стек, щоб завадити людям робити те, що я намагаюся зробити, або я роблю це неправильно.

— Джуліано

Вони є різними інтерфейсами, тому ви повинні мати можливість коригувати витрати на маршрути окремо. Якщо клієнт спостерігає за таблицею маршрутизації, там вам нічого не допоможе. Клієнт VPN Cisco налаштований з файлом PRF, яким можна керувати в системі. Клієнт Fortigate SSL, ймовірно, той самий, або реєстр, або файл. Я просто не впевнений, де буде місце. Трохи погляньте, і ви можете знайти щось, що дозволяє налаштувати клієнта. Крім того, "підтримка розділеного тунелювання" налаштована "на стороні сервера" / на блоці Fortigate.

— mbrownnyc

Подивіться всередину: HKEY_CURRENT_USER\Software\Fortinet\SslvpnClient. Tunnelмає бути цікавим. Будь ласка, опублікуйте те, що ви знайшли. Або відповідіть і позначте community wikiтак, щоб ви могли допомогти іншим.

— mbrownnyc

Дуже погано. Не впевнений у своїй ситуації, але чи варто подавати запит на роздільне тунелювання? В іншому випадку, схоже, вам доведеться викрасти деякі дзвінки API з чимось на кшталт об'їздів rohitab або MSFT. Це може бути веселий проект на вихідні!

— mbrownnyc