З'єднання VPN змушує DNS використовувати неправильний DNS-сервер

17

У мене в мережі компанії 7 ПК (яка є членом нашої Active Directory). Все працює добре, поки я не відкрию VPN-з'єднання на сайт клієнта.

Коли я підключаюся, я втрачаю доступ до мережі до спільних ресурсів у мережі, включаючи каталоги, такі як "Дані програми", щодо яких ми застосовуємо політику перенаправлення папок. Як ви можете уявити, це робить роботу на ПК дуже складною, оскільки ярлики робочого столу перестають працювати, а програмне забезпечення перестає працювати належним чином через те, що з-під нього витягнуті "Дані програми".

Наша мережа має маршрутизацію (10.58.5.0/24), а інші локальні підмережі існують в межах 10.58.0.0/16. Віддалена мережа працює на 192.168.0.0/24.

Я відстежив проблему, пов’язану з DNS. Як тільки я відкриваю тунель VPN, весь мій трафік DNS переходить через віддалену мережу, що пояснює втрату локальних ресурсів, але моє питання полягає в тому, як я можу змусити локальні запити DNS переходити на наші локальні сервери DNS, а не на наших клієнтів. ?

Вихід, ipconfig /allколи не підключений до VPN, нижче:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

Це вихід тієї самої команди з підключеним тунелем VPN:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

PPP adapter Customer Domain:

   Connection-specific DNS Suffix  . : customerdomain.com
   Description . . . . . . . . . . . : CustomerDomain
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.0.85(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 192.168.0.16
                                       192.168.0.17
   Primary WINS Server . . . . . . . : 192.168.0.17
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

Таблиця маршрутизації

Метричний метричний інтерфейс шлюзового пункту призначення

          0.0.0.0          0.0.0.0        10.58.5.1       10.58.5.89     20
        10.58.5.0    255.255.255.0         On-link        10.58.5.89    276
       10.58.5.89  255.255.255.255         On-link        10.58.5.89    276
      10.58.5.255  255.255.255.255         On-link        10.58.5.89    276
    91.194.153.42  255.255.255.255        10.58.5.1       10.58.5.89     21
        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     192.168.0.95     192.168.0.85     21
     192.168.0.85  255.255.255.255         On-link      192.168.0.85    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        10.58.5.89    276
        224.0.0.0        240.0.0.0         On-link      192.168.0.85    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        10.58.5.89    276
  255.255.255.255  255.255.255.255         On-link      192.168.0.85    276

Порядок прив'язки інтерфейсів такий:

введіть тут опис зображення

Я не налаштував тунель VPN для використання шлюзу за замовчуванням на віддаленому кінці, і мережеві комутації до вузлів в обох мережах добре. (тобто я можу пінг будь-якого вузла нашої мережі або віддаленої мережі).

Я змінив властивості підключення PPTP для використання серверів DNS, 10.58.3.32після чого 192.168.0.16запит все ще переходить на 192.168.0.16.

Редагувати:

Локальні ресурси, які зникають, розміщуються на коренях DFS домену, що може (або не може) бути релевантним.

Далі редагувати:

Це, мабуть, впливає на корені DFS домену. Якщо я посилаюсь на подію через ім'я сервера (тобто \\server\shareзамість \\dfsroot\share), я можу отримати доступ до спільних ресурсів.

Відповідно до мого коментаря проти цієї відповіді , я виявив, що можу додати DNS-ім’я домену до файлу хостів, що зупиняє зникнення моїх (DFS) мережевих дисків, але я все одно хотів би сміливу частину свого запитання (вище ) відповідь, якщо хтось має якісь ідеї.

— Брайан
джерело

Ви ніколи не згадували, який брандмауер ви використовуєте? Це досить важливий фактор ІМО, оскільки я думаю, що саме тут ви потенційно зможете знайти відповідь на це питання.

— Ганні

@hanny брандмауер забезпечується мережевим перекладом адрес на модемах ADSL на обох сайтах. Я, мабуть, можу надати номери моделей, якщо це дійсно потрібно, але вони будуть просто стандартними модемами ADSL NATing. Зважаючи на те, що ми говоримо про AD з інтегрованою DNS, я не вважаю ці пристрої релевантними, оскільки проблеми суто DNS.

— Брайан

Якщо VPN не обробляється брандмауером, але Windows, то це відображає різні параметри, з якими можна працювати, оскільки мій досвід VPN Windows досить обмежений. Наприклад, з розбиттям тунелінгу ASA 5505 - це щось дуже легко усунути неполадки, і це може бути зроблено велику кількість конфігурацій, особливо щодо проблем з DNS та призначення DNS. Тому я попросив, дякую за уточнення.

— Ганні

Не могли б ви додати до публікації route print(з vpn-з'єднання)?

— florianb

З маршрутизацією немає нічого поганого, оскільки він здатний підключити через IP, але не через DNS

— MichelZ

12

Добре, тут знайдено чудовий ресурс: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/

Це не ідеально, але просто може працювати.

Порядок прив'язки зберігається в реєстрі в наступному місці: HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. Список включає всі GUID пристроїв для мережевих адаптерів та активних з'єднань у порядку пріоритетного обов'язкового використання.

Під час роботи з ключем реєстру з'являються такі факти:

Зміна порядку GUID в реєстрі впливає на порядок прив'язки, в тому числі для VPN-з'єднань

Будь-які зміни ключа набирають чинності негайно

Коли VPN-з'єднання завершено, GUID для з'єднання додається у верхній частині порядку зв’язування, якщо він ще не існує

Коли VPN-з'єднання закрите, запис GUID для з'єднання видаляється

Якщо для підключення є кілька записів GUID, при закритті з'єднання видаляється лише одна

Цей механізм створює можливість такого вирішення:

Вивчіть ключ реєстру Bind

Підключіться до свого VPN-з'єднання

Ще раз перевірте клавішу Прив’язати та скопіюйте GUID, який було додано до верхньої частини списку

Вставте запис GUID внизу списку 20 разів

Експортуйте ключ і очистіть експортований файл, щоб він включав лише ключ прив’язки

Результат - ключ, який підтримуватиме бажану поведінку. Щоразу, коли встановлено з'єднання VPN, оскільки GUID присутній, воно не буде додано. Оскільки GUID знаходиться внизу, роздільна здатність DNS буде виконана локально для клієнта. Коли з'єднання відключено, один запис GUID буде видалений. Після 20 підключень VPN експортований файл реєстру можна використовувати для повторного імпорту ключа.

Звичайно, ви можете вставити GUID більше разів, щоб зменшити частоту повторного імпорту ключа.

Також важливо пам’ятати, щоб повторити цю процедуру, якщо є якісь зміни мережевих адаптерів.

— ZnArK
джерело

Гарна знахідка. Це дуже добре працює в поєднанні зі сценарієм запуску комп'ютера, щоб скинути значення ключа реєстру для кожного завантаження, що повинно бути чудовим вирішенням того, що не повинно бути проблемою в першу чергу. Велике дякую. Я дам це для подальшого тестування.

— Брайан

3

Я рекомендую створити заплановане завдання. Контролюйте ідентифікатор події 20226, який відповідає події відключення VPN. Потім вогонь невеликий Powershell скрипт ( powershell -File c:\scripts\fixdnsbind.ps1) , який містить:

$val = Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind;  $val.Bind += "\Device\{D7D0BD5E-B65C-4239-BA4D-D309186E9524}";  Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind -Value $val.Bind

. (не забудьте адаптувати ідентифікатор адаптера). Ви також запускаєте цей сценарій один раз перед тим, як підключитися до VPN.

— Стів Б

4

Мені здається, що тунель VPN якимось чином має перевагу над локальним інтерфейсом, що спрямовує DNS-трафік на сервери DNS VPN (ви можете перевірити запит на цих серверах, щоб перевірити цю поведінку, якщо у вас є доступ до них або хтось може перевірити цю поведінку для ти).

Це я не можу повністю пояснити, оскільки порядок зобов’язання вказує по-іншому. Відповідно до цієї публікації тут (див. Більш високу оцінку відповіді) Windows має інше сприйняття щодо цього, вибираючи канал з більш високим пріоритетом залежно від швидкості з'єднання НЕ в порядку прив’язки адаптера. Тож для тестування спробуйте змінити цю автоматичну поведінку: 1) перейдіть до мережевих підключень і для кожного зробіть 2) властивості IP v4 3) розширені 4) відключення "автоматичної метрики" 5) вручну поставити показник 1 для вашої локальної з'єднання та показник 2 на вашому VPN-з'єднанні (PPP). Таким чином він буде сортувати жорсткий шлях до локальних серверів DNS, як бажано, до віддалених DNS.

Сподіваюся, це допомагає!

— анк
джерело

Цікаво, що, дивлячись на мою таблицю маршрутизації вище, показник в інтерфейсі локальної мережі є найнижчим (20), VPN-з'єднання має показник 21. Сказавши це, ця проблема може бути дещо переривчастою і з таблицею маршрутизації, як показано вище , зараз все працює правильно. Я спробую відтворити проблему і ще раз перевірити таблицю маршрутизації.

— Брайан

Оновлення, щойно відновив тунель, і всі мої з'єднання з накопичувачами відпали, але таблиця маршрутизації не відрізняється вище. тобто показник 20 для локальної мережі, метричний 21 для VPN.

— Брайан

1

@Bryan, ця стаття Microsoft ( support.microsoft.com/kb/299540 ) начебто підтверджує те, що я говорив вище. Було б цікаво подивитися, що станеться, якщо ви пройдете процедуру, про яку я писав вище, коли у вас є час. Інші повідомили про точні переривчасті проблеми, які ви бачите, і вирішили їх за допомогою жорсткого підключення показників ( serverfault.com/questions/70792/… ). На жаль, на даний момент у мене немає подібної установки, щоб зробити деякі тести.

— анк

Велике спасибі за це @ank, я, безумовно, піду пізніше наступного тижня, коли я знову в офісі. Цікава стаття BTW. Спасибі.

— Брайан

1

Це зробило трюк для мене! Метрика в налаштуваннях IPv4 для NIC, схоже, не має нічого спільного з метрикою в таблиці маршрутизації! Зміна порядку GUID в HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkkage \ Bind, про який писав ZnArK, нічого не змінила стосовно того, для чого використовується NIC / DNS. Це перевірено на Windows 10

— MrCalvin

4

Як зазначалося, це питання розбиття тунелів.

Три виправлення, рекомендуємо №2, оскільки це легко і буде мати хороші показники, якщо використовувати хороший ящик з VMware Workstation 8

1 - Увімкнути розділене тунелювання - небезпечно і може зажадати роботи на стороні клієнта. Це, мабуть, не відбудеться, гестапо з безпеки ІТ буде закривати вас.

2 - Віртуальний підхід до робочого столу - P2V існуючого робочого столу та перетворіть його на VM. Використовуйте VM для VPN для клієнта. Ви зберігаєте робочий стіл і можете переходити на нього та з нього за потреби.

3 - Віртуалізований серверний підхід - P2V існуючого робочого столу та перетворіть його на VM, після чого поставте його на безкоштовну версію ESXi. Ви зберігаєте робочий стіл і можете переключитися на VM за потреби через консоль. Це може бути повільним ...

— Бреннан
джерело

+1; Мені подобається ідея створення спеціалізованої віртуалізованої системи для виконання завдання, однак я не бачу, що це працює добре в цей час з різних причин. Це, безумовно, буде вдалим рішенням у майбутньому. Спасибі.

— Брайан

3

На жаль, Windows VPN не в змозі зробити "Split-DNS". Однак ви можете видалити сервер DNS із з'єднання VPN після підключення до віддаленого сайту.

Це можна зробити, видавши:

netsh interface ipv4 delete dnsservers name = " ім'я VPN " адреса = всі перевірити = ні

Ви мали це робити кожного разу під час підключення до мережі VPN.

— MichelZ
джерело

FYI ... це не дозволяє використовувати віддалений (VPN) DNS.

— MichelZ

Проблема полягає в тому, що як тільки тунель піднявся, я вже страждаю від проблеми, описаної в моєму запитанні, тому команда буде занадто пізно. Крім того, експериментуючи з цим, команда насправді не має жодних змін ( nslookupвсе ще використовує віддалений DNS-сервер, а ipconfigще перелічує віддалений сервер DNS). Я також відредагував параметри DNS для підключення до тунелю VPN, щоб використовувати власні внутрішні налаштування DNS, але це ігнорується, весь мій трафік DNS все ще спрямований на віддалений сервер DNS.

— Брайан

1

Я спробував це, як у мене була та сама проблема, і вона працювала тут. Ви відрегулювали " ім'я VPN "? Крім того, якщо ви в основному стурбовані цим один сервер , на якому ваші диски підключені до, додайте його в файлі хостів, і ніщо не зможе змінити його

— MichelZ

Дякую, я спробував змінити ім’я (вирізати та вставити з ipconfigвиводу, і коли я помилився, я отримав помилку The filename, directory name, or volume label syntax is incorrect), тому я майже впевнений, що я правильно зрозумів команду. Це може бути щось на віддаленому сервері PPTP, що не дозволяє мені змінювати налаштування DNS. Я буду досліджувати, але мені подобається ідея введення файлів хостів. Я піду на це. Також дивіться мою редакцію питання.

— Брайан

Я просто спробував команду ще раз, і вона видалила DNS-сервер із PPP-з'єднання. Чи можете ви це підтвердити ipconfig /all? Думаю, однак запис про хостів повинен бути для вас найпростішим виправленням.

— MichelZ

2

Ваш тунель VPN знаходиться між клієнтом і клієнтською мережею. Здається, що він не використовує розділене тунелювання, що зупинить вам доступ до ресурсів у вашій власній мережі, поки тунель працює.

Тож вам (або вашому клієнту) потрібно включити розділене тунелювання, або вам потрібно додаткове підключення до мережі та спеціальна таблиця маршрутів для доступу до обох мереж одночасно.

— dunxd
джерело

Для отримання інформації я можу отримати доступ до мережевих ресурсів, поки тунель працює, але здається, що тільки DNS-роздільна здатність зламається. Я не був знайомий з терміном split tunnellingчесно, але, наскільки я можу сказати, це означає лише те, що я не використовую шлюз за замовчуванням на віддаленому сайті, який, не дивлячись на те, що я не вказую, я це вже роблю. Дякую за відповідь, я відредагую своє запитання, щоб це відобразити.

— Брайан

1

У такому випадку це здається, що VPN клієнта не встановлено для розділеного DNS. При розділеному DNS концентратор VPN надає вашому клієнту VPN список серверів DNS (як це відбувається зараз), а також список доменів, які є єдиними доменами, які слід використовувати з цими DNS-серверами; всі інші використовуватимуть DNS вашої системи за замовчуванням.

— Джеймс Снайрінгер

0

Хоча це питання було задано давно, але опублікувати цю відповідь, оскільки це може допомогти іншим. У мене була така ж проблема з VPN, коли коли користувачі підключалися до віддаленого vpn, їх зовнішні dns використовували для зупинки, наприклад. google.comтільки домени компаній, які використовувались для роботи, на яких було зазначено список split-dns.

Проблема полягала в тому, що місцева машина, що використовується, виконує запит на трафік запиту до тунелю vpn, а якщо дозволено в тунелі dns, він відновлюється. Після резервного копіювання він спочатку вибирав ipv6 як роздільну здатність, а потім ніколи не повертався до ipv4.

Тож для перевірки результатів ми спочатку відключили ipv6 на локальній машині, він почав працювати. Щоб назавжди виправити це для всіх користувачів, ми включили client-bypass-protocolкоманду на брандмауері ASA, яка ігнорувала IPv6, якщо його не налаштовано у пулах vpn.

тому, якщо ви не можете керувати брандмауером і знаєте, що розділений тунель і розділений dns вже є, але він не вдається, ви можете спробувати відключити ipv6на локальній машині, і якщо ви можете керувати ним, ви можете включити вищезгадану команду, поки ви не використовуєте ipv6 у віддаленій мережі.

Це мені допомогло, сподіваюся, це допомагає іншим :)

— Рсінгх
джерело

0

Так, я маю досвід!

Встановіть з'єднання VPN з локальним сервером DNS та підключіться до VPN, що використовується nslookup, для запиту доменного імені VPN. Ви повинні отримати відповідь із IP-адресою, яка локальна для локальної мережі VPN. Це означає, що ви використовували сервери VPN DNS для вирішення запиту.

Тепер відкрийте з’єднання з локальною мережею та вручну встановіть DNS в локальний або ISP DNS. а Воля !!! за допомогою клавіші зі стрілкою та повторіть запит nslookup. Ви отримаєте загальнодоступний IP-адресу, що використовував ваш локальний / ISP-сервер DNS для вирішення запиту домену VPN. Бам !!!!

— Грем.Фразер
джерело

0

Я просто видаляю цю опцію з конфігурації VPN клієнта

setenv opt block-out-dns

Це вирішило це питання

— Ісмаїл
джерело

0

У мене була ця проблема кілька років тому, і виправлено, редагуючи файл з'єднання VPN, просто зробіть файл vpn.pbk (ви можете знайти його в google), відкрийте цей файл через текстовий редактор, як блокнот, і змініть значення UseRasCredentials на нуль, і ви вирішите проблему. але єдине питання полягає в тому, що для локальних з’єднань пріоритет DNS стає вищим, ніж DNS VPN, а роздільна здатність імені займає більше часу (якщо VPN використовується для підключення до Інтернету).

— Мохсен Бігделі
джерело

-1

Чому ви вважаєте його DNS?

Якщо ви втратите доступ до своїх мережних спільних ресурсів під час підключення до VPN - це, мабуть, майже напевно, як у вашої машини є проблеми з WINS / NETBIOS.

Визначте сервер WINS і повторіть тест.

— Бен Лессані - Сонассі
джерело

Я точно не знаю, що це причина моїх проблем, але те, що я знаю, це те, що клієнти AD повинні використовувати сервери DNS, які використовуються для розміщення AD, і це не так. Оскільки ця проблема виникає лише тоді, коли я встановлюю VPN-з'єднання, і моя резолюція DNS одночасно стає хитрою, схоже, що DNS є ймовірним кандидатом. Незважаючи на те, я не хочу використовувати віддалений сервер DNS під час підключення до іншої мережі за допомогою VPN.

— Брайан

Ви визначили сервер WINS відповідно до моєї пропозиції? Для Windows не характерно використовувати DNS-сервер у VPN, якщо не визначено використання або "Встановлено віддалений шлюз", який, як ви сказали, відключений. Крім того, ви використовуєте статичний IP в тунелі VPN, то чому взагалі ви встановили записи DNS? Видаліть ці сервери DNS (192.168.0.16-17) або встановіть сервер WINS.

— Бен Лессані - Сонассі

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

— Брайан

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

— Брайан

1

ваше тлумачення цього невірно. IP-адреса призначається сервером PPTP, який фактично не використовує DHCP. Сервер PPTP має пул, з якого він може виділити, але це не DHCP. Я отримую інший IP кожен раз, коли я підключаюся. Крім того, я не поставив галочку для використання віддаленого шлюзу, як ви добре бачите з таблиці маршрутизації.

— Брайан