RRAS VPN istemcilerinin kendi IPv4 havuzuna ve dönüş yoluna ihtiyacı var

VPN istemcisi bağlanır ve bir adres alır, ancak ihtiyaç duyduğu LAN ana makinesi ona hâlâ yanıt veremez. Windows Routing and Remote Access'te VPN istemcilerinin iç adresi, sunucunun LAN bağdaştırıcısından ayrı yapılandırılan bir havuzdan gelir ve LAN tarafının bu havuza dönüş yoluna ihtiyacı vardır. İki değişiklik, bir değil, ve farklı şekillerde başarısız olurlar. Eski aralıklar kullanımdan kaldırılmadan önce adres planının ve dönüş yolunun kanıtlanması için bunları sırayla ele alın.

Konsolu açmadan önce aralığı ayırın

LAN, diğer VPN aralıkları veya siteye yönlendirilen herhangi bir şeyle çakışmayan bir önek seçin. /24 bir test için uygun boyuttur ve ilk kullanılabilir bölüm istemcilere verilebilirken geri kalanı büyüme için serbest kalır. Konsola yazmadan önce amacı ve sahibiyle birlikte kaydedin. Sonraki bir bölünmenin yeniden numaralandırmayı zorlamaması için bloğun iki ucunda da yer bırakın.

Yalnızca bir konsolda yaşayan adres planı, bir çakışmadan bir yeniden kurulum uzaktadır. Ayrıca büyüme eğilimindedir: biri sonra ikinci bir aralık ekler ve kimse ilkini denetlemez. Planı sohbet dizisinde değil, sunucu belgelerinin yanında tutun.

Sunucunun LAN bağdaştırıcısı bu havuzu tanımlamaz. Ortak dinleyiciyi değiştirmek veya LAN'a bir bağdaştırıcı eklemek tamamen başka bir şey yapar. Bu yüzden istemciler bağlanabilir ve yine de yanlış yerden adres alabilir. Havuz sunucunun IPv4 özelliklerinde yaşar, bağdaştırıcı listesinde değil.

Yöntemi değiştirmek aralık eklemek değildir

RRAS'in bir atama yöntemi ve bir aralık kümesi vardır. DHCP'den statik havuza geçmek bir yöntem değişikliğidir. Statik havuz zaten etkinken başka bir blok eklemek bir aralık değişikliğidir.

Herhangi birini çalıştırmadan önce iki işlemi de önizleyin ve hangisinin sunucunun mevcut durumuna uyduğunu okuyun:

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

Sunucu hâlâ DHCP atamasındaysa ikinci cmdlet başarısız olur veya kullanılamaz bir havuz üretir. Birincisi mevcut havuzu genişletmek yerine yöntemi değiştirir. Hiçbir önizleme bir şey uygulamaz, bu yüzden uygun olanı çalıştırın ve ardından ortaya çıkan havuzu konsolda doğrulayın. Sunucunun hangi durumda olduğundan emin değilseniz, IPv4 özellikleri sayfasındaki atama yöntemini okuyun ve yapılandırılmış aralıkları listeleyin:

Get-VpnIPAddressRange

Boş aralık listesi olan DHCP yöntemi, ilk önizlemenin geçerli olduğu anlamına gelir. Var olan aralığa sahip statik adres havuzu, ikincisinin geçerli olduğu anlamına gelir.

Ayarın gerektirebileceği hizmet yeniden başlatmasını hesaba katın ve bağlı istemcilerin hemen yeniden numaralandırılacağını varsaymayın. Eski adresini yeniden bağlanana kadar koruyan istemci normal davranır. Değişikliği yeniden bağlanmanın kabul edilebilir olduğu bir pencere için planlayın.

LAN'ın dönüş yoluna ihtiyacı var

LAN'ın 10.60.0.0/24 olduğunu ve RRAS sunucusunun üzerinde 10.60.0.10 olduğunu varsayalım. O LAN'daki 10.250.50.0/24 içindeki bir istemciye yanıt veren ana makinenin RRAS sunucusu üzerinden havuza bir yola ihtiyacı vardır. Bu yol olmadan istek ulaşır ve yanıt ölür.

Ana makinenin varsayılan ağ geçidi başka bir yönlendiriciyse, o yönlendiricinin VPN öneki için dönüş yoluna ihtiyacı vardır. RRAS sunucusundaki statik bir yol burada yardımcı olmaz; dönüş yolu LAN ağ geçidine sahip cihazda bulunmalıdır, bu yüzden onu yönlendirme tablosuna veya sitenin kullandığına göre dinamik yönlendirme sürecine ekleyin.

Ana makinenin güvenlik duvarını ve tüm ağ erişim kurallarını yeni kaynak aralığına karşı da denetleyin. Eski istemci aralığı için yazılmış kurallar, atama başarılı olsa bile yenisini reddeder. İstemcinin LAN'a yönelik yolları ve DNS çözümlemesi ayrı gereksinimlerdir ve tünel sağlıklı görünürken ikisi de başarısız olabilir. Her birini ayrı ayrı test edin.

Eskiyi kullanımdan kaldırmadan önce yeni havuzu tek bir cihazda kanıtlayın

Kontrol ettiğiniz bir yetkilendirme alın, yeniden bağlanın ve istemcinin aldığı havuz adresini okuyun. O tek sayı atamayı yönlendirmeden ayırır. Ardından adlandırılmış bir uygulamayı çalıştırın, dönüş trafiğini izleyin ve reddedilmiş kalması gereken bir hedefi deneyin. Üç gözlem, üç farklı başarısızlık biçimi.

Ad çözümlemesi kendi testini hak eder: IP ile erişim çalışabilirken istemcinin DNS'i hâlâ ulaşamadığı bir çözümleyiciyi gösterebilir. LAN'daki bir DNS sunucusuna yalnızca istemcinin oraya yolu varsa ve sunucu yeni aralıktan gelen sorguları kabul ediyorsa ulaşılabilir. Havuz taşındığında ikisi de sık görülen eksiklerdir.

Eski aralıkları ve istisnalarını ancak etkin oturumları ve bakım sürecini hesaba kattıktan sonra kullanımdan kaldırın. Yeni adresle bağlı bir istemci atamayı kanıtlar, erişim ilkesini değil. Eski aralığı onu kullanan son oturum sona erene kadar belgelenmiş tutun.

Sonucu üç gözlemle denetleyin

Kabul üç olgu gerektirir: istemcinin yeni havuzdan bir adresi var, bir LAN ana makinesi ona ulaşıp yanıt alabiliyor ve reddedilen bir hedef reddedilmiş kalıyor. Her birinin kendi denetimi vardır, bu yüzden başarısızlık atamaya, yönlendirmeye veya ilkeye işaret eder. Bunları bu sırayla çalıştırın.

İstemciden adresi ve bir LAN ana makinesine giden yolu doğrulayın:

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

LAN ana makinesinden dönüş yolunu ve ilkeyi tek geçişte doğrulayın. Ping başarısız olur ama uygulama çalışırsa, eksik parça büyük olasılıkla yol değil bir ICMP kuralıdır. İkisi de başarısız olursa, VPN'i düzenlemeden önce ana makinedeki yolu okuyun. Üç sonucu değişiklik kaydına yazın ki sonraki kişi kanıtla başlasın.