VPN в межах сеансу віддаленого робочого столу

Я підключаюся до сервера в моїй локальній мережі через віддалений робочий стіл. Тоді мені потрібно встановити VPN-з'єднання з Інтернетом із сеансу віддаленого робочого столу. Однак це негайно відключає сеанс мого віддаленого робочого столу.

Що тут відбувається і чи є спосіб я це виправити?

Додаткова інформація:

Місцевий комп'ютер №1:

• Ініціює сесію RDP до №2
• Windows 7
• 1.10.140/24

Місцевий комп'ютер №2:

• Windows Vista
• 1.10.132/24
• Ініціює підключення VPN до публічного IP
• VPN - це PPTP
• Встановіть автоматичне отримання IP та DNS
• "Використовувати шлюз за замовчуванням у віддаленій мережі" не вибрано
• Вибрано "Увімкнути LMHosts"
• Вибрано "Увімкнути Netbios" через TCP / IP
• Має можливість бути багатодомним (тобто має 2 нік)

Загальнодоступний маршрутизатор ADSL:

• VPN-сервер
• отримує з'єднання від №2 через зовнішній IP
• Внутрішня мережа - 192.168.0.0/24

Я можу встановити VPN-з'єднання зі свого ПК без проблем (RDP не задіяний).

Том запропонував використовувати подвійні NIC в коментарі нижче. У мене є подвійні NIC у вікні (№2 вище), але я не впевнений, як їх правильно налаштувати або як призначити VPN для використання один за іншим.

Я спробував встановити додатковий NIC в тій же приватній мережі (10.1.1.200/24), запустивши VPN, а потім спробував RDP до будь-якого з NIC, 10.1.1.132 або 10.1.1.200, але не пощастило. Чи я можу сказати VPN використовувати один NIC над іншим?

За запитом - ось мої таблиці маршрутизації з ПК №2:

Перед підключенням VPN:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.1.1.254       10.1.1.132     20
         10.1.1.0    255.255.255.0         On-link        10.1.1.132    276
       10.1.1.132  255.255.255.255         On-link        10.1.1.132    276
       10.1.1.255  255.255.255.255         On-link        10.1.1.132    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
      169.254.0.0      255.255.0.0         On-link        10.1.1.132    296
  169.254.255.255  255.255.255.255         On-link        10.1.1.132    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.1.1.132    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.1.1.132    276
===========================================================================

і після підключення VPN:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.1.1.254       10.1.1.132     20
         10.1.1.0    255.255.255.0         On-link        10.1.1.132    276
       10.1.1.132  255.255.255.255         On-link        10.1.1.132    276
       10.1.1.255  255.255.255.255         On-link        10.1.1.132    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
      169.254.0.0      255.255.0.0         On-link        10.1.1.132    296
  169.254.255.255  255.255.255.255         On-link        10.1.1.132    276
      192.168.0.0    255.255.255.0    192.168.0.254    192.168.0.234    267
    192.168.0.234  255.255.255.255         On-link     192.168.0.234    522
    remote-vpn-ip  255.255.255.255       10.1.1.254       10.1.1.132     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        10.1.1.132    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.1.1.132    276
  255.255.255.255  255.255.255.255         On-link     192.168.0.234    522
===========================================================================

Я навіть спробував підключити другий інтерфейс (10.1.1.232) та грати з типовими маршрутами:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.1.1.254       10.1.1.132     21
         10.1.1.0    255.255.255.0       10.1.1.254       10.1.1.232     11
       10.1.1.132  255.255.255.255         On-link        10.1.1.132    276
       10.1.1.232  255.255.255.255         On-link        10.1.1.232    266
        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
      169.254.0.0      255.255.0.0         On-link        10.1.1.132    296
  169.254.255.255  255.255.255.255         On-link        10.1.1.132    276
      192.168.0.0    255.255.255.0    192.168.0.254    192.168.0.235    267
    192.168.0.235  255.255.255.255         On-link     192.168.0.235    522
    remote-vpn-ip  255.255.255.255       10.1.1.254       10.1.1.132     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        10.1.1.132    276
        224.0.0.0        240.0.0.0         On-link        10.1.1.232    266
  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.1.1.132    276
  255.255.255.255  255.255.255.255         On-link        10.1.1.232    266
  255.255.255.255  255.255.255.255         On-link     192.168.0.235    522

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

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

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

Також переконайтеся, що цільова мережа не використовує ті самі налаштування підмережі, що і ви, інакше знову відчуєте описані вами симптоми.

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

Бачачи, що ваш vpn має адресу 192. * при підключенні він зруйнує інтерфейс, до якого ви підключаєтесь (тим самим відключивши).

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

Це означає, що ви правильно встановлюєте локальні підключення vpn (це виглядає приблизно так).

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

Що вам потрібно зробити, це налаштувати статичний маршрут до вашої машини в комп’ютері №2. І встановивши пріоритет цього маршруту на 0

Таким чином, кінцевим результатом буде маршрут за замовчуванням 0.0.0.0/0 до IP-адреси шлюзу VPN та статичний маршрут до Вашої машини за допомогою шлюзу за замовчуванням.

У Windows, що ви робите, це щось подібне:

 route add 10.1.1.140 netmask 255.255.255.255 <defaultGW> -P

де defaultGW - ip-адреса вашого маршрутизатора.

Це забезпечить, що рух, що йде до 10.1.1.140, не буде спрямований до тунелю.

якщо у вас є фізичний доступ до комп'ютера №2, підключіться до VPN та повідомте нам таблицю маршрутизації машини:

route print

один перед підключенням до vpn і один після.

Незважаючи на цю інформацію, ми можемо допомогти вам встановити "розділений тунель"

Сподіваюся, що допоможе

Я виявив, що використання IPv6 адреси для підключення не призводить до порушення VPN сеансу RDP.

У моїй установці у мене є гостьовий хост і хост віртуального вікна, і мій VPN на гість примушує ВСІЙ трафік через VPN (це налаштовано сервер, я не можу це змінити)

Якщо я підключуюсь від свого хоста до гостя через адресу ipv4 (наприклад, 192.168.1.x), то, як тільки я ініціюю VPN-з'єднання у гостя, сеанс RDP перерветься. Однак якщо я підключаю RDP через ім'я хоста гостя (який вирішує адресу IPv6), то VPN-з'єднання не розриває сеанс RDP.

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

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

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

Перегляньте посібник, щоб отримати детальну інформацію та як це виправити.

Зазвичай я використовував "вкладені" сеанси RDP через VPN без особливих проблем (крім трохи уповільнення) Основною схемою була клієнтська> VPN-> перший сервер RDP-> Інтернет-> сервер RDP другий. Я думаю, єдина проблема, яка може виникнути у тому, що Перший сервер може мати брандмауер, який блокує вихідний виклик протоколу RDP. За допомогою VPN ви можете «увійти» в серверну мережу, але це не є гарантією того, що той же сервер чи інші локальні машини можуть встановити сесію RDP із зовнішнім сервером локальної мережі. Якщо ваш другий сервер перебуває в локальній мережі першого, переконайтеся, що до нього можна отримати сеанс RDP (наприклад: може мати локальний брандмауер, що блокує RDP-порт) і Windows дозволить використовувати його. Негайне відключення другого сеансу RDP означає, що існує мережа "проблема" (брандмауери, auth і так далі) на маршруті до другого сервера, тому потрібна точна перевірка вихідних дзвінків з першого сервера. На мою думку, рішення простіше, ніж ви думаєте, також якщо перший сервер має лише одну мережеву карту. Протягом тривалого часу я працював з вкладеними сеансами rdp із серверами, що монтували Windows 2000, Windows 2003 та 2008, використовуючи VPN-сервер на сервері Windows 2003, потім вклавши сеанси RDP для двох інших, іноді легших, від першого. Тому, будь ласка, перевірте мережеві умови першого сервера. Windows 2003 та 2008, використовуючи сервер VPN на сервері Windows 2003, потім вклавши сеанси RDP для двох інших, іноді легших, від першого. Тому, будь ласка, перевірте мережеві умови першого сервера. Windows 2003 та 2008, використовуючи сервер VPN на сервері Windows 2003, потім вклавши сеанси RDP для двох інших, іноді легших, від першого. Тому, будь ласка, перевірте мережеві умови першого сервера.

Ви згадали, що "Використовувати шлюз за замовчуванням" не знімається, що, якщо це прийнятно (маршрутизація не потрібна за межами підмережі 192.168.0.0/24), повинна вирішити вашу проблему.

Що вам залишається, як звучить потенційний брандмауер? Чи можете ви повністю відключити Брандмауер Windows (або будь-який продукт, який ви використовуєте) і переконатися, що симптом все ще існує?

Чи можете ви знову підключити відмінений сеанс після того, як VPN-посилання було встановлено та залишається активним?

Редагувати : Я пропустив відповідь Слескеса, пояснивши те саме.

Можливо, якийсь встановлений захисний продукт (брандмауер, "безпека Інтернету", антивірус, ...) виявляє з'єднання PPTP і має такий же функціонал?

Зауважте, що деякі з цих продуктів мають параметри, які заглиблені глибоко в графічний інтерфейс, за відміною прапорців.

Ймовірно, що клієнт VPN налаштований на маршрутизацію ВСІХ трафіку вниз по тунелю, а не лише на трафік до мереж, до яких маршрути VPN. Це скасовує будь-які відкриті в даний час з'єднання і змінює поведінку маршрутизації на сервері, отже, чому ваше з'єднання припинено.

Це не вирішує зазначену конкретну проблему, але це те, що я використовував для вирішення однотипних проблем у підтримці різних клієнтів, використовуючи різні клієнти vpn, які не всі сумісні, а також деякі, які створюють закрите vpn з'єднання з тунелем. У мене є сервер vmware, який розміщує декілька віртуальних машин і використовує клієнт vSphere для підключення до сеансу Windows, і я можу відкрити закрите vpn-з'єднання з тунелем і не втратити доступ до сеансу Windows.