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 /all
ketika 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:
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.32
diikuti 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\share
alih-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.
route print
(dari koneksi vpn) ke posting?Jawaban:
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.
sumber
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.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!
sumber
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 ...
sumber
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:
Anda HARUS melakukan ini setiap kali terhubung ke Jaringan VPN.
sumber
nslookup
masih menggunakan server DNS jarak jauh, ditambahipconfig
lagi 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.ipconfig
output, dan ketika saya salah, saya mendapat kesalahanThe 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.ipconfig /all
? Saya pikir bagaimanapun entri host harus memperbaiki paling mudah untuk Anda.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.
sumber
split tunnelling
jujur, 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.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.com
hanya domain perusahaan yang digunakan untuk bekerja yang terdaftar displit-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-protocol
perintah 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
ipv6
pada 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 :)
sumber
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 !!!!
sumber
Saya cukup menghapus opsi ini dari konfigurasi VPN klien
setenv opt block-outside-dns
Itu menyelesaikan masalah
sumber
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).
sumber
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.
sumber