Koneksi VPN menyebabkan DNS menggunakan server DNS yang salah

17

Saya memiliki PC Windows 7 di jaringan perusahaan kami (yang merupakan anggota dari Active Directory kami). Semuanya berfungsi dengan baik sampai saya membuka koneksi VPN ke situs pelanggan.

Ketika saya terhubung, saya kehilangan akses jaringan untuk berbagi di jaringan, termasuk direktori seperti 'Data Aplikasi' yang memiliki kebijakan pengalihan folder. Seperti yang dapat Anda bayangkan, ini membuat bekerja pada PC sangat sulit, karena pintasan desktop berhenti bekerja, perangkat lunak berhenti berfungsi dengan baik karena 'Data Aplikasi' ditarik dari bawahnya.

Jaringan kami dirutekan (10.58.5.0/24), dengan subnet lokal lain ada dalam ruang lingkup 10.58.0.0/16. Jaringan jarak jauh pada 192.168.0.0/24.

Saya telah melacak masalahnya karena terkait DNS. Segera setelah saya membuka terowongan VPN, semua lalu lintas DNS saya berjalan melalui jaringan jarak jauh, yang menjelaskan hilangnya sumber daya lokal, tetapi pertanyaan saya adalah, bagaimana saya bisa memaksa permintaan DNS lokal untuk pergi ke server DNS lokal kami alih-alih pelanggan kami ?

Output ipconfig /allketika tidak terhubung ke VPN di bawah ini:

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

Ini adalah output dari perintah yang sama dengan terowongan VPN yang terhubung:

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

Tabel perutean

Metrik Tujuan Jaringan Netmask Gateway Interface

          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

Urutan pengikatan untuk antarmuka adalah sebagai berikut:

masukkan deskripsi gambar di sini

Saya belum mengonfigurasi terowongan VPN untuk menggunakan gateway default di ujung jarak jauh, dan jaringan comms ke node di kedua jaringan baik-baik saja. (yaitu saya dapat melakukan ping ke sembarang simpul di jaringan kami atau jaringan jarak jauh).

Saya telah memodifikasi properti koneksi PPTP untuk menggunakan server DNS 10.58.3.32diikuti oleh 192.168.0.16, namun permintaan masih pergi ke 192.168.0.16.

Edit:

Sumber daya lokal yang hilang dihosting pada root domain DFS, yang mungkin (atau mungkin tidak) relevan.

Edit Lebih Lanjut:

Ini sepertinya hanya memengaruhi root DFS domain. Jika saya mereferensikan share melalui nama server (yaitu \\server\sharealih-alih \\dfsroot\share), saya dapat mengakses share.

Sesuai komentar saya terhadap jawaban ini , saya telah menemukan saya dapat menambahkan nama DNS domain ke file host saya yang menghentikan drive jaringan (DFS) saya menghilang, tetapi saya masih ingin bagian tebal dari pertanyaan saya (di atas ) menjawab jika ada yang punya ide.

— Bryan
sumber

Anda tidak pernah menyebut firewall mana yang Anda gunakan? Itu faktor IMO yang cukup penting, karena saya pikir di situlah Anda akan berpotensi menemukan jawaban untuk pertanyaan ini.

— Hanny

@hanny, firewall disediakan oleh terjemahan alamat jaringan pada modem ADSL di kedua situs. Saya mungkin dapat memberikan nomor model jika benar-benar diperlukan, tetapi mereka hanya akan menjadi modem standar ADSL bog. Mengingat bahwa kita berbicara tentang AD dengan DNS terintegrasi, saya tidak menganggap perangkat ini relevan, karena masalahnya murni DNS.

— Bryan

Jika VPN tidak ditangani oleh firewall tetapi Windows maka itu menyajikan parameter pengiriman yang berbeda untuk bekerja di dalamnya, karena Windows VPN cukup terbatas dalam pengalaman saya. Misalnya dengan ASA 5505 - split tunneling adalah sesuatu yang sangat mudah untuk dipecahkan dan ada banyak konfigurasi yang dapat dilakukan, terutama yang berkaitan dengan masalah DNS dan penugasan DNS. Itu sebabnya saya bertanya, terima kasih telah menjelaskan.

— Hanny

Bisakah Anda menambahkan route print(dari koneksi vpn) ke posting?

— florianb

Tidak ada yang salah dengan perutean, karena ia dapat menghubungkan melalui IP, tetapi tidak melalui DNS

— MichelZ

12

OK, temukan sumber yang bagus di sini: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/

Itu tidak sempurna, tetapi mungkin saja berhasil.

Urutan mengikat disimpan dalam registri di lokasi berikut: HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind. Daftar ini mencakup semua GUID perangkat untuk adaptor jaringan dan koneksi aktif dalam urutan prioritas yang mengikat.

Saat bekerja dengan kunci registri, fakta-fakta berikut muncul:

Mengubah urutan GUID dalam registri tidak memengaruhi urutan mengikat, termasuk untuk koneksi VPN

Setiap perubahan pada tombol segera berlaku

Ketika koneksi VPN selesai, GUID untuk koneksi ditambahkan ke bagian atas urutan mengikat jika belum ada

Ketika koneksi VPN ditutup, entri GUID untuk koneksi dihapus

Jika ada beberapa entri GUID untuk koneksi, hanya satu yang dihapus ketika koneksi ditutup

Mekanisme ini menciptakan kemungkinan solusi berikut:

Periksa kunci registri Bind

Hubungkan ke koneksi VPN Anda

Periksa kembali tombol Bind dan salin GUID yang telah ditambahkan ke bagian atas daftar

Tempel entri GUID di bagian bawah daftar 20 kali

Ekspor kunci dan bersihkan file yang diekspor hanya menyertakan kunci ikat

Hasilnya adalah kunci yang akan mendukung perilaku yang diinginkan. Setiap kali koneksi VPN dibuat, karena GUID ada, itu tidak akan ditambahkan. Karena GUID ada di bagian bawah, resolusi DNS akan dilakukan secara lokal ke klien. Ketika koneksi terputus, satu entri GUID akan dihapus. Setelah 20 koneksi VPN, file registri yang diekspor dapat digunakan untuk mengimpor kembali kunci.

Tentu saja, Anda dapat menempelkan GUID lebih sering untuk mengurangi seberapa sering Anda harus memasukkan kembali kunci.

Juga penting untuk diingat untuk mengulang prosedur ini jika ada perubahan pada adaptor jaringan.

— ZnArK
sumber

Bagus temukan. Itu bekerja dengan sangat baik, ditambah dengan skrip start up komputer untuk mereset nilai kunci registri setiap boot, yang seharusnya menjadi solusi yang bagus untuk apa yang seharusnya tidak menjadi masalah. Terimakasih banyak. Saya akan memberikan beberapa pengujian lebih lanjut.

— Bryan

3

Saya akan merekomendasikan untuk membuat tugas yang dijadwalkan. Pantau ID peristiwa 20226, yang terkait dengan acara putuskan VPN. Kemudian api script PowerShell kecil ( powershell -File c:\scripts\fixdnsbind.ps1) yang berisi:

$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

. (jangan lupa untuk mengadaptasi ID adaptor). Anda juga menjalankan skrip ini satu kali sebelum menghubungkan ke VPN.

— Steve B

4

Sepertinya saya bahwa terowongan VPN entah bagaimana lebih diutamakan daripada antarmuka area lokal yang mengarahkan lalu lintas DNS ke server DNS VPN (Anda dapat memeriksa permintaan pada server ini untuk memverifikasi perilaku ini jika Anda memiliki akses ke sana atau seseorang dapat memverifikasi perilaku ini untuk kamu).

Itu saya tidak bisa, sepenuhnya, menjelaskan karena urutan yang mengikat menunjukkan berbeda. Menurut posting ini di sini (lihat jawaban skor yang lebih tinggi) Windows memiliki persepsi yang berbeda dalam hal ini, memilih saluran prioritas yang lebih tinggi tergantung pada kecepatan koneksi BUKAN pada urutan pengikatan adaptor. Jadi demi pengujian coba yang berikut ini untuk mengubah perilaku otomatis ini: 1) pergi ke koneksi Jaringan dan untuk masing-masing lakukan 2) properti IP v4 3) Lanjutan 4) Nonaktifkan "Metrik Otomatis" 5) Secara manual menempatkan metrik 1 untuk lokal Anda koneksi dan metrik 2 pada koneksi VPN Anda (PPP). Dengan cara itu akan menyortir jalur ke server DNS lokal seperti yang lebih disukai daripada DNS jarak jauh.

Semoga ini membantu!

— pergelangan kaki
sumber

Menarik, melihat tabel perutean saya di atas, metrik pada antarmuka LAN adalah yang terendah (20), koneksi VPN memiliki metrik 21. Karena itu, masalah ini bisa agak terputus-putus, dan dengan tabel perutean seperti ditampilkan di atas , semuanya saat ini berfungsi dengan benar. Saya akan mencoba dan menciptakan kembali masalah dan memeriksa kembali tabel routing.

— Bryan

Perbarui, baru saja membuka kembali terowongan, dan semua koneksi saya ke drive telah jatuh, tetapi tabel routing tidak berbeda dengan di atas. yaitu Metrik 20 untuk LAN, Metrik 21 untuk VPN.

— Bryan

1

@Bryan, artikel Microsoft ini ( support.microsoft.com/kb/299540 ), semacam, memverifikasi apa yang saya katakan di atas. Akan menarik untuk melihat apa yang terjadi jika Anda pergi melalui prosedur yang saya tulis di atas ketika Anda punya waktu. Orang lain telah melaporkan masalah terputus-putus yang Anda lihat dan menyelesaikannya dengan memasang kabel metrik ( serverfault.com/questions/70792/… ). Sayangnya saya saat ini tidak memiliki pengaturan yang sama untuk melakukan beberapa tes.

— Pergelangan kaki

Terima kasih banyak untuk itu, terima kasih, saya pasti akan mencobanya minggu depan ketika saya kembali ke kantor. Artikel menarik BTW. Terima kasih.

— Bryan

1

Itu berhasil bagi saya! Metrix di pengaturan IPv4 untuk NIC tampaknya tidak ada hubungannya dengan metrix di tabel routing! Mengubah urutan GUID di HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind ketika ZnArK menulis tentang tidak mengubah apa pun mengenai NIC / DNS yang digunakan. Ini diuji pada Windows 10

— MrCalvin

4

Seperti yang dinyatakan, ini adalah masalah tunneling terbelah.

Tiga perbaikan, rekomendasikan # 2 karena mudah dan akan memiliki kinerja yang baik jika menggunakan kotak yang bagus dengan VMware Workstation 8

1 - Aktifkan split tunneling - tidak aman dan mungkin memerlukan pekerjaan di sisi klien. Tidak mungkin terjadi, gerakan keamanan TI akan mematikan Anda.

2 - Pendekatan desktop tervirtualisasi - P2V desktop yang ada dan ubah menjadi VM. Gunakan VM ke VPN ke klien. Anda menjaga desktop Anda, dan dapat beralih ke dalamnya dan keluar darinya sesuai kebutuhan.

3 - Pendekatan server tervirtualisasi - P2V desktop yang ada dan ubah menjadi VM, lalu letakkan di versi gratis ESXi. Anda menjaga desktop Anda, dan dapat beralih ke VM sesuai kebutuhan melalui konsol. Ini mungkin lambat ...

— Brennan
sumber

+1; Saya suka gagasan memiliki sistem tervirtualisasi yang didedikasikan untuk tugas tersebut, namun saya tidak melihat bahwa bekerja dengan baik di sini pada saat ini karena berbagai alasan. Ini pasti akan menjadi solusi yang baik di masa depan. Terima kasih.

— Bryan

3

Sayangnya, Windows VPN tidak dapat melakukan "Split-DNS". Namun Anda dapat menghapus Server DNS dari koneksi VPN setelah terhubung ke situs jarak jauh.

Anda dapat melakukan ini dengan mengeluarkan:

antarmuka netsh ipv4 delete dnsservers name = " name of the VPN " address = all validate = no

Anda HARUS melakukan ini setiap kali terhubung ke Jaringan VPN.

— MichelZ
sumber

FYI ... ini menghentikan Anda dari menggunakan Remote (VPN) DNS.

— MichelZ

Masalahnya adalah, segera setelah terowongan naik, saya sudah menderita masalah yang dijelaskan dalam pertanyaan saya, jadi perintahnya akan terlambat. Juga, setelah bereksperimen dengan ini, perintah itu sebenarnya tidak tampak membuat perbedaan ( nslookupmasih menggunakan server DNS jarak jauh, ditambah ipconfiglagi daftar server DNS jarak jauh). Saya juga mengedit pengaturan DNS untuk koneksi terowongan VPN untuk menggunakan pengaturan DNS internal saya sendiri, tetapi ini diabaikan, semua lalu lintas DNS saya tampaknya masih menuju ke server DNS jauh.

— Bryan

1

Saya telah mencoba ini karena saya memiliki masalah yang sama, dan itu berhasil di sini. Sudahkah Anda menyesuaikan " nama VPN "? Selain itu, jika Anda sebagian besar khawatir tentang server yang satu ini di mana drive Anda terhubung, tambahkan di file host Anda, dan tidak ada yang bisa

— menimpanya

Terima kasih, saya memang mencoba mengubah nama (cut dan paste dari ipconfigoutput, dan ketika saya salah, saya mendapat kesalahan The filename, directory name, or volume label syntax is incorrect), jadi saya cukup yakin saya mendapatkan perintah yang benar. Mungkin ada sesuatu di server PPTP jarak jauh yang tidak memungkinkan saya untuk menimpa pengaturan DNS. Saya akan menyelidiki, tapi saya suka ide entri file host. Saya akan mencobanya. Lihat juga edit saya untuk pertanyaan.

— Bryan

Saya baru saja mencoba perintah itu, dan itu menghapus Server DNS dari koneksi PPP. Bisakah Anda memverifikasi dengan ipconfig /all? Saya pikir bagaimanapun entri host harus memperbaiki paling mudah untuk Anda.

— MichelZ

2

Terowongan VPN Anda berada di antara klien dan jaringan klien. Kedengarannya seperti itu tidak menggunakan split tunneling, yang akan menghentikan Anda mengakses sumber daya di jaringan Anda sendiri saat terowongan naik.

Jadi Anda (atau klien Anda) perlu mengaktifkan tunneling split, atau Anda memerlukan koneksi jaringan tambahan dan tabel rute yang disesuaikan untuk mengakses kedua jaringan pada saat yang sama.

— dunxd
sumber

Untuk info, saya dapat mengakses sumber daya jaringan saat terowongan naik, hanya resolusi DNS yang tampaknya rusak. Saya tidak terbiasa dengan istilah split tunnellingjujur, tetapi sejauh yang saya tahu, itu hanya melibatkan memastikan bahwa saya tidak menggunakan gateway default di situs remote, yang meskipun saya tidak menentukan, saya sudah melakukannya. Terima kasih atas tanggapannya, saya akan mengedit pertanyaan saya untuk mencerminkan hal ini.

— Bryan

1

Dalam hal ini, sepertinya VPN pelanggan tidak diatur untuk DNS split. Dengan DNS split, konsentrator VPN memberi klien VPN Anda daftar server DNS (seperti saat ini), dan juga daftar domain yang merupakan satu-satunya domain yang harus digunakan dengan server DNS tersebut; semua yang lain akan menggunakan DNS default sistem Anda.

— James Sneeringer

0

Meskipun pertanyaan ini sudah lama ditanyakan tetapi posting jawaban ini karena ini dapat membantu orang lain. Saya memiliki masalah yang sama dengan VPN di mana ketika pengguna yang digunakan untuk terhubung ke vpn jarak jauh dns eksternal mereka digunakan untuk berhenti misalnya. google.comhanya domain perusahaan yang digunakan untuk bekerja yang terdaftar di split-dns.

Masalahnya adalah ketika mesin lokal yang digunakan melakukan lalu lintas permintaan dns pergi ke terowongan vpn dan jika dns diizinkan di terowongan itu jatuh kembali. Ketika itu mundur maka digunakan untuk memilih ipv6 sebagai resolusi pertama dan kemudian tidak pernah kembali ke ipv4.

Jadi untuk menguji hasilnya, pertama-tama kami menonaktifkan ipv6 pada mesin lokal yang mulai berfungsi. Untuk memperbaikinya secara permanen untuk semua pengguna kami mengaktifkan client-bypass-protocolperintah pada ASA firewall yang mengabaikan IPv6 jika tidak dikonfigurasi pada vpn pools.

jadi jika Anda tidak dapat mengontrol firewall dan mengetahui split tunnel dan split dns sudah ada namun gagal, Anda dapat mencoba menonaktifkan ipv6pada mesin lokal dan jika Anda dapat mengendalikannya maka Anda dapat mengaktifkan perintah di atas selama Anda tidak menggunakan ipv6 di jaringan jauh Anda.

Ini telah membantu saya, semoga ini membantu orang lain :)

— Rsingh
sumber

0

Yay sesuatu yang saya alami!

Atur koneksi VPN dengan server DNS lokal dan sambungkan ke VPN yang digunakan nslookup untuk menanyakan nama domain VPN. Anda harus mendapatkan respons dengan IP yang bersifat lokal ke VPN LAN. Ini berarti Anda menggunakan server DNS VPN untuk menyelesaikan kueri.

Sekarang buka koneksi LAN Anda dan atur DNS secara manual ke DNS lokal atau ISP Anda. sebuah Volia !!! gunakan tombol panah dan ulangi permintaan nslookup. Anda akan menerima IP publik yang berarti Anda menggunakan server DNS lokal / ISP Anda untuk menyelesaikan kueri domain VPN. Bam !!!!

— Graham. Fraser
sumber

0

Saya cukup menghapus opsi ini dari konfigurasi VPN klien

setenv opt block-outside-dns

Itu menyelesaikan masalah

— Ismail
sumber

0

Saya punya masalah ini beberapa tahun yang lalu dan diperbaiki dengan mengedit file koneksi VPN, buat saja file vpn.pbk (Anda dapat menemukannya di google) buka file itu melalui editor teks seperti notepad dan ubah nilai UseRasCredentials menjadi nol dan masalah Anda terpecahkan. tetapi satu-satunya masalah adalah Anda koneksi area lokal prioritas DNS menjadi lebih tinggi dari VPN DNS dan resolusi nama membutuhkan waktu lebih lama (jika VPN digunakan untuk terhubung ke internet).

— Mohsen Bigdeli
sumber

-1

Menurut Anda mengapa ini DNS?

Jika Anda kehilangan akses ke jaringan yang Anda bagikan ketika Anda terhubung ke VPN - sepertinya hampir pasti mesin Anda mengalami kesulitan dengan WINS / NETBIOS.

Tentukan server WINS dan uji lagi.

— Ben Lessani - Sonassi
sumber

Saya tidak tahu pasti bahwa ini adalah penyebab masalah saya, tetapi yang saya tahu adalah bahwa klien AD harus menggunakan server DNS yang digunakan untuk meng-host AD, dan ini bukan masalahnya. Karena masalah hanya muncul ketika saya membuat koneksi VPN, dan resolusi DNS saya menjadi kacau pada saat yang sama, sepertinya DNS adalah kandidat yang tepat. Apapun, saya tidak ingin menggunakan server DNS jauh ketika saya terhubung ke jaringan lain menggunakan VPN.

— Bryan

Apakah Anda mendefinisikan server WINS sesuai saran saya? Ini bukan khas Windows untuk menggunakan server DNS pada VPN kecuali jika penggunaannya didefinisikan atau "Gunakan remote gateway diatur", yang Anda katakan dinonaktifkan. Anda juga menggunakan IP statis pada terowongan VPN, jadi mengapa Anda mengatur entri DNS sama sekali? Hapus server DNS tersebut (192.168.0.16-17) atau atur server WINS.

— Ben Lessani - Sonassi

Tidak, saya belum mencobanya karena kami tidak memiliki server WINS untuk mengarahkan klien. Saya tidak yakin WINS akan membantu untuk jujur, jadi saya tidak tertarik untuk menginstal server WINS di jaringan kami karena mungkin membantu. Saya tentu akan mengingat ide itu, jadi terima kasih. IP ditugaskan oleh server VPN dan bersifat dinamis. Jika saya tidak menetapkan server DNS untuk koneksi VPN, itu ditentukan secara dinamis oleh server. Saya bahkan sudah membuat kode server DNS saya sendiri di properti koneksi VPN, namun masih menggunakan server DNS di situs jarak jauh.

— Bryan

Saya tidak perlu atau tidak ingin menggunakan server DNS jauh, pernah, saya selalu ingin resolusi DNS dilakukan pada server lokal, ini akan memperbaiki masalah saya, maka pertanyaan saya berfokus pada DNS. Saya mungkin dapat menggunakan aturan firewall untuk memblokir akses ke server DNS jauh, tetapi ini tidak memperbaiki masalah kesalahan konfigurasi yang mendasarinya.

— Bryan

1

penafsiran Anda tentang ini tidak benar. Alamat IP diberikan oleh server PPTP, yang sebenarnya tidak menggunakan DHCP. Server PPTP memiliki kumpulan yang dapat dialokasikan, tetapi ini bukan DHCP. Namun saya mendapatkan IP yang berbeda setiap kali terhubung. Selain itu, saya belum mencentang kotak untuk menggunakan gateway jauh, karena Anda dapat dengan jelas melihat dari tabel routing.

— Bryan