Konfigurowanie routingu VPN i dostępu zdalnego
Próbuję skonfigurować VPN za pomocą routingu i zdalnego dostępu.
Wypróbowałem dwie konfiguracje, jedną z jedną kartą sieciową, a drugą z dwiema kartami sieciowymi.
Mogę połączyć się przez VPN i uzyskać adres IP z serwera DHCP, ale nie mogę niczego „WIDZIEĆ”. Rozumiem przez to, że klient wydaje się być całkowicie ślepy na sieć biurową, co oznacza:
- Brak pingowania do żadnego serwera biurowego, w tym serwera VPN (zatrzymałem filtrowanie ICMP)
- Brak rozpoznawania nazw DNS (nic dziwnego, jeśli nie mogę połączyć się za pomocą adresu IP. Próbowałem uzyskać dostęp do udziału serwera VPN i hostowanej na nim strony internetowej, na przykład przy użyciu nazwy domeny i adresu IP http://host.com/abc http://host.com/abci http://192.169.254.199/abc http://192.169.254.199/abc )
- Brak dostępu do jakichkolwiek zasobów sieciowych (co również nie jest zaskakujące, biorąc pod uwagę powyższe)
Nie miałem żadnych problemów z połączeniem się z VPN (myślałem, że tak, ale było to związane z routerem testowym, który podałem).
Nie wygląda to na problem z zaporą/routerem, ponieważ skonfigurowałem go tak, aby przepuszczał ruch VPN i przekazywał go do właściwego serwera.
Myślę, że jest to potwierdzone, ponieważ dzienniki zdarzeń serwera VPN pokazują pomyślne sprawdzenia (tj. Zdarzenia logowania).
Pokazuje jednak następujące zdarzenie zaraz po pomyślnym zalogowaniu się (i nie wiem, czy jest to normalne, ale nie spodziewałem się, że tak będzie - klient VPN nie rozłącza się).
An account was logged off.Subject:
Security ID: [DomainName]\[UserName]
Account Name: [UserName]
Account Domain: [DomainName]
Logon ID: 0x[xxxxxx]Logon Type: 3
To zdarzenie jest generowane po zniszczeniu sesji logowania. Można to pozytywnie skorelować ze zdarzeniem logowania przy użyciu wartości identyfikatora logowania. Identyfikatory logowania są unikatowe tylko między ponownymi uruchomieniami na tym samym komputerze.
Nie jestem pewien, czy to się przyda, ale
Wireshark
http://en.wikipedia.org/wiki/Wireshark
pokazuje, że pomyślnie się łączę, a następnie pobieram zaszyfrowane pakiety, co podejrzewałem:
- Istnieje okno dialogowe konfiguracji PPP LCP/CHAP, które jest połączeniem klienta.
- Nie widzę żadnego ICMP z żadnej strony, kiedy pinguję publiczny interfejs VPN (zakładam, że dzieje się tak, ponieważ jest on zamknięty w pakietach GRE).
Jednak interesujące są następujące rzeczy (których nie potrafię wyjaśnić):
- Pingowanie publicznego interfejsu (A) (serwer VPN) Widzę wzrost ruchu PPP i GRE
- To samo, jeśli wysyłam ping do prywatnego interfejsu (B) (serwer VPN)
- Jeśli pinguję inny serwer (C) w sieci, widzę żądania pakietów ICMP, ale nie otrzymuję odpowiedzi (nie jestem pewien, czy serwer (C) odpowiada bezpośrednio na adres IP klienta (D) VPN), czy nie - to naprawdę jest., tak widzę ruch w (A))
Nie potrafię wyjaśnić punktów 1 lub 2 - spodziewałem się protokołu ICMP, ale problem wydaje się polegać na wysyłaniu ruchu do (D). Aby to przetestować, wysłałem żądanie echa do (D) z (C) i OTRZYMAŁEM odpowiedź, jednak NIE WIDZIAŁEM skorelowanego ruchu ICMP do (D) (czy może to być ruch GRE?). Wydaje mi się to dziwne, ale (C) zdecydowanie wysyła ping do właściwej maszyny, ponieważ przestaje odpowiadać, gdy odłączam (D) od VPN.
Zwróć również uwagę, że nie widzę ruchu na (D) do adresów sieci VPN, tylko do routerów, które mają skonfigurowane przekierowanie portów. Może to jakiś problem z routingiem?
Serwer VPN wydaje się mieć problem z pingiem (D) - mówi NO RESOURCES,
PathPing
http://en.wikipedia.org/wiki/PathPing
pokazuje, że używa interfejsu (A). i ten problem występuje tylko podczas pingowania (D), wszystko inne pinguje bez problemów.
Zmieniłem RRAS na konfigurację z pojedynczą kartą sieciową i problem z awarią zasobów zniknął - wydaje mi się, że jestem w stanie pingować klienta ze wszystkich maszyn, ale nie mogę wysłać polecenia ping z klienta. Mówię, że gdy pinguję klienta, zajmuje to mniej niż 1 ms (pamiętaj, że dzieje się to przez Internet i różnych dostawców usług internetowych) i nie widzę żadnego ruchu ICMP na serwerze VPN - plus, kiedy odłączam klienta nadal można go pingować!?! (To tak, jakby serwer VPN odpowiadał na żądania echa w imieniu klienta). Gdy to się dzieje, serwer VPN uzyskuje limity czasu, gdy pinguje rozłączonego klienta. BARDZO DZIWNY!
Po pozostawieniu go na chwilę (picie herbaty, zjedzenie czegoś takiego jak jedzenie), serwer VPN wrócił do problemu Brak zasobów i nie mam pingowania w żadnym kierunku. Wyłączenie RRAS i ponowne włączenie go doprowadziło mnie z powrotem do miejsca, w którym byłem przed chwilą, mogę teraz pingować z sieci LAN do klienta.
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
4 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
To, co próbujesz zrobić, zadziała dobrze. Prawdopodobnie nie uzyskujesz rozpoznawania nazw NetBIOS przez VPN, ponieważ prawdopodobnie nie używasz serwera WINS w sieci LAN. To byłoby moje „psychiczne” przypuszczenie, dlaczego masz kłopoty.
Zainstalowanie usługi RRAS na kontrolerze domeny sprawia, że jest on wieloadresowy. To zadziała, ale Microsoft tego nie poleca. Powinieneś o tym pomyśleć
uniemożliwić adapterowi RRAS rejestrację w DNS i WINS
http://support.microsoft.com/kb/292822
.
Edytować:
Nie sądzę, żeby w mojej odpowiedzi było coś „zmyślonego”. Próbuję pomóc w oparciu o Twój niedokładny opis Twoich problemów (używając terminu „zobacz”, a nie to, co dokładnie zawodzi, gdy jesteś połączony) oraz na podstawie mojego doświadczenia przy rozwiązywaniu podobnych problemów. Twoje niejasne stwierdzenie o używaniu RADIUSa dało mi poczucie, że nie jesteś profesjonalnym administratorem (później potwierdził to Twój komentarz dotyczący Twojej pracy) i prawdopodobnie próbowałeś użyć jakiegoś narzędzia graficznego lub aplikacji, aby uzyskać dostęp do zasobów w sieci lokalnej. ale nie udało się wykonać podstawowych kroków rozwiązywania problemów, takich jak weryfikacja łączności na poziomie 3, rozpoznawanie nazw itp.
Skonfigurowałem serwery RRAS na kontrolerach domeny w sieciach lokalnych połączonych z Internetem za zaporami NAT. Łączę się z nimi kilka razy w tygodniu. To, co próbujesz zrobić, działa świetnie.
Czy zezwalasz serwerowi RRAS na przypisywanie adresów IP klientom z DHCP, czy też określasz zakres adresów? Jeśli podałeś zakres adresów, czy znajduje się on w podsieci LAN, czy też jest to inna podsieć? Czy adres IP jest przypisany do klienta podczas „łączenia” z tym, czego się spodziewasz?
Wciąż nie jest dla mnie jasne, co próbowałeś zrobić po „połączeniu”, co powoduje, że myślisz, że nie możesz „zobaczyć” sieci LAN. Czy możesz pingować adres IP serwera RRAS? Czy możesz nawiązać połączenia TCP z usługami hostowanymi na serwerze RRAS lub innymi serwerami w sieci lokalnej na podstawie adresu IP? Czy otrzymujesz rozpoznawanie nazw DNS?
Wreszcie nie miałem pojęcia, że przeniesienie usługi RRAS na inny serwer sprawi, że cokolwiek zadziała. Założyłem, że Microosft nie zaleca używania kontrolerów domeny z wieloma sieciami. RRAS będzie działał dobrze na kontrolerze domeny, jeśli rozumiesz jego konsekwencje.
Edycja 2:
Po skonfigurowaniu serwera RRAS do przypisywania adresów IP z DHCP, czy widzisz, że klientowi jest przypisany dobry adres IP w sieci LAN?
Zakładając, że tak jest i nie można odczytać adresu IP LAN serwera RRAS od klienta, czas rozpocząć nasłuchiwanie ruchu. Sniffowałbym na serwerze RRAS
i
na kliencie, aby upewnić się, że żądanie PING prawidłowo kieruje połączenie VPN (jak ładunek zaszyfrowany przez GRE - prawdopodobnie używasz PPTP). Jeśli nasłuchiwanie jest niewygodne, można monitorować przesyłane bajty za pomocą okna dialogowego Stan podłączonego klienta w węźle Klienci dostępu zdalnego w przystawce Routing i dostęp zdalny w konsoli zarządzania. Chociaż bym węszył - nic nie zastąpi przeglądania danych przez kabel.
Przypuszczam, że tablica routingu klienta wygląda tak, jak można by oczekiwać po połączeniu. Domyślnie klient VPN firmy Microsoft przypisuje bramę domyślną do sieci zdalnej (pole wyboru Użyj bramy domyślnej w sieci zdalnej we właściwościach zaawansowanych protokołu TCP/IP dla połączenia VPN). Jeśli ją wyłączysz, zamiast zmieniać bramę domyślną, zobaczysz wpis dotyczący sieci bramy zdalnej z adresem IP przypisanym do karty klienta VPN. Nie wspominasz, czym jest system operacyjny klienta, ale zachowanie klienta Microsoft VPN nieznacznie się zmieniło w systemie Windows 7 (co pozwala na jawne wyłączenie głupiego, „klasycznego” zachowania dodawania tras).
Prawdopodobnie przebiega bez pytania, ale podsieć IP LAN serwera VPN i podsieć LAN, do której klient jest podłączony, używają różnych zakresów adresów, prawda?
Anonimowy użytkownik
Potwierdzenie od:
Zmień podsieć IP. Nie takie proste, wiem ... haha.
Anonimowy użytkownik
Potwierdzenie od:
Możesz to sprawdzić w ten sposób: będąc w VPN, otwórz powłokę (monit DOS lub cokolwiek) na swoim kliencie i uruchom (pod Windows)
ipconfig/all
or (under linux)
cat/etc/resolv.conf
This will show you which DNS server you are using. This DNS server either must reside on the target network (the most commonly used solution) or must be able to resolve names of machines in the target network to IP addresses.
Drugi test polega na sprawdzeniu routingu. Pod typem Windows
route print
Under Linux, use
sudo route -nv
This will give you output looking like this:
# route -nv
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.180.0.1 10.180.0.169 255.255.255.255 UGH 0 0 0 tun0
10.180.0.169 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.172.0.0 10.180.0.169 255.255.0.0 UG 0 0 0 tun0
10.171.0.0 10.180.0.169 255.255.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.10.254 0.0.0.0 UG 0 0 0 eth0W powyższym przykładzie sieci 10.171.0.0/16 i 10.172.0.0/16 są kierowane przez tunel.
Jeśli na kliencie brakuje któregokolwiek z tych dwóch parametrów, sprawdź konfigurację serwera VPN, aby zobaczyć, czy jest faktycznie skonfigurowany do wysyłania odpowiednich bitów do klienta. To oczywiście zależy od typu używanego serwera VPN.
Anonimowy użytkownik
Potwierdzenie od:
Aby rozwiązać ten problem, RĘCZNIE dodałem statyczną pulę adresów (nie zadziała, jeśli skonfigurujesz ją w ten sposób podczas konfigurowania RRAS).
Teraz mogę pingować. Chociaż DNS wydaje się być problemem, nawet jeśli klient wybierze prawidłowe serwery DNS - aby rozwiązać ten problem, należy skonfigurować połączenie sieciowe VPN na kliencie, aby dodać sufiks DNS.