Klien VPN RRAS perlukan kolam IPv4 sendiri dan laluan pulang

Klien VPN bersambung dan menerima alamat, tetapi hos LAN yang diperlukannya masih tidak dapat menjawabnya. Dalam Windows Routing and Remote Access, alamat dalaman klien VPN datang daripada kolam yang dikonfigurasikan berasingan daripada penyesuai LAN pelayan, dan bahagian LAN memerlukan laluan pulang ke kolam itu. Dua perubahan, bukan satu, dan kedua-duanya gagal dengan cara berbeza. Lakukan mengikut urutan supaya pelan alamat dan laluan pulang terbukti sebelum julat lama dihentikan.

Tempah julat sebelum membuka konsol

Pilih awalan yang tidak bertindih dengan LAN, julat VPN lain atau apa-apa yang dihalakan ke tapak. /24 ialah saiz yang sesuai untuk ujian, dan bahagian pertama yang boleh digunakan boleh diberikan kepada klien sementara selebihnya kekal bebas untuk pertumbuhan. Catatkannya bersama tujuan dan pemiliknya sebelum anda menaipnya dalam konsol. Tinggalkan ruang di kedua-dua hujung blok supaya pembahagian kemudian tidak memaksa penomboran semula.

Pelan alamat yang hanya hidup dalam konsol berada satu pembinaan semula daripada perlanggaran. Ia juga cenderung membesar: seseorang menambah julat kedua kemudian dan tiada siapa yang memeriksa yang pertama. Simpan pelan di sebelah dokumentasi pelayan, bukan dalam utas sembang.

Penyesuai LAN pelayan tidak menentukan kolam ini. Menukar pendengar awam atau menambah penyesuai ke LAN melakukan sesuatu yang sama sekali berbeza. Itulah sebabnya klien boleh bersambung dan masih menerima alamat dari tempat yang salah. Kolam itu hidup dalam sifat IPv4 pelayan, bukan dalam senarai penyesuai.

Menukar kaedah bukan menambah julat

RRAS mempunyai kaedah penetapan dan satu set julat. Beralih daripada DHCP ke kolam statik ialah perubahan kaedah. Menambah blok lain semasa kolam statik sudah aktif ialah perubahan julat.

Pratonton kedua-dua operasi sebelum menjalankan mana-mana satu, dan baca yang mana sepadan dengan keadaan pelayan semasa:

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 kolam yang tidak boleh digunakan jika pelayan masih pada penetapan DHCP. Yang pertama menggantikan kaedah dan bukan melanjutkan kolam sedia ada. Tiada pratonton menggunakan apa-apa, jadi jalankan yang sepadan, kemudian sahkan kolam yang terhasil dalam konsol. Jika anda tidak pasti keadaan pelayan, baca kaedah penetapan pada halaman sifat IPv4 dan senaraikan julat yang dikonfigurasikan:

Get-VpnIPAddressRange

Kaedah DHCP dengan senarai julat kosong bermaksud pratonton pertama terpakai. Kolam alamat statik dengan julat sedia ada bermaksud yang kedua terpakai.

Perhitungkan permulaan semula perkhidmatan yang mungkin diperlukan oleh tetapan itu, dan jangan andaikan klien yang bersambung dinomborkan semula serta-merta. Klien yang menyimpan alamat lamanya sehingga bersambung semula berkelakuan normal. Rancang perubahan itu untuk tetingkap yang membenarkan sambungan semula.

LAN memerlukan laluan pulang

Katakan LAN ialah 10.60.0.0/24 dan pelayan RRAS ialah 10.60.0.10 di atasnya. Hos pada LAN itu yang membalas klien dalam 10.250.50.0/24 memerlukan laluan ke kolam melalui pelayan RRAS. Tanpa laluan itu permintaan tiba dan balasannya mati.

Jika get laluan lalai hos ialah penghala lain, penghala itu memerlukan laluan pulang untuk awalan VPN. Laluan statik pada pelayan RRAS tidak membantu di sini; laluan pulang mesti wujud pada peranti yang memiliki get laluan LAN, jadi tambahkannya pada jadual penghalaan atau pada proses penghalaan dinamik, mengikut apa yang digunakan oleh tapak.

Periksa juga tembok api hos dan mana-mana peraturan akses rangkaian terhadap julat sumber baharu. Peraturan yang ditulis untuk julat klien lama menolak yang baharu walaupun penetapan berjaya. Laluan klien ke arah LAN dan penyelesaian DNS ialah keperluan berasingan, dan kedua-duanya boleh gagal semasa terowong kelihatan sihat. Uji setiap satu secara berasingan.

Buktikan kolam baharu pada satu peranti sebelum menghentikan yang lama

Ambil satu kebenaran yang anda kawal, sambung semula dan baca alamat kolam yang diterima klien. Satu nombor itulah memisahkan penetapan daripada penghalaan. Kemudian jalankan aplikasi bernama, perhatikan trafik pulang dan cuba destinasi yang sepatutnya kekal ditolak. Tiga pemerhatian, tiga mod kegagalan berbeza.

Penyelesaian nama wajar diuji sendiri: akses melalui IP boleh berfungsi sementara DNS klien masih menunjuk kepada penyelesai yang tidak dapat dicapainya. Pelayan DNS pada LAN hanya boleh dicapai jika klien mempunyai laluan ke sana dan pelayan menerima pertanyaan daripada julat baharu. Kedua-duanya ialah kelewatan biasa apabila kolam berpindah.

Hentikan julat lama dan pengecualiannya hanya selepas mengambil kira sesi aktif dan proses penyelenggaraan. Klien bersambung dengan alamat baharu membuktikan penetapan, bukan dasar akses. Simpan julat lama didokumenkan sehingga sesi terakhir yang menggunakannya tamat tempoh.

Periksa hasilnya dengan tiga pemerhatian

Penerimaan memerlukan tiga fakta: klien mempunyai alamat daripada kolam baharu, hos LAN dapat mencapainya dan mendapat balasan, dan destinasi yang ditolak masih ditolak. Setiap satu mempunyai pemeriksaan sendiri, jadi kegagalan menunjuk kepada penetapan, penghalaan atau dasar. Jalankan mengikut urutan itu.

Daripada klien, sahkan alamat dan laluan ke satu hos LAN:

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

Daripada hos LAN, sahkan laluan balasan dan dasar dalam satu langkah. Jika ping gagal tetapi aplikasi berfungsi, bahagian yang hilang mungkin peraturan ICMP dan bukan laluan. Jika kedua-duanya gagal, baca laluan pada hos sebelum menyunting VPN. Catat ketiga-tiga hasil dalam tiket perubahan supaya orang seterusnya bermula dengan bukti.