VPN w ramach sesji pulpitu zdalnego

Łączę się z serwerem w mojej sieci lokalnej za pośrednictwem pulpitu zdalnego. Następnie muszę nawiązać połączenie VPN z Internetem w ramach sesji pulpitu zdalnego. Jednak to natychmiast rozłącza moją sesję pulpitu zdalnego.

Co się tutaj dzieje i czy mogę to naprawić?

Informacje dodatkowe:

Komputer lokalny nr 1:

• Inicjuje sesję RDP do nr 2
• System Windows 7
• 10.1.1.140/24

Komputer lokalny nr 2:

• Windows Vista
• 10.1.1.132/24
• Inicjuje połączenie VPN z publicznym adresem IP
• VPN to PPTP
• Ustaw automatyczne uzyskiwanie adresu IP i DNS
• Opcja „Użyj domyślnej bramy w sieci zdalnej” nie jest zaznaczona
• Wybrano „Enable LMHosts”
• Wybrano opcję „Włącz Netbios” przez TCP / IP
• Ma możliwość bycia multi-homed (tj. Ma 2 nici)

Publiczny router ADSL:

• Serwer VPN
• odbiera połączenie z nr 2 za pośrednictwem zewnętrznego adresu IP
• Sieć wewnętrzna to 192.168.0.0/24

Mogę nawiązać połączenie VPN z mojego komputera bez problemów (bez udziału RDP).

Tom zasugerował użycie podwójnych kart sieciowych w komentarzu poniżej. Mam podwójne karty sieciowe w pudełku (nr 2 powyżej), ale nie jestem pewien, jak je poprawnie skonfigurować, ani jak przypisać VPN do korzystania z jednej nad drugą.

Próbowałem ustawić dodatkową kartę sieciową w tej samej sieci prywatnej (10.1.1.200/24), uruchamiając VPN, a następnie próbując połączyć RDP z jedną z kart sieciowych, 10.1.1.132 lub 10.1.1.200, ale nie miałem szczęścia. Czy jest jakiś sposób, aby powiedzieć VPN, aby korzystała z jednej karty sieciowej nad drugą?

Zgodnie z życzeniem - oto moje tabele routingu z komputera nr 2:

Przed połączeniem 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
===========================================================================

i po podłączeniu 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
===========================================================================

Próbowałem nawet podłączyć drugi interfejs (10.1.1.232) i grać z domyślnymi trasami:

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

Dzieje się tak, że skutecznie odcinasz trasę IP od serwera do siebie - stąd utrata sesji RDP. Możesz to naprawić, konfigurując VPN w taki sposób, aby był połączony z drugim interfejsem (fizycznym lub wirtualnym), aby zarówno VPN, jak i łącze RDP mogły współistnieć. To, jak to zrobisz, zależy w ogromnym stopniu od bardzo szczegółowych konfiguracji, których obecnie nie znamy, więc jeśli potrzebujesz pomocy, musisz wrócić do nas z DUŻĄ ilością dodatkowych informacji, na tyle, na ile możesz. Proszę.

Może to być zwyczajowa praktyka - domyślnie w oknie systemu Windows (to mogło się zmienić) cały ruch jest wymuszany w tunelu VPN, więc tak, twój RDP spadnie.

Sugeruję, aby przejść do zaawansowanych ustawień VPN na serwerze i upewnić się, że nie wysyła on całego ruchu przez VPN.

Sprawdź także, czy sieć docelowa nie używa takich samych ustawień podsieci jak ty, w przeciwnym razie ponownie wystąpią opisane objawy.

Miałem identyczny problem. Sprawdź, czy dostawca VPN może dodać Cię do grupy, która ma zestaw zasad dla „tunelowania dzielonego” - odbywa się to po stronie hosta VPN, a jeśli serwer nie ma włączonej tej opcji, nie będziesz mógł robić tego, co Ty. próbują.

Widząc, że twój VPN ma adres 192. * po podłączeniu zniszczy interfejs, z którym się łączysz (w ten sposób odcinając cię).

Jeśli tunelowanie podzielone nie jest włączone na serwerze VPN (skontaktuj się z administratorem serwera VPN w tej sprawie!), Nie będziesz mógł się połączyć.

To wszystko zakłada, że ​​poprawnie ustawiasz lokalne połączenia VPN (tak to wygląda).

Miałem już ten problem, a rozwiązaniem jest „dzielone tunelowanie”, co oznacza, że ​​wysyłają ruch internetowy do domyślnej bramy i ruch do sieci VPN za pomocą tunelu.

To, co musisz zrobić, to ustawić statyczną trasę do komputera w komputerze nr 2. I ustawienie priorytetu dla tej trasy na 0

Tak więc wynikiem końcowym będzie domyślna trasa 0.0.0.0/0 do adresu IP bramy VPN i statyczna trasa do komputera przy użyciu domyślnej bramy.

W systemie Windows możesz zrobić coś takiego:

 route add 10.1.1.140 netmask 255.255.255.255 <defaultGW> -P

gdzie defaultGW to adres IP routera.

Zapewni to, że ruch do 10.1.1.140 nie będzie kierowany do tunelu.

jeśli masz fizyczny dostęp do komputera # 2, połącz się z VPN i daj nam znać tabelę routingu urządzenia:

route print

jeden przed połączeniem z VPN i jeden po.

Dzięki tym informacjom możemy pomóc w skonfigurowaniu „podzielonego tunelu”

Mam nadzieję na pomoc

Odkryłem, że użycie adresu IPv6 do połączenia nie powoduje przerwania sesji RDP przez VPN.

W mojej konfiguracji mam gościa i hosta wirtualnego systemu Windows, a moja sieć VPN na gościu wymusza CAŁY ruch przez VPN (jest to skonfigurowany serwer, nie mogę tego zmienić)

Jeśli połączę się z mojego hosta do gościa za pomocą adresu IPv4 (np. 192.168.1.x), to natychmiast po zainicjowaniu połączenia VPN na gościu sesja RDP zostanie przerwana. Jeśli jednak połączę protokół RDP za pomocą nazwy hosta gościa (która jest tłumaczona na adres IPv6), połączenie VPN nie przerywa sesji RDP.

Trudno powiedzieć bez dodatkowych informacji, ale wielu klientów VPN ma nieprzyjemny zwyczaj (logicznie) odłączania komputera hosta od sieci LAN podczas konfigurowania połączenia VPN. Tzn. Możesz być podłączony do sieci LAN lub VPN, ale nie do obu.

Jeśli twój klient VPN to zrobi, oczywiście sesja RDP zostanie zabita jako efekt uboczny odcięcia cię od sieci LAN.

Nie jestem pewien, dlaczego robią to klienci VPN, czy jest to celowy środek (bezpieczeństwo?) Czy tylko efekt uboczny rekonfiguracji sieci, ale często się z tym spotkałem.

Sprawdź szczegóły w instrukcji i jak to naprawić.

Zwykle używałem „zagnieżdżonych” sesji RDP przez VPN bez specjalnego problemu (poza niewielkim spowolnieniem) Podstawowym schematem był Klient-> VPN-> Pierwszy serwer RDP-> Internet-> Drugi serwer RDP. Myślę, że jedynym problemem, jaki możesz mieć, jest to, że Pierwszy serwer może mieć zaporę ogniową, która blokuje połączenie wychodzące protokołu RDP. Korzystając z VPN można „dostać się” do sieci serwerów, ale nie jest to gwarancją, że ten sam serwer lub inne urządzenia LAN mogą ustanowić sesję RDP z zewnętrznym serwerem LAN. Jeśli drugi serwer znajduje się w sieci LAN pierwszego, sprawdź, czy można do niego dotrzeć za pomocą sesji RDP (np. Może mieć lokalną zaporę blokującą port RDP), a system Windows pozwala na jego użycie. Natychmiastowe odcięcie drugiej sesji RDP oznacza, że ​​występuje „problem” sieci (zapory ogniowe, auth i tak dalej) na trasie do drugiego serwera, dlatego wymagana jest dokładna kontrola połączeń wychodzących z pierwszego serwera. Według mnie rozwiązanie jest prostsze niż myślisz, jeśli pierwszy serwer ma tylko jedną kartę sieciową. Przez długi czas działałem z zagnieżdżonymi sesjami rdp z serwerami montującymi Windows 2000, Windows 2003 i 2008, używając serwera VPN na serwerze Windows 2003, a następnie zagnieżdżając sesje RDP dla pozostałych dwóch, czasem razem, od pierwszego. Sprawdź więc warunki sieciowe pierwszego serwera. Windows 2003 i 2008 używają serwera VPN na serwerze Windows 2003, a następnie zagnieżdżają sesje RDP dla pozostałych dwóch, czasem razem, od pierwszego. Sprawdź więc warunki sieciowe pierwszego serwera. Windows 2003 i 2008 używają serwera VPN na serwerze Windows 2003, a następnie zagnieżdżają sesje RDP dla pozostałych dwóch, czasem razem, od pierwszego. Sprawdź więc warunki sieciowe pierwszego serwera.

Wspomniałeś, że „Użyj domyślnej bramy” nie jest zaznaczone - co jeśli jest to dopuszczalne (nie wymaga routingu poza podsiecią 192.168.0.0/24) powinno rozwiązać Twój problem.

Co pozostaje z dźwiękami, jak potencjalna zapora sieciowa, która przeszkadza? Czy możesz całkowicie wyłączyć Zaporę systemu Windows (lub inny produkt, którego używasz) i sprawdzić, czy objaw nadal występuje?

Czy jesteś w stanie ponownie połączyć przerwaną sesję po ustanowieniu łącza VPN i pozostaje on aktywny?

Edycja : Brakowało mi odpowiedzi Sleskesa wyjaśniającej to samo.

Być może jakiś zainstalowany produkt zabezpieczający (zapora ogniowa, „bezpieczeństwo internetowe”, antywirus, ...) wykrywa połączenie PPTP i ma tę samą funkcjonalność?

Pamiętaj, że niektóre z tych produktów mają opcje głęboko zakopane w graficznym interfejsie użytkownika za niepozornymi polami wyboru.

Jest prawdopodobne, że klient VPN jest skonfigurowany do kierowania CAŁEGO ruchu w dół tunelu, a nie tylko ruchu do sieci, do których kieruje VPN. Spowoduje to porzucenie obecnie otwartych połączeń i zmianę zachowania routingu na serwerze, dlatego połączenie zostało zerwane.

Nie rozwiązuje to konkretnego wspomnianego problemu, ale tego właśnie użyłem, aby rozwiązać ten sam typ problemu, wspierając różnych klientów korzystających z różnych klientów VPN, którzy nie są wszyscy zgodni, a niektórzy z nich tworzą zamknięte połączenie VPN z tunelem. Mam serwer vmware, który hostuje kilka maszyn wirtualnych i używam klienta vSphere do łączenia się z sesją Windows i mogę otworzyć zamknięte połączenie VPN z tunelem i nie stracić dostępu do sesji Windows.