Połączenie VPN powoduje, że DNS używa niewłaściwego serwera DNS

17

Mam komputer z systemem Windows 7 w naszej sieci firmowej (która jest członkiem naszej Active Directory). Wszystko działa dobrze, dopóki nie otworzę połączenia VPN z witryną klienta.

Kiedy się łączę, tracę dostęp do sieci do udziałów w sieci, w tym do katalogów takich jak „Dane aplikacji”, dla których mamy zasady przekierowywania folderów. Jak możesz sobie wyobrazić, utrudnia to pracę na komputerze, ponieważ skróty pulpitu przestają działać, oprogramowanie przestaje działać poprawnie z powodu wyciągnięcia spod nich „Danych aplikacji”.

Nasza sieć jest trasowana (10.58.5.0/24), a inne lokalne podsieci istnieją w zakresie 10.58.0.0/16. Sieć zdalna działa na 192.168.0.0/24.

Wyśledziłem problem związany z DNS. Jak tylko otworzę tunel VPN, cały mój ruch DNS przechodzi przez sieć zdalną, co tłumaczy utratę lokalnych zasobów, ale moje pytanie brzmi, jak mogę zmusić lokalne zapytania DNS do kierowania na nasze lokalne serwery DNS, a nie do naszych klientów ?

Dane wyjściowe, ipconfig /allgdy nie jest podłączony do VPN, są poniżej:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

To jest wynik tego samego polecenia z podłączonym tunelem VPN:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

PPP adapter Customer Domain:

   Connection-specific DNS Suffix  . : customerdomain.com
   Description . . . . . . . . . . . : CustomerDomain
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.0.85(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 192.168.0.16
                                       192.168.0.17
   Primary WINS Server . . . . . . . : 192.168.0.17
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tabela routingu

Metryka Interfejs sieci docelowej maski bramy

          0.0.0.0          0.0.0.0        10.58.5.1       10.58.5.89     20
        10.58.5.0    255.255.255.0         On-link        10.58.5.89    276
       10.58.5.89  255.255.255.255         On-link        10.58.5.89    276
      10.58.5.255  255.255.255.255         On-link        10.58.5.89    276
    91.194.153.42  255.255.255.255        10.58.5.1       10.58.5.89     21
        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.0.0    255.255.255.0     192.168.0.95     192.168.0.85     21
     192.168.0.85  255.255.255.255         On-link      192.168.0.85    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.58.5.89    276
        224.0.0.0        240.0.0.0         On-link      192.168.0.85    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.58.5.89    276
  255.255.255.255  255.255.255.255         On-link      192.168.0.85    276

Kolejność wiązania interfejsów jest następująca:

wprowadź opis zdjęcia tutaj

Nie skonfigurowałem tunelu VPN do korzystania z domyślnej bramy na zdalnym końcu, a połączenia sieciowe z węzłami w obu sieciach są w porządku. (tzn. mogę pingować dowolny węzeł w naszej sieci lub w sieci zdalnej).

Zmodyfikowałem właściwości połączenia PPTP, aby użyć serwerów DNS, 10.58.3.32a następnie 192.168.0.16zapytanie nadal wynosi 192.168.0.16.

Edytować:

Lokalne zasoby, które znikają, są hostowane w katalogu głównym DFS domeny, co może (ale nie musi) być istotne.

Dalsza edycja:

Wydaje się, że wpływa to tylko na katalog główny DFS domeny. Jeśli odwołam się do udziału poprzez nazwę serwera (tj. \\server\shareZamiast \\dfsroot\share), będę mógł uzyskać dostęp do udziałów.

Zgodnie z moim komentarzem do tej odpowiedzi stwierdziłem, że mogę dodać nazwę DNS domeny do mojego pliku hosts, co powstrzymuje moje dyski sieciowe (DFS) przed zniknięciem, ale nadal chciałbym odważną część mojego pytania (powyżej ), jeśli ktoś ma jakieś pomysły.

— Bryan
źródło

Nigdy nie wspominałeś, z której zapory korzystasz? To dość ważny czynnik IMO, ponieważ myślę, że właśnie tam potencjalnie znajdziesz odpowiedź na to pytanie.

— Hanny

@hanny firewall zapewnia translacja adresów sieciowych w modemach ADSL w obu lokalizacjach. Prawdopodobnie mogę podać numery modeli, jeśli naprawdę będą potrzebne, ale będą to po prostu standardowe modemy ADSL NATing. Biorąc pod uwagę, że mówimy o AD ze zintegrowanym DNS, nie uważam tych urządzeń za istotne, ponieważ problemy dotyczą wyłącznie DNS.

— Bryan,

Jeśli VPN nie jest obsługiwany przez zaporę ogniową, ale Windows, to przedstawia inny wysłany parametr do pracy, ponieważ Windows VPN jest dość ograniczony z mojego doświadczenia. Na przykład w przypadku ASA 5505 - tunelowanie z podziałem jest naprawdę bardzo łatwe do rozwiązania i istnieje wiele konfiguracji, które można wykonać, szczególnie w odniesieniu do problemów z DNS i przypisywania DNS. Dlatego zapytałem, dziękuję za wyjaśnienie.

— Hanny

Czy możesz dodać route print(z połączenia VPN) do postu?

— florianb

Nie ma nic złego w routingu, ponieważ jest on w stanie łączyć się przez IP, ale nie przez DNS

— MichelZ

12

OK, znalazłem świetny zasób tutaj: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/

To nie jest idealne, ale może działać.

Kolejność wiążące są przechowywane w rejestrze w następującej lokalizacji: HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. Lista zawiera wszystkie identyfikatory GUID urządzeń dla kart sieciowych i aktywnych połączeń w kolejności priorytetów wiązania.

Podczas pracy z kluczem rejestru pojawiają się następujące fakty:

Zmiana kolejności identyfikatorów GUID w rejestrze ma wpływ na kolejność wiązania, w tym dla połączeń VPN

Wszelkie zmiany klucza obowiązują natychmiast

Po zakończeniu połączenia VPN identyfikator GUID połączenia jest dodawany na początku kolejności wiązania, jeśli jeszcze nie istnieje

Po zamknięciu połączenia VPN wpis GUID połączenia jest usuwany

Jeśli istnieje wiele wpisów GUID dla połączenia, tylko jeden zostanie usunięty, gdy połączenie zostanie zamknięte

Ten mechanizm stwarza możliwość następującego obejścia:

Sprawdź klucz rejestru Bind

Połącz się z połączeniem VPN

Sprawdź ponownie klucz Bind i skopiuj identyfikator GUID, który został dodany na początku listy

Wklej wpis GUID na dole listy 20 razy

Wyeksportuj klucz i wyczyść wyeksportowany plik, aby uwzględnić tylko klucz powiązania

Wynik jest kluczem, który będzie wspierać pożądane zachowanie. Za każdym razem, gdy ustanowione jest połączenie VPN, ponieważ GUID jest obecny, nie zostanie dodany. Ponieważ identyfikator GUID znajduje się na dole, rozpoznawanie DNS będzie wykonywane lokalnie na kliencie. Po rozłączeniu połączenia jeden wpis GUID zostanie usunięty. Po 20 połączeniach VPN wyeksportowanego pliku rejestru można użyć do ponownego zaimportowania klucza.

Oczywiście możesz wkleić GUID więcej razy, aby zmniejszyć częstotliwość ponownego importowania klucza.

Należy również pamiętać o ponownym wykonaniu tej procedury, jeśli wystąpią jakiekolwiek zmiany w kartach sieciowych.

— ZnArK
źródło

Dobre znalezisko. Działa to bardzo dobrze, w połączeniu ze skryptem uruchamiania komputera, który resetuje wartość klucza rejestru przy każdym rozruchu, co powinno być świetnym obejściem tego, co nie powinno stanowić problemu. Wielkie dzięki. Dam jeszcze kilka testów.

— Bryan

3

Poleciłbym utworzyć zaplanowane zadanie. Monitoruj zdarzenie o numerze 20226, które odpowiadają zdarzeniu rozłączenia VPN. Następnie ogień mały skrypt powershell ( powershell -File c:\scripts\fixdnsbind.ps1), który zawiera:

$val = Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind;  $val.Bind += "\Device\{D7D0BD5E-B65C-4239-BA4D-D309186E9524}";  Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind -Value $val.Bind

. (nie zapomnij dostosować identyfikatora adaptera). Uruchom ten skrypt także raz przed połączeniem z VPN.

— Steve B,

4

Wydaje mi się, że tunel VPN w jakiś sposób ma pierwszeństwo przed interfejsem lokalnym kierującym ruch DNS do serwerów VPN DNS (możesz sprawdzić żądanie na tych serwerach, aby zweryfikować to zachowanie, jeśli masz do nich dostęp lub ktoś może zweryfikować to zachowanie dla ty).

Tego nie mogę całkowicie wyjaśnić, ponieważ wiążący porządek wskazuje inaczej. Zgodnie z tym postem tutaj (patrz odpowiedź o wyższej punktacji) system Windows ma odmienne zdanie na ten temat, wybierając kanał o wyższym priorytecie w zależności od szybkości połączenia, NIE od kolejności łączenia adaptera. Na potrzeby testowania spróbuj wykonać następujące czynności, aby zmienić to automatyczne zachowanie: 1) przejdź do Połączenia sieciowe i dla każdego z nich wykonaj 2) Właściwości IP v4 3) Zaawansowane 4) Wyłącz „Automatyczną metrykę” 5) Ręcznie ustaw metrykę 1 dla twojego lokalnego połączenie i metryka 2 w połączeniu VPN (PPP). W ten sposób będzie twardo łączyć ścieżkę z lokalnymi serwerami DNS w sposób preferowany nad zdalnym DNS.

Mam nadzieję że to pomoże!

— Ank
źródło

Interesujące, patrząc na moją tabelę routingu powyżej, metryka w interfejsie LAN jest najniższa (20), połączenie VPN ma metrykę 21. Powiedziawszy to, ten problem może być nieco przerywany, a tabela routingu jest pokazana powyżej , wszystko działa obecnie poprawnie. Spróbuję odtworzyć problem i ponownie sprawdzić tabelę routingu.

— Bryan

Zaktualizuj, właśnie ponownie otworzyłem tunel i wszystkie moje połączenia z dyskami spadły, ale tabela routingu nie różni się od powyższej. tzn. Metric 20 dla LAN, Metric 21 dla VPN.

— Bryan

1

@Bryan, ten artykuł Microsoft ( support.microsoft.com/kb/299540 ) w pewnym sensie weryfikuje to, co powiedziałem powyżej. Byłoby ciekawie zobaczyć, co się stanie, jeśli przejdziesz przez procedurę, którą napisałem powyżej, kiedy będziesz miał czas. Inni zgłosili dokładnie pojawiające się sporadyczne problemy i rozwiązali je, wykonując okablowanie wskaźników ( serverfault.com/questions/70792/… ). Niestety obecnie nie mam podobnej konfiguracji do przeprowadzenia niektórych testów.

— dniu

Wielkie dzięki za to @ank, z pewnością spróbuję później w przyszłym tygodniu, kiedy wrócę do biura. Ciekawy artykuł BTW. Dzięki.

— Bryan

1

To załatwiło sprawę! Metryka w ustawieniach IPv4 dla karty sieciowej nie wydaje się mieć nic wspólnego z metryką w tabeli routingu! Zmiana kolejności identyfikatora GUID w HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind, o czym pisał ZnArK, nie zmieniła niczego w odniesieniu do używanego NIC / DNS. Jest to testowane w systemie Windows 10

— MrCalvin

4

Jak wspomniano, jest to problem tunelowania podzielonego.

Trzy poprawki, zalecam nr 2, ponieważ jest to łatwe i będzie miało dobrą wydajność, jeśli użyjesz dobrego pudełka z VMware Workstation 8

1 - Włącz dzielone tunelowanie - niepewne i może wymagać pracy po stronie klienta. Prawdopodobnie nie stanie się to, gestapo bezpieczeństwa IT spowoduje zamknięcie systemu.

2 - Zwirtualizowane podejście pulpitu - P2V istniejący pulpit i zmień go w maszynę wirtualną. Użyj maszyny wirtualnej do VPN do klienta. Zachowujesz pulpit i możesz w niego przełączać się z niego w razie potrzeby.

3 - Podejście zwirtualizowanego serwera - P2V istniejący pulpit i zmień go w maszynę wirtualną, a następnie umieść w bezpłatnej wersji ESXi. Zachowujesz pulpit i możesz w razie potrzeby przełączać się na maszynę wirtualną za pomocą konsoli. To może być powolne ...

— Brennan
źródło

+1; Podoba mi się pomysł posiadania dedykowanego zwirtualizowanego systemu do tego zadania, jednak nie widzę, aby działał on tutaj dobrze z różnych powodów. Z pewnością będzie to dobre rozwiązanie w przyszłości. Dzięki.

— Bryan

3

Niestety, Windows VPN nie jest w stanie wykonać „Split-DNS”. Możesz jednak usunąć serwer DNS z połączenia VPN po połączeniu ze zdalną witryną.

Możesz to zrobić, wydając:

netsh interface ipv4 delete dnsservers name = " nazwa VPN " adres = wszystko sprawdź = nie

Musisz to zrobić za każdym razem, gdy łączysz się z siecią VPN.

— MichelZ
źródło

FYI ... to powstrzymuje cię od korzystania ze zdalnego (VPN) DNS.

— MichelZ

Problem polega na tym, że jak tylko tunel się skończy, już cierpię z powodu problemu opisanego w moim pytaniu, więc polecenie będzie za późno. Po eksperymentowaniu z tym polecenie wydaje się nie robić żadnej różnicy ( nslookupnadal używa zdalnego serwera DNS, a ponadto ipconfigwyświetla listę zdalnego serwera DNS). Edytowałem również ustawienia DNS połączenia tunelowego VPN, aby użyć własnych wewnętrznych ustawień DNS, ale jest to ignorowane, cały mój ruch DNS nadal wydaje się kierować na zdalny serwer DNS.

— Bryan

1

Próbowałem tego, ponieważ miałem ten sam problem i zadziałało tutaj. Czy zmieniłeś „ nazwę VPN ”? Dodatkowo, jeśli są głównie zaniepokojony tym jednym serwerze, na którym napędy są podłączone do, dodaj je w pliku hosts, i nic nie będzie w stanie go zastąpić

— MichelZ

Dzięki, próbowałem zmienić nazwę (wytnij i wklej z ipconfigwyjścia, a kiedy się pomyliłem, dostałem błąd The filename, directory name, or volume label syntax is incorrect), więc jestem prawie pewien, że poprawnie wykonałem polecenie. Może to być coś na zdalnym serwerze PPTP, który nie pozwala mi zastąpić ustawienia DNS. Zbadam, ale podoba mi się pomysł wpisu pliku hosts. Spróbuję to zrobić. Zobacz także moją edycję pytania.

— Bryan

Właśnie spróbowałem ponownie, a to usunęło serwer DNS z połączenia PPP. Czy możesz to zweryfikować za pomocą ipconfig /all? Myślę jednak, że wpis hosta powinien być dla Ciebie najłatwiejszym rozwiązaniem.

— MichelZ

2

Twój tunel VPN znajduje się między klientem a siecią klienta. Wygląda na to, że nie używa tunelowania podzielonego, co uniemożliwi dostęp do zasobów w sieci, gdy tunel jest uruchomiony.

Więc (lub Twój klient) musisz włączyć tunelowanie podzielone lub potrzebujesz dodatkowego połączenia sieciowego i dostosowanej tabeli tras, aby uzyskać dostęp do obu sieci jednocześnie.

— dunxd
źródło

Aby uzyskać informacje, mogę uzyskać dostęp do zasobów sieciowych, gdy tunel jest uruchomiony, tylko rozdzielczość DNS wydaje się zepsuć. split tunnellingSzczerze mówiąc, nie znałem tego terminu , ale o ile mogę stwierdzić, oznacza to po prostu upewnienie się, że nie korzystam z domyślnej bramy w zdalnej witrynie, co, mimo że nie sprecyzowałem, już to robię. Dzięki za odpowiedź, zmienię moje pytanie, aby to odzwierciedlić.

— Bryan

1

W takim przypadku wygląda na to, że sieć VPN klienta nie jest skonfigurowana do podziału DNS. Dzięki podzielonemu DNS koncentrator VPN daje Twojemu klientowi VPN listę serwerów DNS (tak jak obecnie), a także listę domen, które są jedynymi domenami, które powinny być używane z tymi serwerami DNS; wszyscy inni używają domyślnego DNS twojego systemu.

— James Sneeringer

0

Chociaż pytanie to zostało zadane dawno temu, ale opublikowanie tej odpowiedzi, ponieważ może to pomóc innym. Miałem ten sam problem z VPN, gdzie kiedy użytkownicy łączyli się ze zdalną VPN, ich zewnętrzne dny zatrzymywały się np. google.comdziałały tylko domeny firmowe wymienione na split-dns.

Problem polegał na tym, że gdy używana jest lokalna maszyna, ruch zapytań dns trafia do tunelu VPN, a jeśli dns jest dozwolony w tunelu, spada. Kiedy pojawia się w trybie awaryjnym, najpierw wybiera ipv6 jako rozdzielczość, a następnie nigdy nie wraca do ipv4.

Aby przetestować wyniki, najpierw wyłączyliśmy ipv6 na komputerze lokalnym, który zaczął działać. Aby trwale to naprawić dla wszystkich użytkowników, włączyliśmy client-bypass-protocolkomendę w zaporze ASA, która zignorowała IPv6, jeśli nie jest skonfigurowany w pulach VPN.

więc jeśli nie możesz kontrolować zapory ogniowej i wiesz, że podzielony tunel i podzielone dns są na swoim miejscu, ale to nie działa, możesz spróbować wyłączyć ipv6na lokalnym komputerze, a jeśli możesz to kontrolować, możesz włączyć powyższą komendę, o ile nie używasz ipv6 w twojej zdalnej sieci.

Pomogło mi to, mam nadzieję, że to pomoże innym :)

— Rsingh
źródło

0

Tak, z czym mam doświadczenie!

Ustaw połączenie VPN z lokalnym serwerem DNS i połącz się z VPN używanym przez nslookup do zapytania o nazwę domeny VPN. Powinieneś otrzymać odpowiedź z adresem IP lokalnym dla sieci VPN LAN. Oznacza to, że użyłeś serwerów DNS VPN do rozwiązania zapytania.

Teraz otwórz połączenie LAN i ręcznie ustaw DNS na DNS lokalny lub ISP. Volia !!! użyj klawisza strzałki i powtórz zapytanie nslookup. Otrzymasz publiczny adres IP, co oznacza, że użyłeś lokalnego / DNS serwera ISP do rozwiązania zapytania domeny VPN. Bam !!!!

— Graham.Fraser
źródło

0

Po prostu usuwam tę opcję z konfiguracji VPN klienta

setenv opt block-outside-dns

To rozwiązało problem

— Ismail
źródło

0

Miałem ten problem kilka lat temu i naprawiłem go, edytując plik połączenia VPN, po prostu stwórz plik vpn.pbk (można go znaleźć w Google), otwórz ten plik za pomocą edytora tekstu, takiego jak notatnik, i zmień wartość UseRasCredentials na zero, a twój problem zostanie rozwiązany. ale jedynym problemem jest to, że połączenia lokalne priorytet DNS stają się wyższe niż VPN DNS i rozpoznawanie nazw zajmuje więcej czasu (jeśli VPN jest używany do łączenia się z Internetem).

— Mohsen Bigdeli
źródło

-1

Jak myślisz, dlaczego to DNS?

Jeśli stracisz dostęp do udziałów sieciowych podczas łączenia się z VPN - wydaje się prawie na pewno, że twój komputer ma problemy z WINS / NETBIOS.

Zdefiniuj serwer WINS i przetestuj ponownie.

— Ben Lessani - Sonassi
źródło

Nie wiem na pewno, że to jest przyczyna moich problemów, ale wiem, że klienci AD powinni używać serwerów DNS używanych do hostowania AD, a tak nie jest. Ponieważ problem pojawia się tylko wtedy, gdy nawiązuję połączenie VPN, a moja rozdzielczość DNS spada jednocześnie, wydaje się, że DNS jest prawdopodobnym kandydatem. Niezależnie od tego, nie chcę używać zdalnego serwera DNS, gdy łączę się z inną siecią za pomocą VPN.

— Bryan

Czy zdefiniowałeś serwer WINS zgodnie z moją sugestią? Używanie serwera DNS w sieci VPN nie jest typowe dla systemu Windows, chyba że zdefiniowano użycie jednego z nich lub „Ustawiono opcję używania bramy zdalnej”, która, jak mówiono, jest wyłączona. Używasz również statycznego adresu IP w tunelu VPN, więc dlaczego w ogóle ustawiłeś wpisy DNS? Usuń te serwery DNS (192.168.0.16-17) lub ustaw serwer WINS.

— Ben Lessani - Sonassi

Nie, nie próbowałem tego, ponieważ nie mamy serwera WINS do wskazywania klientom. Nie jestem przekonany, że WINS pomoże być uczciwym, więc nie chcę instalować serwera WINS w naszej sieci, ponieważ może to pomóc. Z pewnością będę jednak pamiętać o tym pomyśle, więc dzięki. Adres IP jest przypisywany przez serwer VPN i jest dynamiczny. Jeśli nie przypisam serwera DNS do połączenia VPN, jest on dynamicznie przydzielany przez serwer. Nawet na stałe zakodowałem własne serwery DNS we właściwościach połączenia VPN, ale nadal używa serwerów DNS w zdalnej witrynie.

— Bryan

Nie potrzebuję ani nie chcą używać do zdalnego serwera DNS, nigdy, zawsze chcę rozdzielczość DNS ma być wykonywana na serwerze lokalnym, to będzie rozwiązać mój problem, stąd moje pytanie, koncentrując się na DNS. Prawdopodobnie mógłbym użyć reguły zapory, aby zablokować dostęp do zdalnego serwera DNS, ale to nie rozwiązuje problemu leżącego u podstaw błędnej konfiguracji.

— Bryan

1

twoja interpretacja tego jest nieprawidłowa. Adres IP jest przypisywany przez serwer PPTP, który tak naprawdę nie korzysta z DHCP. Serwer PPTP ma pulę, z której może przydzielić, ale nie jest to DHCP. Dostaję jednak inny adres IP za każdym razem, gdy się łączę. Co więcej, nie zaznaczyłem tego pola, aby użyć bramy zdalnej, jak wyraźnie widać z tabeli routingu.

— Bryan