Cisco WLC Harici WebAuth Görünen Rasgele Davranış


10

On Cisco 5508 v7.2.103.0, ben yapılandırılmış WLAN'ların çift var. Bu soru uğruna onlara ABC ve XYZ deyin. ABC 802.1X kullanır ve açılış sayfası yönlendirme URL'sini aşağı iter. XYZ, PSK kullanır ve bir giriş sayfası yönlendirme URL'sini göndermek için WebAuth harici yapılandırmasını kullanır. Hem açılış hem de giriş sayfaları, http://webauth.example.com/splash.html ve /login.html gibi aynı temel (harici web sunucusu) URL'si altında sunulur.

WLAN ABC - Splash-Page-Web-Redirect[WPA + WPA2][Auth(802.1X + CCKM)]
WLAN XYZ - Web-Passthrough[WPA2][Auth(PSK)]

Yönlendirme URL'lerinin cihazlarda, webauth / NAC RUN durumunda ve aslında İnternet erişimi alma (veya gerektiğinde alma) konusunda tutarsız davranışlar görüyorum.

Giriş sayfasının trafiğin geçmesine izin vermeden önce kabul gerektirdiğini (kullanıcı adı gerekli değildir) ve WLC'nin burada trafik akışı için açılış sayfasının cihaz tarafından görüldüğünü (kabul gerekli değildir) düşünmesi gerektiğini anlıyorum.

Neredeyse tüm koşulları gördüm , ancak trafik akışlarının her zaman mantıklı olmadığı durumlar.

  1. Güvenli olmayan, düz metinli bir URL'ye göz atarken sıçrama veya Giriş sayfası yönlendirmesi gerçekleşir; webauth, NAC durumu RUN ile doğrulandı, trafik akışlarını gösterir. Bu beklenen bir şey ama sık sık gerçekleşmiyor.
  2. Güvenli olmayan, düz metinli bir URL'ye göz atarken sıçrama veya Giriş sayfası yönlendirmesi gerçekleşmez; webauth, NAC durumu RUN ile doğrulandı, trafik akışlarını gösterir (ancak istemciyi göstermeyen webauth yönlendirmesini zorlamak için istemciyi WLC'den kaldırdıktan sonra olmamalıdır).
  3. Güvenli olmayan, düz metinli bir URL'ye göz atarken sıçrama veya Giriş sayfası yönlendirmesi gerçekleşmez; webauth, NAC durumu WEBAUTH ile doğrulanmadı, trafik akışı var (ancak olmamalı).
  4. Güvenli olmayan, düz metinli bir URL'ye göz atarken sıçrama veya Giriş sayfası yönlendirmesi gerçekleşir; webauth, NAC durumu WEBAUTH ile kimlik doğrulaması yapılmadığını gösteriyor, trafik akmıyor (ancak WEBAUTH iletilirse gösterilmelidir).
  5. Güvenli olmayan, düz metinli bir URL'ye göz atarken sıçrama veya Giriş sayfası yönlendirmesi gerçekleşmez; webauth NAC durumu WEBAUTH ile doğrulanmadı, trafik akmıyor (beklendiği gibi).

Her durumda, istemci ayrıntısı, yönlendirme URL'sinin ayarlandığını gösterir.
Her şeyin yönlendirme, webauth / çalıştırma durumu ve trafik akışı (izin verilen veya reddedilen) ile beklendiği gibi çalıştığı iki durumda, ACL'lerin sorun olduğunu düşünmüyorum. Yönlendirme URL'si dışında ACS'den başka bir şey alınıyor. İki WLAN farklı VLAN'lara sabit kodlanmıştır.

Bu rastgele bir davranış olabilir mi veya gözlerim sadece bana bir numara mı oynuyor? Farklı cihazlarla biraz farklı davranışlar gördüm - bazıları daha rastgele, bazıları daha az.

Bu sorunu daraltmak için en iyi yaklaşım nedir?

Güncelleme : DNS sorun değil. Genel IP erişilebilirliği tarayıcıda rastgele çalışır. Webauth durumu ne olursa olsun (RUN vs WEBAUTH-REQD), bazen tarayıcı geçer ve bazen geçmez. (İlk istekler her zaman düz metin HTTP'dir.) SMTP gibi web dışı uygulamalar için düzenli trafik geçtiğini gördüm, bu yüzden gerçekten Webauth'un bununla uğraştığını düşünüyorum, ama açıkça yanlış bir şey görmüyorum . Oldukça liberal olan bir vaiz ACL ve bir misafir ACL var. Ben bile fark etmedi her iki ACL izin izin ekledim.


Birkaç kurulumun istediğinizi yapmak için konuk çapa denetleyicileri kullandığını bildiğimden, bir göz atacağım. Aynı şekilde kablosuz kullanmayı denediğim birkaç yerde de aynı sorunların olduğunu biliyorum. Bazen yönlendirme yapmıyor, bazen de beni çalıştırıyor! Yine de ortak bir sorun olduğunu söyleyebilirim.
Artanix

WLAN ABC, çalışanlar içindir ve 802.1X kullanır. Yalnızca WLAN XYZ, PSK kullanan konuklar içindir ve şu anda konuk denetleyicisine bağlı değildir. Önsöz ACL ile tamamen açık testler yaptım ve hala aynı rastgele davranışı elde ediyorum.
generalnetworkerror

Herhangi bir cevap size yardımcı oldu mu? öyleyse, cevabı kabul etmelisiniz, böylece soru sonsuza kadar ortaya çıkmayacak, bir cevap arıyor. Alternatif olarak kendi cevabınızı verebilir ve kabul edebilirsiniz.
Ron Maupin

Yanıtlar:


3

Geçmişte iki kez benzer sorunlar gördüm.

İlk kez DNS çözümlemesi ile ilgisi vardı. Sorunları olan bir istemcide DNS araması yaptım ve istemcinin giriş sayfası için geçirdiğim URL'yi çözemediğini fark ettim. Bunun nedeni harici bir DNS sunucusundan geçmemdi. Önce kontrol edin. 1.1.1.1'e çözümlenen bir cname oluşturabilseniz de, URL'yi IP'den geçirerek çözdüm.

İkinci kez, bir sertifika sorunuydu. Kullanıcının kendinden imzalı bir sertifikayı kabul etmesi gerekiyorsa bazı varsayılan tarayıcılar açılış ekranını göstermez. Bunu otomatik olarak göstermeyen bir istemciden açılış ekranına veya giriş sayfasına göz atarak test ediyorum.

Umarım bunlardan biri size yardımcı olur. Bunu ilk gördüğümde saçlarımı çekmeye hazır olduğumu biliyorum.


Lütfen 1.1.1.1 kullanmayın. Bu var geçerli reklamı adres alanı. Cisco'nun hala örneklerinde kullandığını biliyorum, ancak kullandığınızda Google'ın adres alanının bazılarını maskeliyorsunuz.
LapTop006

Görünüşe göre beni öldüren herhangi bir değişiklik olmadan aynı müşteri için rastgele davranış. @ LapTop006 ile 1.1.1.1 kullanmamamız gerektiğini kabul ediyorum. Özel / 32 adresiyle eşleşen bir DNS adı kullandım.
generalnetworkerror

@JD kaldırıldı. Ödül tutuyorum. Eğer bir cevabı kabul ederse, o ödülün ödülünü alacağım. Aksi takdirde çaba için ödül alırsınız. : ^)
Craig Constantine
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.