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
źródło
Odpowiedzi:
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:
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.
źródło
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.
źródło
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.
źródło
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.
źródło