VPN - VPN tüneli üzerinden bir Active Directory [AD] Sunucusu yapılandırma

Başka sorularınız var mı? Bir talep gönder

Önemli Uyarı:
Değerli müşterimiz, makaleleri yerel dilinizde sunmak için makine çevirisi kullandığımızı lütfen unutmayın. Tüm metin doğru şekilde çevrilmemiş olabilir. Çevrilmiş versiyondaki bilgilerin doğruluğu konusunda sorularınız veya tutarsızlıklarınız varsa, lütfen orijinal makaleyi buradan inceleyin:Orijinal Versiyon

Bu makale, USG FLEX/ATP VPN kimlik doğrulama yöntemini kullanarak bir L2TP VPN tüneli aracılığıyla bir Active Directory (AD) sunucusunun nasıl yapılandırılacağına ilişkin ayrıntılı bir genel bakış sağlar. Ayrıca, burada sunulan kılavuz IPsec IKEv2 ve IKEv1 VPN yapılandırmaları için de geçerlidir.

VPN tünelleri, küresel kurumsal ağlar veya yan konumlarla birbirine bağlı ana siteler gibi doğal olarak genişleyen ağlar kurarken kritik bir bileşendir.

Kurumsal ağların temel bir özelliği, kullanıcıların kimliklerini bir sunucuya doğrulama, böylece güvenilirliği gösterme ve dahili kaynaklara erişim elde etme sürecidir. Bu eğitim, bir VPN tüneli aracılığıyla bir kimlik doğrulama sunucusuna kimlik doğrulamayı yapılandırmak için gerekli araçlarla sizi donatmayı amaçlamaktadır.
mceclip2.png

İki güvenlik duvarı Siteden Siteye VPN ile bağlıdır ve Ana Site A'da LAN içinde bir RADIUS-Sunucusu vardır. B Sitesinde, A Sitesindeki RADIUS sunucusuna doğru kimlik doğrulaması yapmak isteyen birkaç istemci olabilir. B Sitesinde, ya A Sitesindeki RADIUS Sunucusuna doğru bağlantıya ihtiyaç duyan yerel istemciler ya da A Sitesinin RADIUS'una doğru kimlik doğrulaması gerektiren L2TP VPN İstemcileri buluruz.

Burada, VPN İstemcisi ile B Sitesindeki LAN İstemcisi arasında önemli bir ayrım yapmak zorundayız - B Sitesindeki İstemcinin A Sitesinin RADIUS'una karşı herhangi bir sorun olmadan kimlik doğrulaması yapabilmesi çok muhtemelken, L2TP VPN istemcileri büyük olasılıkla bunu yapamayacaktır. Bunun nedeni nedir?

Siteden Siteye VPN'ler bir Yerel Politika ve bir Uzak Politika ile kurulur. Bu politikalar, tünel oluşturulduğunda hangi ağ yollarının oluşturulacağını, yani hangi ağların "birbirleriyle konuşmasına" izin verileceğini belirler. Bu durumda, 192.168.10.0/24 ve 192.168.20.0/24 arasındaki yönlendirmenin iyi olduğunu varsayıyoruz. Doğal olarak B Sitesindeki yerel alt ağlardan farklı bir alt ağ olması gereken L2TP VPN'in, Yerel veya Uzak İlkesine dahil edilmediği için A Sitesine doğru iletişim kurmasına izin verilmez.

Yani, eğer ek politika rotaları eklemezsek. Bu tür rotaların yardımıyla, L2TP VPN'den gelen herhangi bir kimlik doğrulama girişimini Site A'daki bir hedefe doğru zorlayabiliriz. Öncelikle, Site B'deki kimlik doğrulamalarının Site A'nın RADIUS'una yönlendirileceğini tanımlamamız gerekir.

AAA Sunucusunu Yapılandırma

Yapılandırma > Nesne > AAA Sunucusu

ve 192.168.10.100 IP'sine yönelik bir kimlik doğrulama nesnesi ayarlayın:

mceclip0.png

AD kimlik doğrulamanızı test edin

Yapılandırma -> Nesne -> AAA Sunucusu

Yapılandırma doğrulamasını test etmeden önce yapılandırmanızı kaydettiğinizden emin olun.

İyi sonuç Kötü sonuç

Auth'u yapılandırın. Yöntem

Bu AAA Server-Object şimdi bir kimlik doğrulama yöntemiyle birleştirilmeli ve bu da VPN'imiz için ana kimlik doğrulama olarak ayarlanmalıdır. İlk olarak, menüye gidin

Yapılandırma > Nesne > Auth. Yöntem

'yi seçin ve yeni oluşturulan AAA Sunucusunu varsayılan Auth. Yöntem:

mceclip1.png

Güvenlik Duvarının AD Sunucusuna Katılmasını Sağlayın

Ardından USG'nin AD sunucusunun etki alanı adıyla AD etki alanına katılması gerekir

Yapılandırma -> Sistem -> Ana Bilgisayar Adı bölümüne gidin

Realm, reklam sunucusunun Alan adıdır ve NetBIOS adı etki alanıdır.

Güvenlik duvarını AD sunucusuna yönlendirmek için, AD sunucusunun IP adresi üzerinden AD sunucusunu başarılı bir şekilde bulmak üzere bir DNS kaydı oluşturmamız gerekir:

VPN'i yapılandırma

IKEv2 aracılığıyla

Yapılandırma -> VPN -> IPSec VPN -> VPN Ağ Geçidi - Ekle/Düzenle

"Gelişmiş Ayarları Göster "e tıklayın ve "Genişletilmiş Kimlik Doğrulama Protokolü "nü etkinleştirin ve Sunucu modunu seçin.

Ardından AAA Yöntemini (Auth. Method) ve İzin verilen kullanıcıyı seçin

L2TP aracılığıyla

Bundan sonra, bu Auth. üzerinden L2TP VPN aracılığıyla kullanılacak yöntem

Yapılandırma > VPN > IPSec VPN üzerinden L2TP

mceclip2.png

(Lütfen IP Adres Havuzunun yukarıda çizilen topoloji ile uyuşmadığını unutmayın, çünkü bu sadece L2TP-Tünelinin nasıl kurulacağına dair bir örnektir)

Artık L2TP VPN, Site A'daki RADIUS'a doğru yönlendirilmesi gereken bir kimlik doğrulama ile kurulduğuna göre, politika rotaları oluşturmalıyız:

mceclip3.png

İlk politika rotası, 192.168.10.100 IP'sine doğru hareket etmek isteyen herhangi bir kaynaktan gelen her şeyi Site A'ya giden tünele itecektir - yani aynı zamanda L2TP VPN'imizden gelen kimlik doğrulama girişimi. İkinci politika rotası, L2TP VPN alt ağına yönelik her şeyi L2TP VPN'e geri itecektir.

Diğer sitede, şimdi bunu Site B LAN'ından farklı alt ağlardan gelen her şeyi (L2TP VPN Alt Ağımızın girişimi gibi) Site B'ye doğru tünele geri itecek ve bu sitede ayarladığımız ilke rotamızı tetikleyecek ilgili bir kural aracılığıyla tamamlamamız yeterlidir.

Bu basit kılavuzu izleyerek, artık istemcilerinizin kimlik doğrulamasını başka bir uzak VPN konumundaki bir RADIUS'a doğru yapabilmeniz gerekir.

AD Etki Alanı için DNS Yönlendirmeyi Yapılandırma (Önerilen)

Doğru AD adı çözümlemesini sağlamak için, yerel DNS girişine ek olarak DNS iletmeyi yapılandırın:

  • Yapılandırma → Sistem → DNS → Etki Alanı Bölgesi İleticisi'ne gidin, AD etki alanınızı ekleyin (örn. company.local) ve AD DNS sunucusunu iletici olarak ayarlayın.

  • VPN Bağlantısı → İstemci Ayarları'nda, AD DNS sunucusunu (veya yönlendirme etkinse güvenlik duvarının LAN IP'sini) İlk DNS Sunucusu olarak atayın.

  • (İsteğe bağlı) DNS sorgularının VPN üzerinden zorlanması gerekiyorsa bir ilke yolu ekleyin.

Şununla doğrulayın: nslookup dc1.company.local.

Sorun Giderme & Sonucunuzu Test Edin

Şuraya gidin

Monitör -> Ağ Durumu -> Oturum Açan Kullanıcılar

Şuraya gidin

Monitör -> VPN Monitör -> IPSec

Sorun Giderme

Güvenlik duvarının Web Konsoluna gidin veya SSH aracılığıyla güvenlik duvarına bağlanın ve şu komutu çalıştırın

debug domain-auth test profile-name [reklam profili adı] username [kullanıcı adı] password [parola]

Reklam profili adını Active Directory "AD Sunucusu Özeti" Adı ile değiştirin ve MSCHAP aracılığıyla Etki Alanı Kimlik Doğrulamasının kullanıcı adını ve parolasını kullanın.

Daha fazla makaleyi burada bulabilirsiniz:

AD (active directory) kullanıcı kimlik doğrulama kontrolü

USG/ATP/VPN ile bir Active Directory Etki Alanına nasıl katılınır

Active Directory Kullanıcıları ile İki Faktörlü Kimlik Doğrulama Nasıl Yapılır

Bu bölümdeki makaleler

Bu makale yardımcı oldu mu?
3 kişi içerisinden 2 kişi bunun yardımcı olduğunu düşündü
Paylaş

Yorumlar

0 yorum

Yorum yazmak için lütfen oturum açın: oturum aç.