Sabit VPN IP: RADIUS Framed-IP-Address mi, havuz rezervasyonu mu

Bir VPN istemcisi için sabit iç adresi üç yer tutabilir ve bunlardan yalnızca biri sahip olmalıdır. RADIUS adresi bir Access-Accept içinde döndürebilir, ağ geçidi hesap için statik bir eşleme tutabilir ve istemci bağdaştırıcısı elle ayarlanabilir. İlk ikisi politikadır, üçüncüsü ise ağ geçidinin yok saymakta veya üzerine yazmakta serbest olduğu yerel bir tahmindir. İlk ikisi arasında seçim yapmak gerçek karardır ve bu, ağ erişim sunucusunun gerçekte ne uyguladığına bağlıdır.

Sabit bir adresin yaşayabileceği üç yer

Yanıt Framed-IP-Address taşıdığında ve ağ geçidi bu değeri oturuma uyguladığında adresin sahibi RADIUS’tur. Yönetici hesabı havuz içindeki statik bir adrese eşlediğinde ağ geçidi sahibidir. İstemci hiçbir şeye sahip değildir; bağdaştırıcısı elle girilmiş bir adres gösterse bile, çünkü sunucu iç adresi görüşme sırasında atar ve yerel ayar yalnızca sunucu hiçbir şey göndermediğinde önemlidir. Üçü de çalışan bir bağlantıda aynı görünür, bu yüzden çakışmalar geç ortaya çıkar. Fark yeniden bağlanmada, ikinci cihazda ve bir politika değişikliğinden sonra görülür.

İki sahip, kırılan yapılandırmadır. RADIUS yanıtı 172.28.4.77 atarken ağ geçidi 172.28.4.90 için statik bir eşleme tutuyorsa, satıcının kodu hangi değeri önce denetlerse o kazanır ve kaybeden bir günlük satırı olmadan atılır. Aynı hesap ikinci cihazda yinelenen bir adres alır ve belirti, atama çakışmasından çok yönlendirme arızası gibi okunur. İkinci mekanizmayı eklemeden önce sahibi belirleyin.

İstemci tarafındaki seçenek yalnızca dışlanabilsin diye anılmaya değer. Elle girilen bağdaştırıcı adresi işletim sisteminin sunabileceği bir tercihtir, rezervasyon değildir ve başka bir oturumun aynı adresi almasını engelleyemez.

RADIUS yanıtının vaat edebildiği ve edemediği şeyler

RFC 2865Framed-IP-Address’i kullanıcı için yapılandırılacak IPv4 adresi olarak tanımlar ve bu Access-Accept içinde yer alır. Access-Request içindeki aynı öznitelik, sunucunun yok sayabileceği bir ipucudur; bu, bir istemci veya ağ geçidi tercih edilen bir adres sunduğunda önemlidir. Protokolde ağ geçidini yanıta uymaya zorlayan hiçbir şey yoktur, çünkü yanıtı oturuma uygulayan bileşen ağ erişim sunucusudur.

Destek bir protokol değil, ürün sorunudur. Bazı ağ geçitleri çerçeveli adresleri varsayılan olarak uygular, bazıları bunu yapmadan önce grup düzeyinde bir anahtarın açılmasını gerektirir, bazıları ise özniteliği kabul eder ve uzaktan erişim oturumları için hiç kullanmaz. Tehlikeli olan son durumdur, çünkü muhasebe kaydı yanıtı gösterirken istemci havuz adresi alabilir. Davranışı, çalıştırdığınız tam ağ geçidi modeli ve belleniminde doğrulayın, kardeş bir ürünün belgelerinde değil.

Ağ geçidinin yok saydığı bir yanıt, hiç gönderilmemiş bir yanıtla tamamen aynı görünür. Access-Accept ile oturum adresini yan yana okumak, iki durumu ayırmanın tek yoludur.

Adresi zaten yönlendirdiğiniz havuzun içinde ayırın

Sabit adresi, ağ geçidinin zaten yönlendirdiği ve güvenlik duvarının zaten güvendiği havuz alt ağından seçin. Bu aralığın dışındaki bir adres, politika değişikliğini bir yönlendirme projesine dönüştürür ve VPN ayağa kalkar ama arkasında hiçbir şey yanıt veremez. Adres başına erişim kuralları varsa, sabit adresi aynı değişiklikte bunlara ekleyin.

İkinci eşzamanlı oturumun ne yapması gerektiğine karar verin. Bir adresi iki kez atamak cihaz yönetimi değildir ve ortaya çıkan çakışma her iki oturum için de kesintili bağlantı olarak görünür. Ya cihaz başına ayrı kimlikler verin, ya ayrı atamalar, ya da desteklenen bir denetimle eşzamanlılığı zorunlu kılın, örneğin Simultaneous-Use ile, eski oturum sona ermeden istemcinin asla yeniden bağlanmayacağını ummak yerine.

Dönüş yolları da atama kadar dikkat hak eder. Ağ geçidinin havuza bir yolu, iç yönlendiricilerin ağ geçidine dönüş yolu olmalıdır ve sabit adres ikisini de devralır. Bir istemci çalışırken diğerleri başarısız oluyorsa, bu genellikle havuz yolunun var olduğu ama ayrılmış adres için ana bilgisayar yolunun olmadığı anlamına gelir.

Rezervasyona güvenmeden önce yanıtı test edin

AAA tarafını ve oturum tarafını ayrı ayrı test edin, çünkü farklı nedenlerle başarısız olurlar. Yerel bir radtest ağ geçidini işe katmadan sunucunun hesap için ne döndürdüğünü gösterir, kullanıcılar dosyasındaki kayıt ise sunucunun neyle eşleşmesi gerektiğini gösterir. Ardından istemciyi yeniden bağlayın ve aldığı adresi yanıttaki öznitelikle karşılaştırın.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

Öznitelik olmadan gelen bir Access-Accept, sunucunun kaydı eşleştirmediği veya özniteliğin o kullanıcıya uygulanmadığı anlamına gelir. Öznitelikle gelen bir Access-Accept ve hâlâ havuz adresi alan bir istemci, ağ geçidinin onu yok saydığı anlamına gelir. Access-Reject sizi kimlik bilgilerine veya grup ilkesine geri gönderir ve bu sonuçların hiçbiri istemci bağdaştırıcısı düzenlenerek ayıklanmamalıdır.

Denetimi yeniden bağlanmadan sonra ve başka bir cihazdan ikinci oturum açmadan sonra yineleyin. Yalnızca ilk oturum için dayanan bir rezervasyon, olmayı bekleyen bir havuz çakışmasıdır ve onu şimdi bulmak bir denetim sırasında bulmaktan daha ucuzdur.

Tek bir sahip seçin ve yazın

Ağ geçidi çerçeveli adresleri güvenilir biçimde uyguluyorsa, atamanın sahibi RADIUS olsun ve aynı hesap için her türlü statik eşlemeyi kaldırın. Uygulamıyorsa, sahibi ağ geçidi olsun ve özniteliği yanıttan çıkarın, böylece iki kaynak çelişemez. Her biri neredeyse çalışıyor diye ikisini de tutmak, gelecekteki bir oturumun yanlış adresle ve belirgin bir neden olmadan gerçekleşmesini garanti eder.

Seçilen sahibi, ayrılmış adresi ve geldiği havuzu hesap kaydına yazın. Bir cihaz ekleyecek sonraki kişi, ikisinden birini değiştirmeden önce adresin AAA politikası mı yoksa ağ geçidi eşlemesi mi olduğunu görebilir.