Klien VPN RRAS butuh kumpulan IPv4 sendiri dan jalur pulang

Klien VPN terhubung dan menerima alamat, tetapi host LAN yang dibutuhkannya tetap tidak bisa menjawabnya. Di Windows Routing and Remote Access, alamat dalam untuk klien VPN berasal dari kumpulan yang dikonfigurasi terpisah dari adaptor LAN server, dan sisi LAN membutuhkan rute balik ke kumpulan itu. Dua perubahan, bukan satu, dan keduanya gagal dengan cara berbeda. Kerjakan berurutan agar rencana alamat dan jalur pulang terbukti sebelum rentang lama dipensiunkan.

Cadangkan rentang sebelum membuka konsol

Pilih prefiks yang tidak tumpang tindih dengan LAN, rentang VPN lain, atau apa pun yang dirutekan ke situs. /24 adalah ukuran yang nyaman untuk uji, dan bagian pertama yang dapat dipakai bisa diberikan ke klien sementara sisanya tetap bebas untuk pertumbuhan. Tuliskan beserta tujuan dan pemiliknya sebelum Anda mengetikkannya di konsol. Sisakan ruang di kedua ujung blok agar pemisahan nanti tidak memaksa penomoran ulang.

Rencana alamat yang hanya hidup di konsol berjarak satu pembangunan ulang dari tabrakan. Rencana itu juga cenderung tumbuh: seseorang menambahkan rentang kedua nanti dan tidak ada yang memeriksa yang pertama. Simpan rencana di samping dokumentasi server, bukan di utas obrolan.

Adaptor LAN server tidak mendefinisikan kumpulan ini. Mengubah pendengar publik atau menambahkan adaptor ke LAN melakukan hal yang sama sekali berbeda. Itu sebabnya klien bisa terhubung dan tetap menerima alamat dari tempat yang salah. Kumpulan itu hidup di properti IPv4 server, bukan di daftar adaptor.

Mengganti metode bukan menambah rentang

RRAS punya metode penetapan dan sekumpulan rentang. Beralih dari DHCP ke kumpulan statis adalah perubahan metode. Menambahkan blok lain saat kumpulan statis sudah aktif adalah perubahan rentang.

Pratinjau kedua operasi sebelum menjalankan salah satunya, dan baca mana yang cocok dengan keadaan server saat ini:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

cmdlet kedua gagal atau menghasilkan kumpulan yang tidak terpakai jika server masih pada penetapan DHCP. Yang pertama mengganti metode alih-alih memperluas kumpulan yang ada. Tidak ada pratinjau yang menerapkan apa pun, jadi jalankan yang cocok, lalu konfirmasi kumpulan hasilnya di konsol. Jika Anda tidak yakin server dalam keadaan mana, baca metode penetapan di halaman properti IPv4 dan daftarkan rentang yang dikonfigurasi:

Get-VpnIPAddressRange

Metode DHCP dengan daftar rentang kosong berarti pratinjau pertama berlaku. Kumpulan alamat statis dengan rentang yang sudah ada berarti yang kedua berlaku.

Perhitungkan mulai ulang layanan yang mungkin diperlukan pengaturan ini, dan jangan menganggap klien yang terhubung langsung dinomori ulang. Klien yang mempertahankan alamat lamanya sampai terhubung kembali berperilaku normal. Rencanakan perubahan untuk jendela saat koneksi ulang dapat diterima.

LAN butuh rute balik

Misalkan LAN adalah 10.60.0.0/24 dan server RRAS adalah 10.60.0.10 di dalamnya. Host di LAN itu yang menjawab klien di 10.250.50.0/24 membutuhkan jalur ke kumpulan melalui server RRAS. Tanpa jalur itu permintaan tiba dan jawabannya mati.

Jika gateway default host adalah router lain, router itu membutuhkan rute balik untuk prefiks VPN. Rute statis di server RRAS tidak membantu di sini; jalur pulang harus ada di perangkat yang memiliki gateway LAN, jadi tambahkan ke tabel perutean atau ke proses perutean dinamis, sesuai yang digunakan situs.

Periksa juga firewall host dan setiap aturan akses jaringan terhadap rentang sumber baru. Aturan yang ditulis untuk rentang klien lama menolak yang baru meskipun penetapan berhasil. Rute klien menuju LAN dan resolusi DNS adalah persyaratan terpisah, dan keduanya bisa gagal saat terowongan tampak sehat. Uji masing-masing sendiri.

Buktikan kumpulan baru pada satu perangkat sebelum memensiunkan yang lama

Ambil satu otorisasi yang Anda kendalikan, hubungkan ulang, dan baca alamat kumpulan yang diterima klien. Satu angka itu memisahkan penetapan dari perutean. Lalu jalankan aplikasi bernama, amati lalu lintas pulang, dan coba tujuan yang seharusnya tetap ditolak. Tiga pengamatan, tiga mode kegagalan berbeda.

Resolusi nama layak mendapat ujinya sendiri: akses lewat IP bisa berhasil sementara DNS klien masih menunjuk ke resolver yang tidak dapat dijangkau. Server DNS di LAN hanya dapat dijangkau jika klien punya rute ke sana dan server menerima kueri dari rentang baru. Keduanya sering terlewat saat kumpulan berpindah.

Pensiunkan rentang lama dan pengecualiannya hanya setelah memperhitungkan sesi aktif dan proses pemeliharaan. Klien terhubung dengan alamat baru membuktikan penetapan, bukan kebijakan akses. Simpan rentang lama terdokumentasi sampai sesi terakhir yang memakainya berakhir.

Periksa hasilnya dengan tiga pengamatan

Penerimaan membutuhkan tiga fakta: klien punya alamat dari kumpulan baru, host LAN dapat menjangkaunya dan mendapat jawaban, dan tujuan yang ditolak tetap ditolak. Masing-masing punya pemeriksaan sendiri, jadi kegagalan menunjuk ke penetapan, perutean, atau kebijakan. Jalankan dalam urutan itu.

Dari klien, pastikan alamat dan rute ke satu host LAN:

ipconfig | findstr /i "IPv4"
route print -4

Dari host LAN, pastikan jalur jawaban dan kebijakan dalam satu langkah. Jika ping gagal tetapi aplikasi berfungsi, bagian yang hilang kemungkinan aturan ICMP, bukan rute. Jika keduanya gagal, baca rute di host sebelum menyunting VPN. Catat ketiga hasil di tiket perubahan agar orang berikutnya mulai dari bukti.