Windows VPN zawsze rozłącza się po <3 minutach, tylko z mojej sieci

11

Po pierwsze, ten problem istnieje od prawie dwóch lat. Aż do momentu pojawienia się błędu serwera, zrezygnowałem z jego rozwiązania - ale teraz nadzieja się odradza!

Skonfigurowałem serwer Windows 2003 jako kontroler domeny i serwer VPN w zdalnym biurze. Jestem w stanie połączyć się z siecią VPN i pracować bez problemu z każdym klientem systemu Windows, w tym XP, Vista i Windows 7, bez problemu, z co najmniej pięciu różnych sieci (korporacyjnych i domowych, domenowych i nie.) Działa dobrze od wszystkich.

Jednak kiedy tylko połączyć się z klientami na mojej domowej sieci, połączenia spadnie (dyskretnie) po upływie 3 minut lub mniej. Po chwili w końcu powie mi, że połączenie zostało zerwane i spróbuję ponownie wybrać numer / połączyć się ponownie (jeśli tak skonfigurowałem klienta). Jeśli ponownie się połączę, połączenie zostanie ponownie ustanowione i będzie działać poprawnie, ale znowu po cichu spadnie, tym razem po pozornie krótszym okresie.

To nie są sporadyczne spadki. Dzieje się to za każdym razem, dokładnie w ten sam sposób. Jedyną zmienną jest czas trwania połączenia.

Nie ma znaczenia, jaki rodzaj ruchu wysyłam. Mogę siedzieć bezczynnie, wysyłać ciągłe pingi, RDP, przesyłać pliki, wszystko to jednocześnie - to nie ma znaczenia. Wynik jest zawsze taki sam. Połączony przez kilka minut, a potem cicha śmierć.

Ponieważ wątpię, by ktokolwiek doświadczył dokładnie tej sytuacji, jakie kroki mogę podjąć, aby rozwiązać problem z moją ulatniającą się siecią VPN?

Dodatkowe tło

W ciągu tych dwóch lat zmieniłem dostawców usług internetowych (na obu końcach), dodałem nowy kontroler domeny (moja sieć) i zmieniłem routery (obie sieci). Nic z tego nie miało wpływu.

Problem można odtworzyć na wielu komputerach z różnymi systemami operacyjnymi, ale tylko z mojej sieci.

Sprawdziłem, czy zachowanie jest niezależne od klienta, testując na urządzeniu innym niż Windows. Skonfigurowałem VPN na moim iPhonie i połączyłem się przez Wi-Fi przez moją sieć. Korzystając z aplikacji o nazwie Scany, pingowałem serwer w sposób ciągły, dopóki połączenie nie zostało zerwane po około 2 minutach - to samo zachowanie, które widziałem na klientach Windows. Następnie wyłączyłem Wi-Fi i VPN przez AT i Ts 3G i ciągle pingowałem bez żadnych utraconych żądań przez 11 minut. Ten test odpowiednio odizolował problem w mojej sieci.

Jedynym spójnym komponentem w ciągu dwóch lat jest mój kontroler domeny, który obsługuje WINS, a także działa jako serwer VPN dla połączeń przychodzących. Ale ruch wychodzący nie powinien przekierowywać przez mój DC, idzie prosto do zapory / routera, który jest podłączony bezpośrednio do mojego modemu kablowego.

Więcej notatek

Zgłoszono prośbę o sprawdzenie, czy moje trasy nie są funky po ustanowieniu połączenia VPN. Spojrzałem i nie widzę nic oczywiście złego, ale moje doświadczenie z konfiguracją trasy jest dość ograniczone, więc publikuję dane.

Klasa C mojej sieci LAN to 192.168.1.255, klasa C zdalnej sieci LAN to 192.168.10.255. Zamaskowałem również publiczny adres IP serwera VPN (74.93.XXX.XXX).

>route print (VPN Disconnected)
===========================================================================
Interface List
 17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
 11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.24     10
        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.1.0    255.255.255.0         On-link      192.168.1.24    266
     192.168.1.24  255.255.255.255         On-link      192.168.1.24    266
    192.168.1.255  255.255.255.255         On-link      192.168.1.24    266
        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      192.168.1.24    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      192.168.1.24    266
===========================================================================
Persistent Routes:
  None


>route print (VPN Connected)
===========================================================================
Interface List
 25...........................VPN Test
 17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
 11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.24     10
    74.93.XXX.XXX  255.255.255.255      192.168.1.1     192.168.1.24     11
        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.1.0    255.255.255.0         On-link      192.168.1.24    266
     192.168.1.24  255.255.255.255         On-link      192.168.1.24    266
    192.168.1.255  255.255.255.255         On-link      192.168.1.24    266
     192.168.10.0    255.255.255.0   192.168.10.134   192.168.10.134     11
   192.168.10.134  255.255.255.255         On-link    192.168.10.134    266
        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      192.168.1.24    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      192.168.1.24    266
  255.255.255.255  255.255.255.255         On-link    192.168.10.134    266
===========================================================================
Persistent Routes:
  None
windows-server-2003  vpn 
— konopie
źródło
Skoro już próbowałeś rozwiązać ten problem, czy możesz dać nam znać, co już próbowałeś, abyśmy nie przerabiali rzeczy, które do tej pory nie działały?
— Zypher
Większość tego, co „próbowałem”, polegało na przeszukiwaniu sieci w poszukiwaniu powiązanych problemów, które ostatecznie okazały się bardzo niewielkie. Jednym z problemów, który może, ale nie musi być istotny, jest to, że na serwerze VPN występują pewne problemy z konfiguracją. np. Aby komunikować się z nim po podłączeniu VPN, muszę użyć jego adresu IP, a nie jego nazwy (zazwyczaj edytuję plik hosts na każdym łączącym się kliencie). Zawsze też wyłączam „Użyj domyślnej bramy” podczas łączenia się z VPN, ponieważ jego routing RAS jest źle skonfigurowany. Problemy te nie spowodowały jednak problemów podczas łączenia z innej sieci.
— konopie

Odpowiedzi:

8

Ogromne podziękowania dla @Warner i @William za ich sugestie. Ostatecznie to odpowiedź Williama doprowadziła mnie do ostatecznego rozwiązania. Dla każdego, kto szuka, oto oferta.

Po mnóstwie bałaganu, próbując wyizolować problem, w końcu zrobiłem, jak zasugerował William, i wyciągnąłem dzienniki zapory. Nie oczekując niczego interesującego, byłem zaskoczony, gdy zobaczyłem ten wiersz:

PPTP ALG odrzucił pakiet od xxxx do xxxx: 1723

Wiedząc, że PPTP jest skonfigurowane w tej sieci VPN, szukałem błędu. Okazuje się, że inni też to widzieli . W szczególności ludzie z moim dokładnym routerem , D-Link DIR-655.

Okazuje się, że rozwiązanie jest proste.

W interfejsie administracyjnym routera otwórz kartę Zaawansowane i kliknij Ustawienia zapory w menu po lewej stronie. W sekcji „KONFIGURACJA POZIOMU ​​APLIKACJI (ALG)” usuń zaznaczenie pola PPTP (opcjonalnie również zaznacz IPsec, jeśli sieć VPN używa tego protokołu). Kliknij „Zapisz ustawienia” i powiedz routerowi, aby zrestartował komputer. Voila!

Niestety wyłączenie tych opcji ALG oznacza, że ​​niektóre zaawansowane funkcje routingu nie będą działać. Na przykład, obsługa PPTP ma na celu umożliwienie wielu klientom NAT do tunelowania do tego samego serwera VPN jednocześnie. To prawdopodobnie nie zadziała, jeśli pole zostanie wyczyszczone. Jeśli jednak, podobnie jak ja, twoja sieć VPN w ogóle nie działa, gdy pole jest zaznaczone, prawdopodobnie nie masz nic przeciwko.

Nadal nie jestem pewien, dlaczego pamiętam ten problem z zupełnie innym routerem, ale cieszę się, że mimo to działa.

— konopie
źródło
Miałem podobny problem i co wiesz ... ten sam router D-Link. Twoje rozwiązanie zadziałało. Dzięki! Co ciekawe, nigdy nie miałem problemu z siecią VPN, dopóki nie włączyłem urządzenia Vonage VDV21-VD między modemem kablowym a routerem D-Link.
— staticman
Jakie dzienniki zapory wyświetlają ten komunikat? Zakładam, że nie zapora ogniowa loguje się do klienta VPN lub serwera VPN.
— Ian Boyd
@Ian: Nie, firewall to sam DIR-655. Tam właśnie znajdują się dzienniki (widoczne przez interfejs sieciowy).
— konopie
1
To również rozwiązało problem. Tylko jedna głowa: podczas dodawania przekierowania portów wymaganego przez VPN.
— czerwony
2

Domyślamy się, że istnieje element ruchu VPN, który jest wymagany, ale jest blokowany (np. Na zaporze ogniowej) lub zgubiony, co powoduje rezygnację. Sprawdź dzienniki zapory, jeśli masz je pod kątem upuszczonych pakietów. Sprawdź dokładnie zasady, aby upewnić się, że wszystkie niezbędne porty i protokoły są włączone. Możesz także zrobić ciągłe monitorowanie trasy po swojej stronie, aby sprawdzić, czy ruch jest źle kierowany po pojawieniu się tunelu VPN. Polecenie „wydruk trasy” wyświetla te informacje w systemie Windows.

— William
źródło
To świetne sugestie, Williamie. Dzięki. Wrócę z moimi wynikami.
— konopie
Moje trasy opublikowałem jako zmiany w pytaniu.
— konopie
Ta odpowiedź doprowadziła mnie do ostatecznej rezolucji, którą udokumentowałem osobno. Dziękuję za pomoc!
— konopie
1

Miałem tę samą wadę w przypadku openwrt i luci, chciałbym połączyć się za pośrednictwem VPN z moim serwerem openvpn na moim routerze. Połączenie zostanie ustanowione, a następnie będzie ponownie uruchamiał mój modem 3g i tracił połączenie, odpowiedź była w, zapora ogniowa (dziękuję za wskazanie kierunku) i edycja połączenia: 1194. Tutaj masz wybór, skąd pochodziło połączenie VPN i domyślnie było to urządzenie, dwie pozostałe opcje to LAN i WAN, więc w mojej sytuacji było WAN, szybka zmiana i restart i działa świetnie.

— Szczęśliwy człowiek
źródło
0

Podstawowe rozwiązywanie problemów. Wyeliminuj sprzęt. Połączenie internetowe bezpośrednio do komputera. Jeśli odtwarzalne, inny komputer. Wymień modem, wypróbuj różnych dostawców usług internetowych (modem komórkowy). Idź dalej wzdłuż linii, aż będziesz odizolowany, a następnie rozwiąż problemy ze sprzętem, do którego jest on izolowany.

— Warner
źródło
Dziękuję za sugestie. Wzdłuż tych linii mogę dodać: W ciągu tych dwóch lat zmieniłem dostawców usług internetowych (na obu końcach), dodałem nowy kontroler domeny (moja sieć) i zmieniłem routery (obie sieci). Nic z tego nie miało wpływu. Podłączenie serwera VPN bezpośrednio do Internetu nie nastąpi, nawet przez kilka minut, więc to koniec. Problem można odtworzyć na wielu komputerach z różnymi systemami operacyjnymi, ale tylko z mojej sieci. To dało mi jednak pomysł wypróbowania go z klienta innego niż Windows, który spróbuję teraz.
— konopie
Twoja sieć robocza jest już poza zasięgiem, jak sam powiedziałeś, jest odizolowana od sieci. Wygląda na to, że to połączenie lub urządzenie sieciowe. Połącz swoje połączenie domowe bezpośrednio ze znanym działającym komputerem z siecią VPN.
— Warner
Skonfigurowałem VPN na moim iPhonie i łączyłem się przez Wi-Fi przez moją sieć. Korzystając z aplikacji o nazwie Scany, pingowałem serwer w sposób ciągły, aż połączenie zostało przerwane po około 2 minutach - to samo zachowanie, które widziałem na klientach Windows. Następnie wyłączyłem Wi-Fi i VPN przez AT i Ts 3G i nieprzerwanie pingowałem bez żadnych zgubionych żądań przez 7 minut (i wciąż liczę). Ten test odpowiednio izoluje problem w mojej sieci. Jednak już to zrobiłem - więc oferuje niewiele nowych informacji, z wyjątkiem tego, że zachowanie jest agnostyczne dla klienta.
— konopie
Do Twojej wiadomości - ten ping trwał przez 11 minut bez problemu, zanim się nudziłem i zabiłem go.
— konopie
1
Zamknij DC. Czy problem nadal występuje? Podłącz stację roboczą bezpośrednio do Internetu. Czy to trwa? Jaki sprzęt został wyeliminowany poprzez bezpośrednie połączenie z Internetem?
— Warner
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.