Palo Alto Captive Portal ve RADIUS Yapılandırması

Güncelleme: Temmuz 2026 | Test edilen sürüm: PAN-OS 11.1.13 (PA-445)

Bu Rehberde Neler Var?

Bu rehber iki büyük bölümden oluşuyor. İlk bölümde Palo Alto güvenlik duvarında RADIUS kimlik doğrulamasının nasıl yapılandırıldığını, ikinci bölümde ise Captive Portal (PAN-OS 9.1 ve sonrasında resmi adıyla Authentication Portal) kurulumunun tüm adımlarını ekran görüntüleriyle bulacaksınız. Sonda ise gerçek bir laboratuvar ortamında karşılaşılmış sorunların çözümlerini içeren detaylı bir sorun giderme bölümü yer alıyor.

Tüm ekran görüntüleri PAN-OS 11.1.13 sürümü çalıştıran bir PA-445 laboratuvar cihazından alınmıştır. Rehberde geçen IP adresleri, arabirim isimleri, sertifika adları ve kullanıcı adları tamamen örnek niteliğindedir; kendi ortamınıza uyarlamanız gerekir.

Captive Portal (Authentication Portal) Nedir ve Nasıl Çalışır?

Captive Portal, güvenlik duvarının henüz kimliği bilinmeyen kullanıcıları bir web formuna yönlendirerek kimlik doğrulaması yaptırdığı mekanizmadır. Palo Alto mimarisinde bu özellik User-ID alt yapısının bir parçasıdır: kullanıcı giriş yaptığında güvenlik duvarı IP adresi ile kullanıcı adı arasında bir eşleme (IP-to-user mapping) oluşturur ve bu eşlemeyi güvenlik politikalarında kullanır.

Akış şöyle işler: misafir kullanıcı bir web sitesine gitmek ister, trafik Authentication Policy kuralıyla eşleşir, güvenlik duvarı istemciyi kendi arabirimi üzerindeki portal adresine yönlendirir, kullanıcı kimlik bilgilerini girer, başarılı doğrulamadan sonra güvenlik duvarı IP-kullanıcı eşlemesini kaydeder ve trafik artık Security Policy tarafında değerlendirilir. Burada çok kritik bir ayrıntı var: Authentication Policy, Security Policy’den ÖNCE değerlendirilir. Yani kullanıcı henüz kimlik doğrulaması yapmamış olsa bile yönlendirme gerçekleşir.

PAN-OS iki mod sunar. Redirect modunda güvenlik duvarı istemciyi HTTP 302 ile kendi Layer 3 arabirimine yönlendirir; oturum çerezi (session cookie), rol tabanlı zaman aşımı ve Kerberos SSO gibi özellikler bu modda kullanılabilir. Transparent modunda ise güvenlik duvarı hedef sunucuyu taklit ederek doğrudan kimlik doğrulama isteminde bulunur, ancak tarayıcıda sertifika uyarıları kaçınılmazdır. Bu rehberde önerilen ve uygulanan mod Redirect’tir.

Laboratuvar Topolojisi ve Ön Koşullar

Rehber boyunca kullanılan örnek topoloji şöyledir. Dış bacağımız ethernet1/1 arabirimi ve untrust bölgesi; iç yönetim bacağımız ethernet1/2 arabirimi, 10.254.253.244/24 adresi ve trust bölgesi. Misafir ağı ise ethernet1/2 üzerinde VLAN 71 etiketiyle oluşturulmuş ethernet1/2.71 alt arabirimi, 172.16.1.1/24 adresi ve Guest bölgesidir. Misafir istemciler güvenlik duvarının DHCP sunucusundan adres alır ve internete çıkış kaynak NAT ile yapılır.

Başlamadan önce şunların hazır olması gerekir: Layer 3 modunda çalışan bir arabirim, kendi güvenlik bölgesi, çalışan bir varsayılan rota, misafir ağı için DNS erişimi ve yönetici arayüzüne (Web UI) erişim yetkisi. RADIUS kullanacaksanız ayrıca güvenlik duvarının erişebildiği bir RADIUS sunucusu ve bu sunucuda tanımlanmış bir istemci (NAS) kaydı gerekir.

BÖLÜM 1: Palo Alto RADIUS Yapılandırması Nasıl Yapılır?

Palo Alto’da RADIUS entegrasyonu iki katmandan oluşur. Önce RADIUS sunucusunun adresini, portunu, paylaşılan anahtarını ve protokolünü tutan bir RADIUS Server Profile oluşturursunuz. Ardından bu profili kullanan bir Authentication Profile tanımlar ve bu profili Captive Portal, GlobalProtect veya yönetici girişi gibi tüketicilere atarsınız.

Adım 1.1 - RADIUS Sunucu Profili Oluşturma

Device sekmesine geçin ve sol menüden Server Profiles altındaki RADIUS başlığını seçin. Bu ekran cihazda tanımlı tüm RADIUS sunucu profillerini, sunucu adreslerini ve seçili protokolü özet halinde gösterir. Yeni bir profil eklemek için alttaki Add düğmesini kullanırsınız.

Görsel 1: Device > Server Profiles > RADIUS listesi

Add düğmesine bastığınızda RADIUS Server Profile penceresi açılır. Profile Name alanına anlamlı bir ad verin. Administrator Use Only kutusunu yalnızca bu profil sadece güvenlik duvarı yönetici girişlerinde kullanılacaksa işaretleyin; Captive Portal için kullanacaksanız boş bırakmalısınız. Timeout değeri sunucudan yanıt beklenecek saniye, Retries ise başarısız denemede kaç kez tekrar deneneceğini belirler; laboratuvarda 3 ve 3 değerleri yeterlidir.

Servers tablosunda Add ile bir satır ekleyip Name alanına sunucu için bir etiket, RADIUS Server alanına sunucunun IP adresini veya FQDN’ini, Secret alanına RADIUS sunucusunda tanımladığınız paylaşılan anahtarı ve Port alanına kimlik doğrulama portunu yazın. Standart RADIUS kimlik doğrulama portu 1812’dir; eski cihazlarda 1645 kullanılabilir. Paylaşılan anahtar arayüzde asla düz metin olarak gösterilmez.

Görsel 2: RADIUS Server Profile penceresi ve sunucu tanımı

Authentication Protocol açılır listesi PAP, CHAP, PEAP-MSCHAPv2, PEAP with GTC ve EAP-TTLS with PAP seçeneklerini sunar. SignLogger entegrasyonunda bu alanda mutlaka PAP seçilmelidir: SignLogger'ın RADIUS sunucusu captive portal doğrulamasını PAP ile yapar; başka bir yöntem seçilirse doğrulama istekleri yanıtlanamaz ve portal girişleri başarısız olur. PAP'ta kimlik bilgileri RADIUS paketi içinde paylaşılan anahtarla korunduğu için Secret alanına uzun ve tahmin edilemez bir değer girin; güvenlik duvarı ile SignLogger arasındaki RADIUS trafiğini de yönetim ağı gibi yalıtılmış bir ağ üzerinden taşıyın.

Görsel 3: Authentication Protocol seçenekleri

Adım 1.2 - RADIUS Tabanlı Authentication Profile Oluşturma

Sunucu profili tek başına kullanılabilir değildir; onu bir Authentication Profile içine sarmalamanız gerekir. Device sekmesinde sol menüden Authentication Profile başlığını seçtiğinizde mevcut profillerin listesini, her profilin kimlik doğrulama türünü, bağlı sunucu profilini, izin listesini ve hesap kilitleme değerlerini görürsünüz.

Görsel 4: Device > Authentication Profile listesi

Alttaki Add düğmesi boş bir Authentication Profile penceresi açar. Pencerede Name alanı ve üç sekme bulunur: Authentication, Factors ve Advanced. Başlangıçta Type değeri None’dır ve bu haliyle profil hiçbir iş yapmaz.

Görsel 5: Boş Authentication Profile penceresi

Type açılır listesi PAN-OS’un desteklediği tüm kimlik doğrulama arka uçlarını gösterir: None, Cloud Authentication Service, Local Database, RADIUS, LDAP, TACACS+, SAML ve Kerberos. RADIUS entegrasyonu için RADIUS seçeneğini işaretleyin. Captive Portal’ı hızlıca test etmek istiyorsanız harici bir sunucuya ihtiyaç duymayan Local Database seçeneği de kullanılabilir.

Görsel 6: Authentication Profile Type seçenekleri

RADIUS seçildiğinde pencereye iki yeni alan gelir. Server Profile alanı zorunludur ve kırmızı çerçeveyle işaretlenir. Altındaki Retrieve user group from RADIUS kutusu işaretlendiğinde güvenlik duvarı RADIUS yanıtındaki grup bilgisini (örneğin Filter-Id veya satıcıya özel öznitelikler) okuyup grup tabanlı politika yazmanıza olanak tanır. User Domain ve Username Modifier alanları kullanıcı adının RADIUS’a hangi biçimde gönderileceğini belirler; %USERINPUT% kullanıcının yazdığı değeri olduğu gibi iletir.

Görsel 7: RADIUS türü seçildikten sonraki alanlar

Server Profile açılır listesini tıkladığınızda daha önce oluşturduğunuz RADIUS profilleri listelenir. Listenin altındaki New RADIUS Profile kısayolu, pencereden çıkmadan yeni bir sunucu profili oluşturmanıza imkan verir.

Görsel 8: Server Profile seçimi

Sunucu profili seçildikten ve grup bilgisi çekme kutusu işaretlendikten sonra Authentication sekmesi tamamlanmış olur. Bu haliyle profil, kullanıcı adı ve şifreyi RADIUS sunucusuna soracak ve dönen grup bilgisini politika değerlendirmesinde kullanacaktır.

Görsel 9: Tamamlanmış RADIUS Authentication Profile

Adım 1.3 - Allow List ve Hesap Kilitleme (Advanced sekmesi)

Advanced sekmesi çok sık atlanan ama kritik bir sekmedir. Allow List boş bırakılırsa hiç kimse bu profille kimlik doğrulayamaz. Bu yüzden en az bir giriş eklemelisiniz. Account Lockout bölümündeki Failed Attempts kaç başarısız denemeden sonra hesabın kilitleneceğini, Lockout Time ise kilidin kaç dakika süreceğini belirler. Lockout Time değerinin 0 olması kilidin yönetici müdahalesine kadar süreceği anlamına gelir; misafir ağlarında kaba kuvvet saldırılarına karşı makul bir değer girmeniz önerilir.

Görsel 10: Authentication Profile Advanced sekmesi

Allow List satırında Add’e bastığınızda açılan listede all seçeneği ile birlikte cihazda tanımlı gruplar ve kullanıcılar görünür. all seçeneği kimlik doğrulaması başarılı olan herkese izin verir; en az yetki ilkesi gereği üretim ortamında bunun yerine belirli bir grubu seçmek daha doğrudur. RADIUS kullanıyorsanız ve grup bilgisi çekiliyorsa buraya RADIUS’tan gelen grup adlarını yazabilirsiniz.

Görsel 11: Allow List seçenekleri

BÖLÜM 2: Palo Alto Captive Portal Nasıl Ayarlanır?

Captive Portal kurulumu birbirine bağımlı adımlardan oluşur ve sırayı bozarsanız bazı alanları seçemezsiniz. Örneğin SSL/TLS Service Profile oluşturmak için önce sertifikanın, sertifikayı üretmek için de önce kök CA’nın var olması gerekir. Aşağıdaki sıra bu bağımlılıklara göre düzenlenmiştir.

Adım 2.1 - Misafir Ağı için Layer 3 Arabirim ve Alt Arabirim

Network sekmesindeki Interfaces ekranı tüm fiziksel arabirimleri, alt arabirimleri, atanmış yönetim profillerini, IP adreslerini, VLAN etiketlerini ve güvenlik bölgelerini tek tabloda gösterir. Örnek yapılandırmada ethernet1/1 untrust bölgesinde DHCP istemcisi olarak çalışır, ethernet1/2 trust bölgesinde yönetim bacağıdır ve misafir ağı ethernet1/2.71 alt arabirimiyle Guest bölgesine bağlanmıştır.

Görsel 12: Network > Interfaces genel görünüm

Alt arabirimin üzerine tıkladığınızda Layer3 Subinterface penceresi açılır. Config sekmesinde VLAN etiketini (Tag), sanal yönlendiriciyi (Virtual Router) ve güvenlik bölgesini (Security Zone) tanımlarsınız. Misafir ağını kesinlikle ayrı bir bölgeye koymalısınız; Authentication Policy kuralları bölge bazında yazıldığı için bu ayrım işlevsel bir zorunluluktur.

Görsel 13: Layer3 Subinterface - Config sekmesi

IPv4 sekmesinde arabirime statik bir IP adresi verin. Bu adres aynı zamanda misafir istemcilerin varsayılan ağ geçidi ve Captive Portal’ın yönlendirme hedefi olacaktır. Örnekte 172.16.1.1/24 kullanılmıştır.

Görsel 14: Layer3 Subinterface - IPv4 sekmesi

Advanced sekmesindeki Other Info alt sekmesinde Management Profile alanı yer alır. Captive Portal’ın çalışması için bu alana Response Pages ve User-ID servislerini açan bir arabirim yönetim profili atamak zorundasınız. Palo Alto’nun resmi dokümantasyonunda bu şart açıkça belirtilir: yönetim (MGT) arabirimi dışındaki bir arabirim kullanıyorsanız Interface Management Profile içinde Response Pages ve User-ID etkinleştirilmelidir.

Görsel 15: Layer3 Subinterface - Advanced sekmesi ve Management Profile

Adım 2.2 - Interface Management Profile: Response Pages ve User-ID

Network sekmesinde Network Profiles altındaki Interface Mgmt başlığına gidin. Tablo, her profilde hangi servislerin açık olduğunu sütunlar halinde gösterir. Misafir arabirimine atanacak profilde RESPONSE PAGES ve USER-ID sütunlarının işaretli olması şarttır. Bu iki kutu işaretli değilse yönlendirme gerçekleşse bile portal sayfası hiç açılmaz.

Görsel 16: Network > Network Profiles > Interface Mgmt listesi

Profili açtığınızda Interface Management Profile penceresi görünür. Administrative Management Services bölümündeki HTTP, HTTPS, Telnet ve SSH kutuları güvenlik duvarının yönetim arayüzüne erişimi kontrol eder; misafir ağında bunların hepsi kapalı kalmalıdır. Network Services bölümünde ise yalnızca Response Pages ve User-ID kutularını işaretleyin. Permitted IP Addresses listesini boş bırakmak tüm kaynaklara izin verir; misafir ağını sınırlamak isterseniz buraya misafir alt ağını yazabilirsiniz.

Görsel 17: Interface Management Profile penceresi

Adım 2.3 - Güvenlik Bölgesinde User Identification’ı Açma

Network sekmesindeki Zones ekranı bölgeleri ve her bölgede User-ID durumunu gösterir. Misafir bölgesinde User-ID sütunundaki ENABLED kutusunun işaretli olması gerekir. Bu kutu kapalıysa güvenlik duvarı o bölgeden gelen trafik için IP-kullanıcı eşlemesi oluşturmaz ve kimlik doğrulaması başarılı olsa bile kullanıcı hâlâ unknown olarak görünür.

Görsel 18: Network > Zones listesi ve User-ID durumu

Bölgeyi açtığınızda Zone penceresinde Enable User Identification kutusunu işaretleyin. Sağ taraftaki User Identification ACL alanı iki listeden oluşur: Include List’e yazdığınız adresler için kullanıcı tanımlaması yapılır, Exclude List’e yazdığınız adresler ise kapsam dışında kalır. Kimlik doğrulaması istemediğiniz sunucuları, yazıcıları veya RADIUS sunucusunun kendisini Exclude List’e eklemek yaygın bir uygulamadır.

Görsel 19: Zone penceresi ve User Identification ACL

Adım 2.4 - Misafir Ağı için DHCP Sunucusu

Misafir istemcilerin adres, ağ geçidi ve DNS bilgisi alabilmesi için Network sekmesindeki DHCP başlığı altında misafir arabirimi için bir DHCP sunucusu tanımlayın. Liste ekranı arabirimi, modu, kira süresini, dağıtılan DNS sunucularını, adres havuzunu ve ağ geçidini özetler.

Görsel 20: Network > DHCP sunucu listesi

DHCP Server penceresinin Lease sekmesinde kira süresini ve IP havuzunu belirlersiniz. Unlimited seçeneği laboratuvar için pratiktir ancak misafir ağlarında adres tükenmesine yol açabilir; Timeout seçip birkaç saatlik bir kira süresi vermek daha doğrudur. IP Pools alanına tüm alt ağı yazmak yerine 172.16.1.10 - 172.16.1.200 gibi bir aralık tanımlamak, ağ geçidi ve statik cihazlar için yer bırakır.

Görsel 21: DHCP Server - Lease sekmesi

Options sekmesinde Gateway alanına misafir arabiriminin IP adresini, Subnet Mask alanına ağ maskesini ve Primary/Secondary DNS alanlarına DNS sunucularını girin. Önemli bir ayrıntı: Captive Portal’ı IP adresi yerine bir intranet ana bilgisayar adıyla (redirect host) kullanmak istiyorsanız, istemcilere dağıttığınız DNS sunucusunun bu adı misafir arabiriminin IP adresine çözebilmesi gerekir. Resmi dokümantasyon bu nedenle redirect host için bir DNS A kaydı oluşturulmasını şart koşar.

Görsel 22: DHCP Server - Options sekmesi

Adım 2.5 - Sertifikalar: Kök CA ve Portal Sunucu Sertifikası

Redirect modunda portal sayfası HTTPS üzerinden sunulduğu için bir sunucu sertifikasına ihtiyacınız var. Resmi dokümantasyonun önerdiği yol önce kendi imzalı bir kök CA oluşturmak, ardından bu CA ile portal için bir sunucu sertifikası üretmektir. Device sekmesinde Certificate Management altındaki Certificates ekranı tüm sertifikaları hiyerarşik olarak gösterir; alt satırdaki sertifika üst satırdaki CA tarafından imzalanmıştır.

Görsel 23: Device > Certificate Management > Certificates

Alttaki Generate düğmesi Generate Certificate penceresini açar. Pencerede Certificate Type olarak Local ve SCEP seçenekleri, Certificate Name, Common Name, Signed By alanları, Certificate Authority ve Block Private Key Export kutuları, kriptografik ayarlar ve Certificate Attributes tablosu bulunur.

Görsel 24: Boş Generate Certificate penceresi

Önce kök CA’yı oluşturun. Certificate Name alanına CA için bir ad, Common Name alanına kurumsal bir tanımlayıcı yazın, Signed By alanını boş bırakın (boş bırakılması kendi imzalı anlamına gelir) ve Certificate Authority kutusunu işaretleyin. Expiration değerini CA için uzun tutun; örnekte 3650 gün kullanılmıştır. Algoritma olarak RSA 2048 bit ve sha256 özeti güncel istemcilerle uyumludur.

Görsel 25: Kök CA sertifikası oluşturma

Sıra portal sunucu sertifikasında. Bu kez Certificate Authority kutusunu işaretlemeyin ve Signed By açılır listesinden az önce oluşturduğunuz kök CA’yı seçin. Listede External Authority (CSR) seçeneği de bulunur; harici bir CA’ya imzalatmak istiyorsanız bu seçenekle sertifika imza talebi üretebilirsiniz.

Görsel 26: Signed By seçimi

En kritik ayrıntı Certificate Attributes tablosunda. Add’e bastığınızda açılan Type listesinde Country, State, Locality, Organization, Department, Email, Host Name = DNS from SAN, IP = IP Address from SAN ve Alt Email seçenekleri bulunur. Resmi dokümantasyon, portal sertifikasına yönlendirme yapılacak Layer 3 arabiriminin IP adresini SAN alanına eklemeyi şart koşar. Modern tarayıcılar Common Name alanını artık dikkate almadığı için SAN girişi olmadan sertifika geçersiz sayılır.

Görsel 27: Certificate Attributes tür seçenekleri

Türü seçtikten sonra VALUE hücresine çift tıklayıp değeri yazın; tek tıklama hücreyi düzenleme moduna almadığı için çok karıştırılan bir noktadır. Tamamlanmış pencerede Certificate Name portal sertifikasının adını, Common Name yönlendirme hedefini, Signed By kök CA’yı ve Certificate Attributes satırı SAN içindeki IP adresini gösterir. Generate düğmesine bastığınızda sertifika ve anahtar çifti üretilir.

Görsel 28: Tamamlanmış portal sunucu sertifikası formu

Oluşan kök CA’ya tıkladığınızda Certificate information penceresi açılır. Certificate Authority kutusu işaretli ve gri görünür. Altındaki Forward Trust Certificate, Forward Untrust Certificate ve Trusted Root CA kutuları SSL Forward Proxy şifre çözme için kullanılır. Captive Portal ile birlikte şifre çözme yapacaksanız resmi dokümantasyonun önemli bir uyarısını unutmayın: Authentication Portal yönlendirmesi SSL Inbound Inspection ile birlikte çalışmaz, mutlaka SSL Forward Proxy kullanmanız gerekir.

Görsel 29: Kök CA sertifika bilgileri

Portal sunucu sertifikasının bilgi penceresinde Subject alanı yönlendirme hedefini, Issuer alanı ise imzalayan kök CA’yı gösterir. CA kutuları boş ve pasiftir, çünkü bu bir uç varlık (end-entity) sertifikasıdır. Sertifikanın geçerlilik süresini not alın; süresi dolduğunda portal aniden çalışmayacaktır.

Görsel 30: Portal sunucu sertifikası bilgileri

Adım 2.6 - SSL/TLS Service Profile Oluşturma

Sertifikanın Captive Portal tarafından kullanılabilmesi için bir SSL/TLS Service Profile içine yerleştirilmesi gerekir. Device sekmesinde Certificate Management altındaki SSL/TLS Service Profile ekranı mevcut profilleri, bağlı sertifikayı ve desteklenen protokol sürümleriyle şifreleme algoritmalarını listeler. Cihazda önceden tanımlanmış TLSv1.3_Default profili bulunur ancak Captive Portal için kendi profilinizi oluşturmanız gerekir.

Görsel 31: SSL/TLS Service Profile listesi

Add ile açılan pencerede Name alanına profil adını, Certificate alanına portal sunucu sertifikasını seçin. Protocol Settings bölümünde Min Version ve Max Version değerlerini belirleyin. Resmi dokümantasyon, SSL/TLS Service Profile atanmadığında güvenlik duvarının varsayılan olarak TLS 1.2 kullandığını belirtir. Laboratuvarda en geniş istemci uyumluluğu için Min ve Max değerlerini TLSv1.2 yapmak sorunsuz sonuç verir; çok eski istemcileriniz yoksa TLSv1.3’ü de üst sınır olarak bırakabilirsiniz.

Görsel 32: SSL/TLS Service Profile penceresi

Adım 2.7 - Yerel Kullanıcı Veritabanı (RADIUS Alternatifi – Opsiyonel)

RADIUS veya LDAP kurmadan hızlı bir test yapmak istiyorsanız güvenlik duvarının yerel kullanıcı veritabanını kullanabilirsiniz. Device sekmesinde Local User Database altındaki Users ekranı tanımlı kullanıcıları ve etkin olup olmadıklarını gösterir. Bu yöntem üretim ortamları için ölçeklenebilir değildir ama kavram doğrulaması için idealdir.

Not: Bu adım opsiyoneldir. Bu rehberde kurduğumuz mimaride kimlik doğrulama RADIUS üzerinden yapılır, dolayısıyla yerel kullanıcı veritabanına üretim amacıyla ihtiyacınız yoktur. Buna rağmen tanımlı bir yerel kullanıcıyı silmeden bırakmanızı öneririz, çünkü portal açılmadığında veya giriş başarısız olduğunda sorunun nerede olduğunu hızla ayırt etmenizi sağlar: yerel kullanıcıyla giriş yapabiliyorsanız sorun RADIUS tarafındadır, yerel kullanıcıyla da giriş yapamıyorsanız sorun portal sayfası, sertifika veya politika tarafındadır. Bu nedenle aşağıdaki anlatımı zorunlu bir kurulum adımı değil, ek bilgi ve sorun giderme aracı olarak değerlendirin.

Görsel 33: Device > Local User Database > Users

Add ile açılan Local User penceresinde kullanıcı adını, mod seçeneğini ve şifreyi belirlersiniz. Mode alanı şifreyi düz metin olarak mı yoksa önceden hesaplanmış bir özet olarak mı gireceğinizi belirler.

Görsel 34: Local User ekleme penceresi

Kullanıcıları tek tek politikada kullanmak yerine bir grupta toplamak daha yönetilebilirdir. User Groups ekranı tanımlı grupları ve içlerindeki yerel kullanıcıları gösterir.

Görsel 35: Device > Local User Database > User Groups

Local User Group penceresinde gruba bir ad verip All Local Users listesinden üyeleri ekleyin. Bu grubu daha sonra Authentication Profile’ın Allow List alanında ve Security Policy kurallarında kullanabilirsiniz.

Görsel 36: Local User Group penceresi

Adım 2.8 - Captive Portal için Authentication Profile

Captive Portal’ın kullanacağı Authentication Profile’ı oluşturun. RADIUS kullanacaksanız Bölüm 1’de anlatılan profili kullanın; yerel veritabanı ile test edecekseniz Type alanını Local Database yapın. Username Modifier değerini %USERINPUT% bırakmak, kullanıcının yazdığı kullanıcı adının olduğu gibi değerlendirilmesini sağlar.

Görsel 37: Captive Portal için Authentication Profile (Local Database)

Advanced sekmesinde Allow List alanına az önce oluşturduğunuz kullanıcı grubunu ekleyin. Bu adımı atlamak Captive Portal kurulumlarında en sık rastlanan hatalardan biridir: her şey doğru görünür ama kullanıcı doğru şifreyi girse bile giriş reddedilir.

Görsel 38: Authentication Profile Advanced sekmesi ve Allow List

Adım 2.9 - Authentication Portal Settings

Kurulumun kalbi burası. Device sekmesinde User Identification başlığına girip üstteki Authentication Portal Settings sekmesini seçin. Özet ekranı tüm ayarları tek bakışta gösterir: portalın etkin olup olmadığı, eşleme süresi, atıl süre, seçili SSL/TLS profili, kimlik doğrulama profili, mod ve yönlendirme hedefi.

Görsel 39: Device > User Identification > Authentication Portal Settings özeti

Sağ üstteki dişli çark simgesine tıklayınca düzenleme penceresi açılır. Enable Authentication Portal kutusunu işaretleyin. Timer değeri kullanıcı giriş yaptıktan sonra IP-kullanıcı eşlemesinin kaç dakika saklanacağını belirler (varsayılan 60, aralık 1-1440). Idle Timer atıl kalan oturumun ne kadar sonra düşeceğini gösterir. SSL/TLS Service Profile alanında az önce oluşturduğunuz profili seçin; bu alanın boş bırakılması redirect modunda en sık görülen yapılandırma eksiğidir. Authentication Profile alanına global kimlik doğrulama profilini atayın. Mode olarak Redirect’i seçin ve Redirect Host alanına Layer 3 arabiriminin IP adresini ya da o adrese çözülen intranet ana bilgisayar adını yazın. Session Cookie bölümündeki Enable kutusu kullanıcının her istekte yeniden giriş yapmasını önler; Roaming seçeneği ise IP adresi değişse bile çerezin geçerli kalmasını sağlar.

Görsel 40: Authentication Portal düzenleme penceresi

Adım 2.10 - Authentication Enforcement Objesi

Authentication Policy kuralının hangi yöntemi ve hangi profili kullanacağını Authentication Enforcement objesi belirler. Objects sekmesindeki Authentication ekranında üç önceden tanımlı obje bulunur: default-web-form, default-browser-challenge ve default-no-captive-portal. Resmi dokümantasyona göre varsayılan objeler global Authentication Portal profilini kullanır ve önemli bir kısıtları vardır: kural bazlı Timeout değeri varsayılan objelerle uygulanmaz, MFA gerektiren kurallarda da kullanılamazlar. Bu nedenle kendi özel objenizi oluşturmak en iyi uygulamadır.

Görsel 41: Objects > Authentication listesi

Add ile açılan Authentication Enforcement penceresinde Name alanına objenin adını, Authentication Method alanına web-form değerini ve Authentication Profile alanına kullanılacak profili seçin. Message alanına yazdığınız metin kullanıcıya portal sayfasında görünür; misafirlere ne yapmaları gerektiğini açıklayan kısa bir cümle yazmak kullanıcı deneyimini belirgin şekilde iyileştirir.

Görsel 42: Authentication Enforcement objesi oluşturma

Adım 2.11 - Authentication Policy Kuralı

Portal ayarları tek başına hiçbir kullanıcıya sayfa göstermez; yönlendirmeyi tetikleyen şey Authentication Policy kuralıdır. Policies sekmesindeki Authentication ekranı kuralları kaynak, hedef, servis ve enforcement objesi sütunlarıyla listeler.

Görsel 43: Policies > Authentication kural listesi

Kuralı açtığınızda beş sekmeli Authentication Policy Rule penceresi görünür. General sekmesinde kuralın adını, açıklamasını ve etiketlerini tanımlarsınız. Kural adlarını anlamlı seçmek ileride sorun giderirken büyük kolaylık sağlar.

Görsel 44: Authentication Policy Rule - General sekmesi

Source sekmesinde Source Zone olarak misafir bölgesini seçin ve Source User alanını unknown yapın. Bu ayar kuralın yalnızca henüz kimliği bilinmeyen kullanıcılar için çalışmasını sağlar; giriş yapmış kullanıcılar tekrar tekrar portala düşmez.

Görsel 45: Authentication Policy Rule - Source sekmesi

Destination sekmesinde hedef bölge olarak internete çıkış bölgesini seçin. Hedef adresi any bırakmak, kullanıcının gittiği her sitede yönlendirmenin tetiklenmesini sağlar.

Görsel 46: Authentication Policy Rule - Destination sekmesi

Service/URL Category sekmesinde service-http ve service-https servislerini ekleyin. Captive Portal yalnızca web trafiğini yönlendirebilir; DNS, NTP veya diğer protokoller üzerinden yönlendirme yapılamaz. Dilerseniz URL Category alanıyla belirli kategorilerde kimlik doğrulaması isteyip diğerlerini serbest bırakabilirsiniz.

Görsel 47: Authentication Policy Rule - Service/URL Category sekmesi

Actions sekmesi kuralın davranışını belirler. Authentication Enforcement alanına kendi oluşturduğunuz objeyi seçin. Timeout değeri kullanıcının kaç dakika sonra yeniden kimlik doğrulaması yapması gerektiğini belirler. Log Settings bölümünde Log Authentication Timeouts kutusunu işaretlemek ve bir Log Forwarding profili seçmek, sorun giderme sırasında hayat kurtarır.

Görsel 48: Authentication Policy Rule - Actions sekmesi

Adım 2.12 - Security Policy ve NAT Kuralları

Resmi dokümantasyon net bir uyarı yapar: başlamadan önce güvenlik politikanızın, kimlik doğrulaması gerektiren servislere ve URL kategorilerine erişime izin verdiğinden emin olun. Pratikte bu üç kural anlamına gelir. Birincisi, henüz kimliği bilinmeyen misafirlerin DNS çözümlemesi yapabilmesi için bir DNS izin kuralı; DNS çalışmazsa tarayıcı hiçbir siteye gitmeye çalışmaz ve yönlendirme hiç tetiklenmez. İkincisi, kimlik doğrulaması yapmış kullanıcıların (known-user) internete çıkmasına izin veren kural. Üçüncüsü de en altta duran varsayılan reddetme kuralı.

Görsel 49: Policies > Security kural listesi

Misafirlerin internete çıkabilmesi için ayrıca bir kaynak NAT kuralı gerekir. Policies sekmesindeki NAT ekranında kaynak bölge olarak misafir ve iç bölgeleri, hedef bölge olarak untrust’ı seçin ve çeviri türü olarak dynamic-ip-and-port seçerek dış arabirimi belirtin.

Görsel 50: Policies > NAT kuralı

Adım 2.13 - Response Pages ve Commit

Device sekmesindeki Response Pages ekranı güvenlik duvarının kullanıcılara gösterdiği tüm sayfaları listeler. Captive Portal Comfort Page satırı bizim için en önemli olanıdır çünkü web-form kimlik doğrulamasında kullanıcıya sunulan giriş sayfası tam olarak budur. Bu sayfanın Action sütununda Disabled yazmaması gerekir.

Görsel 51: Device > Response Pages listesi

SignLogger Comfort Page Dosyasını İndirme ve Yükleme

Bu rehberde kurduğumuz mimaride kullanıcı, güvenlik duvarının kendi hazır giriş formunu görmez. Karşılama ve kimlik doğrulama arayüzünü SignLogger sunar; güvenlik duvarındaki Captive Portal Comfort Page ise yalnızca kullanıcıyı SignLogger'a taşıyan bir köprü sayfası görevi görür. Bu köprü sayfasını elle yazmanız gerekmez. Comfort page, SignLogger’ın captive portal yönetimi sayfasında her cihaz için ayrı ayrı üretilir: portalı kullanacak güvenlik duvarını SignLogger tarafında bir cihaz olarak tanımlarsınız, SignLogger da o cihaza özel comfort page dosyasını oluşturur ve .txt uzantılı bir metin dosyası olarak indirmenize sunar. Birden fazla güvenlik duvarı yönetiyorsanız her biri için kendi dosyasını ayrı ayrı üretmeniz gerekir; dosya cihaza özel üretildiği için bir güvenlik duvarının dosyası diğerinde kullanılamaz. Aynı şekilde portal adresi, port veya cihaz tanımı SignLogger tarafında değişirse dosyanın yeniden üretilip güvenlik duvarına tekrar yüklenmesi gerekir. Dolayısıyla Response Pages adımında yapmanız gereken iş, ilgili cihaz için üretilen bu dosyayı SignLogger arayüzünden indirmek ve aynı güvenlik duvarının Captive Portal Comfort Page alanına yüklemektir.

Dosyayı indirdikten sonra içeriğini bir metin düzenleyicide açıp iki değeri mutlaka doğrulayın: portal adresi kendi SignLogger sunucunuzu (örnekte http://10.100.100.253:8080/paguest), fw parametresi ise kendi güvenlik duvarınızın yönetim adresini (örnekte 10.254.253.244) göstermelidir. Dosyayı tek parça, düz HTML olarak tutun; harici CSS, yazı tipi veya görsel bağımlılığı eklemeyin, çünkü özel yanıt sayfaları boyut sınırlıdır ve kullanıcı henüz kimlik doğrulamadığı için dış kaynakları indiremez. Laboratuvarımızda kullandığımız dosyanın tam içeriği aşağıdadır.

<!DOCTYPE html>
<html lang="tr">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Misafir Girisi</title>
<script type="text/javascript">
(function(){
  var portal = "http://10.100.100.253:8080/paguest";
  var mgmt = "10.254.253.244";
  try {
    var sep = portal.indexOf("?") === -1 ? "?" : "&";
    portal += sep + "panos=1&fw=" + encodeURIComponent(mgmt) + "&orig=" + encodeURIComponent(window.location.href);
  } catch(e){}
  window.location.replace(portal);
})();
</script>
<meta http-equiv="refresh" content="0;url=http://10.100.100.253:8080/paguest?panos=1&amp;fw=10.254.253.244">
</head>
<body style="font-family:sans-serif;text-align:center;padding-top:40px">
Misafir giris sayfasina yonlendiriliyorsunuz... / Redirecting...<br>
<a href="http://10.100.100.253:8080/paguest?panos=1&amp;fw=10.254.253.244">Devam et / Continue</a>
</body>
</html>

Sayfanın üç ayrı yönlendirme katmanı içermesi bilinçlidir. JavaScript bloğu çalışırsa window.location.replace ile anında yönlendirme yapar ve orig parametresiyle kullanıcının o an bulunduğu portal adresini SignLogger'a taşır; böylece giriş sonrası kullanıcı kaldığı yere geri dönebilir. JavaScript kapalıysa meta refresh etiketi devreye girer. İkisi de çalışmazsa kullanıcı Devam et / Continue bağlantısına kendisi dokunabilir. Sayfayı özelleştirirken bu üç katmanı da koruyun, çünkü bazı istemcilerde (özellikle iOS'un captive portal mini tarayıcısında) tek katmanlı yönlendirme sessizce başarısız olur.

Yükleme adımları şöyledir. Önce SignLogger arayüzünde captive portal yönetimi sayfasını açın, listeden portalı kullanacak güvenlik duvarını seçin ve o cihaz için üretilen comfort page dosyasını .txt olarak bilgisayarınıza indirin. Ardından güvenlik duvarının web arayüzünde Device sekmesinde Response Pages ekranını açın, Captive Portal Comfort Page satırına tıklayın, açılan pencerede Import düğmesini kullanın, SignLogger'dan indirdiğiniz .txt dosyasını seçin ve hedef konum olarak Shared (çok sanal sistemli kurulumlarda ilgili vsys) seçeneğiyle OK verin. İşlem sonrasında aynı pencerede Predefined satırının yanında bir de Shared satırı görünmelidir; Shared satırı sizin yüklediğiniz sayfadır ve kullanıcıya öncelikli olarak o sunulur. Predefined satırını silmeyin: sorun yaşarsanız yalnızca Shared satırını kaldırmak sizi güvenlik duvarının varsayılan giriş formuna geri döndürür ve bu, en hızlı geri alış yöntemidir.

Görsel 51a: Device > Response Pages > Captive Portal Comfort Page penceresi (Shared satırı yüklenen özel sayfa, Predefined satırı varsayılan sayfa)

Görsel 51b: Import File penceresi – SignLogger'dan indirilen .txt dosyası seçilir ve Destination alanı shared olarak bırakılır

Import işlemi tek başına yeterli değildir. Yükleme yalnızca aday yapılandırmaya (candidate config) yazılır; Commit penceresini açtığınızda kapsamın shared-object olarak görünmesi bunun kanıtıdır. Commit almadan tarayıcıda test ederseniz eski sayfa gelmeye devam eder; bu, en sık karşılaşılan yanlış teşhis nedenidir. Aynı şekilde Response Pages listesinde Captive Portal Comfort Page satırının Action sütununda Disabled yazmadığını da yükleme sonrasında bir kez daha doğrulayın.

Comfort Page ile Birlikte Yapılması Gereken Ayarlar

Yönlendirme sayfası tek başına çalışmaz. Kullanıcı henüz kimlik doğrulamadığı için SignLogger sunucusuna erişim hakkı yoktur ve yönlendirme, sayfa açılmadan zaman aşımına düşer. Bu nedenle Security politikalarında, kimlik doğrulama zorunlu kılan kurallardan önce eşleşen bir ön yetki (pre-authentication) kuralı gerekir. Laboratuvarda bu kurala guest-to-signlogger-portal adını verdik: kaynak bölge Guest, hedef bölge trust, hedef adres SignLogger adres nesnesi (örnekte 10.100.100.253), servis service-http ve service-https, eylem Allow. Comfort page 8080 portuna gittiği için service-http nesnesinin 80 ve 8080 portlarını birlikte kapsadığını doğrulayın; PAN-OS'un öntanımlı service-http nesnesi bunu zaten yapar. Kuralın sıralamada kimlik doğrulama gerektiren kurallardan önce olması şarttır.

Kuralın gerçekten eşleştiğini tahmine bırakmayın. Device sekmesindeki Troubleshooting ekranında Security Policy Match testini kullanın: From alanına Guest, To alanına trust, kaynak adrese istemcinin adresini, hedef adrese SignLogger adresini ve hedef porta 8080 yazıp Execute dediğinizde sonuç guest-to-signlogger-portal kuralını göstermelidir. Başka bir kural dönüyorsa sıralamayı düzeltmeniz gerekir.

Authentication Portal Settings ekranında mod Redirect olmalı ve Redirect Host alanı misafir ağının güvenlik duvarı üzerindeki adresini göstermelidir (örnekte 172.16.1.1); comfort page yalnızca redirect modunda anlamlıdır, çünkü tarayıcının çerez kaydedip yönlendirmeyi izleyebilmesi gerekir. Aynı ekranda Authentication Profile alanı RADIUS profilini (örnekte RADIUS-Auth), SSL/TLS Service Profile alanı ise portal sertifikanızı taşıyan profili göstermelidir. Timer ve Idle Timer değerleriyle Session Cookie süresini bilinçli seçin: laboratuvarda portal zamanlayıcısı 60 dakika, oturum çerezi 1440 dakikadır ve çerez süresi uzun olduğu için bir kullanıcıyı yeniden girişe zorlamak istediğinizde istemci tarafındaki çerezin de temizlenmesi gerekir.

Ağ tarafında iki ayrıntı kolayca atlanır. Birincisi, misafir bölgesinde User-ID etkin olmalı ama portal sunucusunun adresi (örnekte 10.100.100.253) bölgenin Exclude listesine eklenmelidir; aksi halde portal sunucusunun kendi trafiği de kullanıcı eşleştirmesine dahil edilmeye çalışılır. İkincisi, kullanıcının yönlendirmeyi tetikleyebilmesi için kimlik doğrulamadan önce DNS çözümlemesine izin veren bir kural bulunmalıdır; laboratuvarda bu işi yalnızca dns uygulamasına izin veren ayrı bir kural yapar.

SignLogger'ın istemcinin gerçek adresini görebilmesi için misafir ağından portal sunucusuna giden trafiğe NAT uygulamayın. Bunun karşılığı olarak SignLogger'ın bulunduğu ağdaki yönlendiricinin misafir alt ağına (örnekte 172.16.1.0/24) geri dönüş rotası olmalıdır; bu rota yoksa sayfa açılmaz ve sorun yanlışlıkla comfort page hatası gibi görünür. Portal adresi HTTP üzerinden 8080 portuna gittiği için bazı tarayıcılar HTTPS bir sayfadan HTTP bir adrese yönlendirmeyi güvensiz sayabilir; üretimde SignLogger arayüzünü HTTPS ile yayınlamak ve comfort page içindeki adresi de https olarak güncellemek en temiz çözümdür.

Son olarak doğrulamayı üç katmanda yapın. SignLogger üzerinde giriş yaptıktan sonra Monitor > Logs > Authentication ekranında Authentication Success satırını, kullanılan kimlik doğrulama nesnesini ve protokol alanında RADIUS istemcinizin kullandığı yöntemi (laboratuvarda PAP) görmelisiniz. Monitor > Logs > User-ID ekranında aynı IP için bir kullanıcı eşleşmesi oluşmalı, Monitor > Logs > Traffic ekranında ise o istemcinin yeni oturumlarında Source User alanı dolmalıdır. Yönlendirme çalışıyor ama Authentication kaydı hiç oluşmuyorsa SignLogger kimlik bilgilerini güvenlik duvarının portal formuna geri göndermiyor demektir; bu durumda kullanıcı eşlemesi de oluşmaz; SignLogger tarafındaki cihaz tanımında güvenlik duvarı yönetim adresinin (fw parametresi) doğru olduğunu ve comfort page dosyasının bu cihaz için üretilmiş dosya olduğunu kontrol edin.

Tüm adımlar tamamlandıktan sonra sağ üstteki Commit düğmesiyle değişiklikleri çalışan yapılandırmaya aktarın. Önce Validate Commit çalıştırıp yapılandırmanın geçerli olduğunu doğrulamak iyi bir alışkanlıktır. Bu adımı atlamak Palo Alto’da en sık yapılan hatadır: aday yapılandırmada (candidate config) yapılan değişiklikler commit edilmedikçe trafiği hiç etkilemez, dolayısıyla ekranda her şey doğru görünürken portal çalışmıyor olabilir.

Doğrulama ve Test

Yapılandırmanın çalışıp çalışmadığını anlamanın en hızlı yolu loglardır. Monitor sekmesindeki Traffic logunda misafir istemcinin IP adresini filtreleyip Session End Reason sütununa bakın. Burada auth-policy-redirect değerini görüyorsanız yönlendirme başarıyla tetiklenmiş demektir. policy-deny değeri ise trafiğin güvenlik politikası tarafından engellendiğini gösterir.

Görsel 52: Monitor > Traffic logunda auth-policy-redirect

İkinci durak Monitor sekmesindeki Authentication logudur. Kullanıcı portal sayfasını gördüğünde ve giriş yaptığında burada kayıt oluşur. Authentication Timeout olayı ve kullanıcının kimlik bilgisi girmediğini söyleyen açıklama, sayfanın görüntülendiğini ama giriş yapılmadığını kanıtlar. Log tamamen boşsa yönlendirme hiç çalışmıyor ya da sayfa istemciye hiç ulaşmıyor demektir.

Görsel 53: Monitor > Authentication logu

Sorun Giderme: Captive Portal Çalışmıyorsa

Aşağıdaki senaryolar gerçek bir laboratuvar kurulumunda birebir yaşanmış ve çözülmüş sorunlardır.

Sorun 1: Portal açılıyor ama bembeyaz bir sayfa geliyor

En sinsi sorun budur. Yönlendirme çalışır, tarayıcı portal adresine gider, sertifika uyarısı geçilir ve ardından tamamen boş beyaz bir sayfa kalır. Nedeni genellikle Captive Portal Comfort Page’in üzerine içe aktarılmış bozuk ya da eksik bir özel HTML sayfasıdır. Bunu anlamanın yolu şu: Device sekmesinde Response Pages ekranında Captive Portal Comfort Page satırına tıklayın. Açılan pencerede yalnızca Predefined satırı varsa sorun başka yerdedir. Ancak Shared (veya vsys adı) diye ikinci bir satır görüyorsanız cihaza özel bir sayfa yüklenmiş demektir ve yerleşik giriş formunun yerini o almıştır. Karşılaştırma yapmak için aynı ekrandaki Data Filtering Block Page gibi hiç dokunulmamış bir sayfayı açın; orada tek satır görüyorsanız farkı net anlarsınız.

Görsel 54: Sorunlu durum - Shared konumunda özel bir comfort page var

Çözüm basit: Shared satırını seçip önce Export ile bir yedeğini alın, ardından Delete ile silin ve Commit yapın. Silme işleminden sonra güvenlik duvarı yerleşik (Predefined) giriş formuna geri döner ve portal anında çalışmaya başlar. Doğru duruma dönüldüğünde pencerede tek bir satır kalır.

Görsel 55: Çözüm sonrası - yalnızca Predefined sayfa kaldı

Sorun 2: Değişiklikler yapıldı ama hiçbir şey değişmiyor

Palo Alto’da yaptığınız her değişiklik önce aday yapılandırmaya yazılır ve commit edilmedikçe trafiği etkilemez. Sağ üstteki Commit düğmesi soluk görünmüyorsa bekleyen değişiklikleriniz var demektir. Nelerin beklediğini görmek için Device sekmesindeki Config Audit ekranında Local Candidate ile çalışan sürümü karşılaştırın ve Change Summary sekmesine bakın.

Sorun 3: Tarayıcı sertifika uyarısı veriyor

Kendi imzaladığınız kök CA istemcilerde güvenilir olmadığı sürece bu uyarı kaçınılmazdır. Resmi dokümantasyonun öngördüğü çözüm, kök CA sertifikasını dışa aktarıp tüm istemci tarayıcılarına güvenilir kök sertifika olarak içe aktarmaktır; Active Directory ortamında bunu bir GPO ile dağıtabilirsiniz. iOS cihazlarda profil kurulumu tek başına yetmez; Ayarlar bölümündeki Sertifika Güven Ayarları ekranından tam güveni ayrıca açmanız gerekir. Misafir ağlarında istemcilere sertifika kurdurmak pratik olmadığı için en temiz çözüm, portal için gerçek bir alan adı kullanıp bu ad için herkese açık bir CA’dan sertifika almaktır.

Sorun 4: iPhone ve iPad’de portal açılmıyor (Apple CNA)

Apple cihazlar ağa bağlandığında Captive Network Assistant (CNA) adı verilen küçük bir tarayıcı penceresi açar. Resmi dokümantasyonun CNA için ayrı bir bölümü vardır ve üç şart sayar. Birincisi redirect host olarak yalnızca IP değil bir FQDN tanımlanmış olması. İkincisi o FQDN için herkese açık bir CA tarafından imzalanmış sertifika kullanan bir SSL/TLS service profile seçilmesi. Üçüncüsü ise CLI üzerinden şu komutun girilmesi:

set deviceconfig setting ctd cap-portal-ask-requests 5

Bu üçüncü maddenin gerekçesi dokümantasyonda açıkça açıklanır: güvenlik duvarının portal için varsayılan hız limiti iki saniyede bir istektir. CNA bu limiti aşan sayıda istek gönderdiği için TCP reset oluşur ve kullanıcı hata alır. Önerilen değer 5’tir. Trafik logunda çok sayıda tcp-rst-from-client kaydı görüyorsanız bu tabloyla karşı karşıyasınız demektir.

Sorun 5: Yönlendirme hiç tetiklenmiyor

Sırayla şunları kontrol edin. Arabirim yönetim profilinde Response Pages ve User-ID kutuları işaretli mi? Bölgede Enable User Identification açık mı? Authentication Policy kuralının kaynak bölgesi, kullanıcı alanı (unknown) ve servisleri (service-http, service-https) doğru mu? Misafirler DNS çözümlemesi yapabiliyor mu? Bu dört maddeden biri eksikse portal hiç devreye girmez.

Sorun 6: Giriş başarılı ama internet açılmıyor

Kimlik doğrulaması başarılı olsa bile trafiğin geçmesi için known-user için yazılmış bir Security Policy kuralı gerekir. Bu kuralın hit sayısı sıfır kalıyorsa ya kullanıcı eşlemesi oluşmuyordur ya da kural sıralaması hatalıdır. Ayrıca kuralda uygulama alanı any bırakılıp servis alanı application-default seçilirse beklenmedik engellemeler yaşanabilir; ya uygulamaları açıkça belirtin ya da servis alanını any yapın. NAT kuralının misafir bölgesini kapsadığından da emin olun.

Hızlı Kontrol Listesi

Kuruluma başlamadan veya sorun giderirken şu sırayı takip edin: Layer 3 arabirim ve güvenlik bölgesi hazır, arabirim yönetim profilinde Response Pages ve User-ID açık, bölgede User Identification etkin, DHCP ve DNS çalışıyor, kök CA ve SAN içeren portal sertifikası üretilmiş, SSL/TLS Service Profile oluşturulup Authentication Portal Settings içinde seçilmiş, kimlik doğrulama profili ve Allow List tanımlanmış, özel Authentication Enforcement objesi oluşturulmuş, Authentication Policy kuralı doğru bölge ve servislerle yazılmış, DNS ve known-user için Security Policy kuralları mevcut, NAT kuralı misafir bölgesini kapsıyor, Captive Portal Comfort Page üzerine bozuk bir özel sayfa yüklenmemiş ve en önemlisi tüm değişiklikler commit edilmiş. SignLogger gibi harici bir portal kullanıyorsanız listeye iki madde daha eklenir: SignLogger’da o cihaz için üretilip indirilen comfort page .txt dosyası Captive Portal Comfort Page alanına yüklenmiş ve commit edilmiş olmalı, ayrıca misafir bölgesinden portal sunucusuna kimlik doğrulamadan önce erişim veren ön yetki kuralı politikalarda bulunmalıdır.

Sıkça Sorulan Sorular (SSS)

Captive Portal ile Authentication Portal arasındaki fark nedir?

Aynı özelliğin iki adıdır. Palo Alto PAN-OS 9.1 ile birlikte Captive Portal ifadesini Authentication Portal olarak değiştirdi. Arayüzde hâlâ Captive Portal Comfort Page gibi eski adlandırmaların izlerini görebilirsiniz.

Redirect mi Transparent mi kullanmalıyım?

Neredeyse her senaryoda Redirect. Oturum çerezi desteği, Kerberos SSO ve daha temiz bir sertifika deneyimi yalnızca bu modda mümkündür. Transparent mod istemciye hedef sunucuyu taklit ederek yanıt verdiği için her seferinde sertifika uyarısı üretir.

Redirect Host alanına IP mi yazmalıyım yoksa isim mi?

Resmi dokümantasyon, içinde nokta bulunmayan bir intranet ana bilgisayar adı kullanmanızı ve bu ad için bir DNS A kaydı oluşturmanızı önerir. IP adresi de çalışır ancak Apple CNA senaryosunda FQDN zorunludur ve sertifika yönetimi de isimle daha kolaydır.

Captive Portal ile SSL şifre çözmeyi birlikte kullanabilir miyim?

Evet, ancak dokümantasyonun net bir kısıtı var: Authentication Portal yönlendirmesi SSL Inbound Inspection’ı desteklemez. Yönlendirme ile birlikte şifre çözme yapacaksanız SSL Forward Proxy kullanmalısınız.

Varsayılan enforcement objesi yerine neden özel obje oluşturmalıyım?

Varsayılan objeler global kimlik doğrulama profilini kullanır. Dokümantasyona göre bu objelerle kural bazlı Timeout değeri uygulanmaz ve çok faktörlü kimlik doğrulama gerektiren kurallarda kullanılamazlar. Farklı kurallara farklı profiller atamak istiyorsanız özel obje zorunludur.

Sonuç

Palo Alto Captive Portal kurulumu tek bir ekrandan oluşmaz; arabirim yönetim profilinden sertifikaya, kimlik doğrulama profilinden politika kuralına kadar birbirine bağımlı bir zincirdir. Zincirin herhangi bir halkası eksik olduğunda sonuç genellikle sessiz bir başarısızlıktır: hata mesajı yerine boş bir sayfa ya da hiç açılmayan bir portal. Bu yüzden adımları sırasıyla uygulamak, her adımdan sonra commit etmeyi unutmamak ve sorun çıktığında önce trafik ve kimlik doğrulama loglarına bakmak en hızlı yaklaşımdır.

RADIUS tarafında ise sunucu profili ile kimlik doğrulama profilini birbirinden ayırmak ve Advanced sekmesindeki Allow List alanını boş bırakmamak, en sık karşılaşılan iki hatanın önüne geçer. Üretim ortamına geçmeden önce portal için gerçek bir alan adı ve herkese açık bir CA’dan alınmış sertifika kullanmayı, Apple cihazlar için CNA ayarlarını uygulamayı ve DHCP havuzunu daraltmayı planlayın.

Kaynaklar

Bu rehberdeki teknik gereksinimler aşağıdaki resmi kaynaklardan doğrulanmış, ekran görüntüleri PAN-OS 11.1.13 çalıştıran bir laboratuvar cihazından alınmıştır.