VPN w ramach sesji pulpitu zdalnego

13

Łą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
vpn remote-desktop Dan
źródło
Podaj więcej informacji na temat konfiguracji. W szczególności, jaka technologia VPN (IPsec, SSL VPN, ...), jaki klient VPN i jaki rodzaj routingu w sieci LAN?
śleske,
Czy masz skonfigurowaną sieć VPN, aby nie kierować całego ruchu przez VPN? jeśli taka jest konfiguracja, to cię odetnie.
Sirex,
Dodałem więcej informacji. Ponadto - próbowałem mieć zaznaczoną i niezaznaczoną opcję „Użyj domyślnej bramy w sieci zdalnej”. Brak szczęścia. Dziękujemy za dotychczasowy wkład.
Dan
Czy cały ruch z innych hostów w sieci 10.1.1.0/24 jest odrzucany przez komputer nr 2, gdy VPN jest aktywny? ICMP (ping) itp.?
Goyuix,
Tak Goyuix - to prawda. Pingi na PC # 2 są skuteczne tylko wtedy, gdy VPN jest nieaktywny.
Dan

Odpowiedzi:

10

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ę.

Siekacz 3
źródło
3
+1. To też będzie moje przypuszczenie. Zastanawiam się, czy coś takiego jak LogMeIn może być łatwiejszym rozwiązaniem niż próba znalezienia obejścia dla uruchomienia sesji RDP.
joeqwerty
Umieść drugą kartę sieciową w polu i poproś klienta VPN, aby pochodził z tej, której przypisano domyślną trasę.
SpacemanSpiff
Być może coś cię tu łączy Tom. Zobacz edycję, o której mowa.
Dan
Jak by to się stało, gdyby ustawienie bramy zdalnej było wyłączone i łączy się przez lokalną trasę (tę samą podsieć)?
Joris
5

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.

Mister IT Guru
źródło
Żeby sprawdzić, czy fizycznie siedzisz na lokalnym komputerze nr 1, prawda?
Mister IT Guru,
Tak to prawda. Próbowałem ustawić opcję „Użyj domyślnej bramy w sieci zdalnej” jako niezaznaczoną. Brak szczęścia.
Dan
Ponadto - jest to inna podsieć,
Dan
1

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).

Marm0t
źródło
Dzięki - nie widzę żadnej opcji „Split Tunneling” na serwerze VPN. Żeby było jasne - używam tylko routera ADSL (Draytek) z wbudowaną funkcjonalnością serwera VPN. Może nie mieć niektórych zaawansowanych opcji ...
Dan
Czy ten router ma uruchomionego demona pptp? Jeśli tak, musisz go wyłączyć. Może to zakłócać pakiety GRE.
Mister IT Guru,
1

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

Hugo Garcia
źródło
Do powyższego pytania dodałem tabele routingu. Dzięki za wkład.
Dan
Czy po połączeniu się z VPN na PC # 2 nadal możesz surfować po sieci? a jeśli możesz, czy możesz sprawdzić, czy wychodzisz z tego samego publicznego adresu IP? whatismyip.net powinien dać ci adres IP, którego używasz, aby wyjść na świat. kolejne pytanie, czy używasz interfejsu dialup systemu Windows do łączenia się z VPN lub innym klientem VPN?
Hugo Garcia,
1

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.

wal
źródło
0

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ć.

Śleske
źródło
1
Klienci VPN robią to, aby zapobiec łączeniu ze sobą dwóch sieci (przy użyciu routingu) i kradzieży wszystkich danych z narażonych systemów (lub nawet po prostu narażeniu się na złośliwe oprogramowanie), taki atak będzie wyglądał na zainicjowany przez system wykonujący połączenie, nie pozostawiając praktycznie żadnych dowodów
Mister IT Guru
0

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.


źródło
0

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?

Goyuix
źródło
Próbowałem z wyłączonymi wszystkimi zaporami i nie mogę ponownie połączyć RDP, gdy VPN jest aktywny.
Dan
0

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.

Joris
źródło
0

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.

tomstephens89
źródło
0

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.

Jeff Haskett
źródło