Як маршрутизувати трафік через активний тунель VPN за доменним іменем?

Я налаштував тунель VPN на свій веб-сервер, орієнтуючи його на FQDN: (наприклад, my.server.com) за допомогою вбудованої функції Windows 7 VPN та вбудованої функції VPN для маршрутизації та віддаленого доступу для Windows 8.

Як я можу забезпечити, щоб весь трафік, орієнтований на FQDN "my.server.com", проходив через тунель VPN? Зокрема, якщо я набрав \\my.server.com\sharedfolderу адресний рядок Провідника або накреслив спільний диск у провіднику на такий шлях, я хочу, щоб трафік проходив через VPN, пов’язаний з my.server.com.

В основному, я хочу, щоб Windows була достатньо розумною для маршрутизації трафіку на "my.server.com" через зашифрований VPN, коли VPN до "my.server.com" підключений, і звичайно маршрутизувати його, коли він не підключений. Це занадто багато запитати?

Мені здається, що після підключення VPN отримує локальну IP-адресу на зразок 192.168.1.101 (яку я призначав статично на сервері на вкладці набору властивості мого облікового запису користувача) і націляючи на цю адресу, спрямовує трафік через VPN. Здається, що трафік, націлений на "my.server.com", ніколи не маршрутизується через VPN і обробляється окремо від IP-адреси VPN, і я повинен використовувати цю IP-адресу VPN для маршрутування речей через VPN. Єдиною перевагою в цьому є брандмауер, який може бути налаштований так, що трафік для спільного використання файлів може походити тільки з цієї IP-адреси.

З цією установкою є дві проблеми:

1. Націлювання на трафік "my.server.com" не здійснюється автоматично через VPN, що є небезпечним та заплутаним, оскільки VPN активний. Це не інтуїтивно зрозуміло.
2. Провідник Windows, як правило, дозволяє вимкнути час з'єднання з диском при використанні локальної адреси підмережі, наприклад, \\192.168.1.101\sharedfolderа Explorer зависає на 30 хвилин, коли я знову намагаюся отримати доступ до накопичувача. Це насправді дратує, і проблема НЕ виникає, коли диск накопичується за допомогою FQDN, як \\my.server.com\sharedfolder... але тоді він не маршрутизується через VPN!

Як я можу вирішити цю проблему?

Оновлення: я також помічаю наступне, коли у мене підключено 2 VPN, один зі статичним IP 192.168.1.101, а другий з 192.168.1.102. Оскільки встановлені обидва VPN, і обидва встановлено, що НЕ використовувати шлюз за замовчуванням у VPN, і обидва VPN, які показують ці дві незалежні IP адреси у статусі їх з'єднання, Провідник плутається, не може підключитися до другого, і тоді, якщо я відкрию нове вікно і спробуйте перейти на 2-ю адресу, схоже, зрівняйте її з першою, а потім з обох адрес (101 і 102) відкрийте одну і ту ж папку на одному сервері через перший VPN. Це не має сенсу.

Я зрозумів це самостійно.

Для маршрутизації на основі FQDN може знадобитися запустити сервер DNS на клієнті, здатний визначати, коли VPN активний за адресою WAN цього FQDN. Коли він виявить активне VPN-з'єднання, він може вирішити FQDN до адреси тунелю VPN, щоб додатки (веб-браузери тощо) отримували адресу тунелю VPN замість адреси WAN сервера. Оскільки це спричинить проблеми для сертифікатів SSL, які показують, які IP-адреси є дійсними, дійсно потрібен мережевий драйвер, відомий VPN, здатний автоматично та прозоро тунелювати дані з програм через тунель VPN. Це можна зробити, але я не знаю, чи існують такі розумні драйвери мережі. Згідно з цією відповіддю на погану відповідь, МОЖЕТЕ МАТЕ РЕЗУЛЬТАТИ на базі FQDN з відповідною конфігурацією, як я підозрював:

Що стосується випуску дублікатів IPv4-адрес сервера, які призначаються різним VPN-серверам у клієнті Windows 7, це, здається, задумано. У Windows Server 2008/2012 Служби маршрутизації та віддаленого доступу (RRAS) сервер використовує маршрутизатор IPv4, який може бути налаштований на використання подібного пула статичних адрес. Цей статичний пул визначатиме IPv4-адресу сервера на клієнті. Тут я встановив, що другий сервер використовуватиме 192.168.2.0/24 як свою підмережу, тож він отримає IP-сервер 192.168.2.1 на клієнті Windows 7.

Моєму обліковому запису користувача на кожному VPN-сервері присвоюється статична IP-адреса на вкладці Dial-In властивості користувачів під управлінням комп’ютера. Це стане IPv4-адресою клієнта в VPN.

Нарешті, щоб переконатися, що трафік спільного використання файлів повинен походити тільки з підмережі VPN сервера, відповідні протоколи / порти в брандмауері можуть обмежувати віддалений IP-адресу для призначеної підмережі:

Тепер на клієнті я можу підключитися до файлових спільних доступів через Інтернет через цю VPN, яка взагалі не вимагає програмного забезпечення сторонніх виробників. Я просто підключаю мережевий диск до VPN-адреси кожного сервера (наприклад, \\192.168.1.1\sharedfolderі \\192.168.2.1\sharedfolder\).

На жаль, ми не можемо використовувати FQDN, наприклад, \\my.server.com\sharedfolder\тому що Windows недостатньо розумний, щоб зрозуміти, що підключення VPN до цієї IP-адреси означає, що весь трафік у всіх портах цієї адреси, за винятком самих зашифрованих пакетів VPN, повинен бути спрямований через IP-VPN. Побічним ефектом від неможливості використання FQDN для шляху обміну файлами є те, що Windows може не підтримувати з'єднання живим і припускає, що він може бути відновлений швидко як локальна адреса, коли насправді він вимкнеться через хвилину а потім знадобиться 30 секунд, щоб відновити з'єднання із загальною папкою. Це можна вирішити, встановивши в реєстрі більший час очікування в режимі очікування. За замовчуванням час очікування для мережевої спільної роботи за замовчуванням становить 600 секунд (10 хвилин). Щоб довше зберегти з’єднання, додайте значення реєстру DWORD під назвою "KeepConn" до ключа реєстру "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ LanmanWorkstation \ Parameters" і надайте йому більш високе значення (за секунди), наприклад 3600, яке б бути годиною. За посиланням:

Збільште значення цього запису, якщо ваша програма закриває та відкриває на сервері файли Універсальної конвенції про іменування (UNC) рідше ніж кожні 10 хвилин. Це зменшує кількість повторних підключень до сервера.

ОНОВЛЕННЯ: Я забув зазначити, що, хоча спільний доступ до файлів через VPN використовує лише вбудовані функції Windows 7 та Windows Server 2012, для Windows Server 2008 є додатковий крок через деяку помилку / функцію, де трафік на порти SMB заблоковано мережевим адаптером за замовчуванням незалежно від брандмауера. Ви повинні встановити адаптер петлі для мікрософт, який буде функціонувати ідентично інтерфейсу за замовчуванням, окрім дозволу трафіку SMB, тож після встановлення він повинен виглядати так. Потім замість підключення до спільної мережі на 192.168.1.1 (VPN-адреса сервера), ви підключаєтесь до 192.168.1.2, що є адресою адаптерів циклу:

Інструкції щодо встановлення адаптера петлі можна знайти тут: http://blogs.msdn.com/b/virtual_pc_guy/archive/2005/10/04/477195.aspx