AP Online Olmuyor: Kontrol Edilecek 10 Kritik Nokta

Bir önceki yazıda AP online olduğu hâlde istemcinin IP alamadığı durumu, yani veri düzlemini inceledik. Bu kez bir adım geriye gidiyoruz: AP’nin kendisi yönetim ekranında hiç görünmüyor ya da sürekli offline. Bu bir kontrol düzlemi sorunudur: AP, controller’a ya da bulut yönetim platformuna ulaşamıyor.

“AP online değil” tek bir arıza değildir. AP’nin online olması için on noktanın sağlam olması gerekir; bu noktalar tipik olarak bir sıra izler ve sorun çoğu zaman sağlam olmayan ilk noktadadır. Bu yazıda o noktaları sırayla eleyeceğiz, sonra aynı kontrollerin Huawei, Cisco Catalyst 9800 ve Meraki, HPE Aruba ve Fortinet’te nerede yapıldığına bakacağız.

Senaryo

Kampüs ve VLAN 50 AP yönetim ağı önceki yazıdakiyle aynı. Bu kez bir de şube AP’si var.

AP online olana kadar: 10 kontrol noktası

Bu on nokta bütün AP’ler için zorunlu ve değişmez bir sıra değildir; bir kontrol listesi olarak okunmalıdır. Bazı adımlar mimariye göre atlanır ya da farklı işler: aynı ağdaki controller’ı yayınla bulan AP DNS keşfine hiç başvurmaz, statik adresli AP DHCP’ye bakmaz, bulut yönetimli AP’de CAPWAP keşfi ve DTLS yerine buluta güvenli bağlantı vardır.

Pratik sonuç şudur: yönetim ekranındaki “offline” bilgisi, sorunun hangi noktada olduğunu söylemez. İlk beş noktada bir sorun varsa AP controller’a hiç ulaşamaz ve controller’ın kayıtlarında da iz bırakmaz. Bu yüzden teşhise AP’nin olduğu yerden, güçten başlanır.

İki mimari, iki farklı “online”

Controller tabanlı mimaride (Huawei AC, Cisco Catalyst 9800, FortiGate’in yönettiği FortiAP) AP, kurum içindeki bir controller’a CAPWAP ile bağlanır. CAPWAP, RFC 5415’te tanımlıdır ve kontrol için UDP 5246, veri için UDP 5247 kullanır. AP’nin controller’ı bulması gerekir; bu, keşif adımıdır.

Bulut yönetimli mimaride (Meraki MR, Aruba Central’a bağlı AP’ler) yerel bir controller keşfi yoktur; AP, üreticinin bulutuna internet üzerinden bağlanır. Aruba’da AP, hangi bulut yönetim adresine bağlanacağını Aruba Activate üzerinden provisioning ile öğrenir. Belirleyici olan AP’nin dışarıya çıkışı, DNS ve doğru saattir.

Meraki için iki ayrıntı önemlidir:

• UDP 7351 asıl bağlantıdır. Erişilemezse AP HTTP/HTTPS üzerinden yedek bağlantıya geçer ve durum sayfasında bunu gösterir. Yedek bağlantıda yapılandırma güncellemeleri, canlı araçlar ve firmware yükseltmeleri yavaşlayabilir; Meraki’nin kendi kimlik doğrulama hizmeti ise yalnızca UDP 7351 üzerinden çalışır. Yani “dashboard’da görünüyor” bilgisi, firewall kurallarının doğru olduğu anlamına gelmez.
• Meraki dokümanına göre bulut bağlantısı tamamen kesilse de MR çalışmaya devam eder. Bu durumda AP dashboard’da offline görünür ama istemcilere hizmet verebilir; arıza kaydını açmadan önce kullanıcı tarafını da kontrol edin.

Controller tabanlı mimaride bağlantı kopunca istemci trafiğinin ne olacağı forwarding moduna ve yüksek erişilebilirlik tasarımına bağlıdır; bu, serinin ilerleyen bir yazısının konusu.

Controller tabanlı mimaride keşif ve CAPWAP

AP’nin controller’ı bulmasının dört yolu vardır:

• Aynı ağda yayın: Controller AP ile aynı L2 ağdaysa AP onu yayınla bulur. Merkezde AP ve controller VLAN 50’de olduğu için bu yeterlidir. Yayın L3 sınırını geçmez; şube AP’si controller’ı bu yolla bulamaz.
• DHCP option: DHCP sunucusu, AP’ye adresle birlikte controller adresini de verir. Burada numaralara dikkat:
  • Option 43: IPv4 controller adresleri. Cisco ve Huawei bunu kullanır; içeriğin biçimi üreticiye özgüdür. Yanlış biçimde girilen option 43, AP tarafından yok sayılır.
  • Option 52: IPv6 controller adresleri (Cisco ve Huawei).
  • Option 15: DHCP’nin “domain name” seçeneğidir; controller adresi taşımaz. DNS ile keşifte kullanılır (aşağıda). Huawei dokümanı da option 15’i adres listesi olarak değil, alan adı olarak sayar.
  • Option 138: FortiAP’nin varsayılan keşif seçeneğidir; kod FortiAP’de değiştirilebilir.
• DNS: AP, DHCP’den aldığı alan adına üreticinin belirlediği adı ekleyip sorgular. Cisco’da bu ad CISCO-CAPWAP-CONTROLLER.<alan-adı>’dır. DHCP kapsamında DNS sunucusu ya da alan adı yanlışsa bu yöntem çalışmaz.
• Statik: Controller adresi AP’nin üzerine elle yazılır.

Controller bulunduktan sonra sıra sabittir: DTLS el sıkışması, join, gerekirse imaj indirme ve yeniden başlama, yapılandırma ve Run. Join yanıtında controller beklediği sürümü bildirir; sürüm farklıysa AP imajı indirir, yeniden başlar ve keşiften devam eder. Bu adım başarısız olursa AP sürekli aynı döngüye girer.

On kritik nokta

Şube AP’si neden ayrı düşünülmeli? Merkezdeki AP, controller’ı aynı ağdaki yayınla bulur ve aradaki tek cihaz switch’tir. Şube AP’si ise controller’a IPsec tüneli üzerinden, L3 ile ulaşmak zorundadır. Bu yüzden şubede dört nokta birden devreye girer: tünelin 10.2.50.0/24 ile 10.0.50.0/24 arasını taşıması (4), DHCP’de controller adresi ya da DNS kaydı (6), firewall politikalarında CAPWAP portları (7) ve tünelin ek yükünün paket boyutunu küçültmesi (10). Huawei dokümanı da küçük MTU’lu yollarda yapılandırma aşamasının başarısız olabileceğini ve CAPWAP MTU’sunun düşürülebileceğini belirtir. MTU’nun tünelde neden küçüldüğünü VPN yazısında anlattık.

Aynı problem dört üreticide

Aşağıdaki komutlar her üreticinin resmî dokümanından alındı ve laboratuvarda çalıştırılmadı. Hiçbir çıktı örneği uydurulmadı; her komutta hangi bilgiye bakılacağı yazılı.

Huawei (AC + Fit AP)

Keşif ve yetki: AP, AC’yi L2 yayınla, DHCP option 43/52 ile, option 15/24 ile aldığı alan adını DNS’te çözerek ya da statik adresle bulur. AC, AP’yi kimlik doğrulama moduna göre kabul eder: MAC adresi ya da seri numarası beyaz listede olmalı, kimlik doğrulama kapalı olmalı ya da AP yönetici tarafından onaylanmalıdır.

İlk bakılacak yer:

display ap all

Çıktıdaki State alanı, AP’nin hangi kontrol noktasında takıldığını doğrudan söyler:

fault durumundaki AP’nin nedeni hata kaydında yazar. Komutun adı sürüme göre değişir: V200R010 dokümanında display ap online-fail record, V200R022 komut referansında display ap online-fail-record. Kayıtta görülebilecek nedenler arasında yetersiz lisans, beyaz listede olmama, kara listede olma, DTLS zaman aşımı ya da PSK uyuşmazlığı, CAPWAP tüneli kurulamaması, yükseltme hatası ve sürüm uyuşmazlığı var.

Destekleyici komutlar: display license resource usage (lisans), display capwap configuration (AC’nin CAPWAP kaynak adresi). AP tarafında yönetim VLAN’ı display system-information ile görülür.

Cisco Catalyst 9800 ve Meraki

Catalyst 9800, keşif: Option 43 (IPv4), option 52 (IPv6), CISCO-CAPWAP-CONTROLLER.<alan-adı> DNS kaydı, aynı ağda yayın ve AP üzerinde statik tanım (capwap ap primary-base <ad> <adres>). AP, birincil, ikincil ve üçüncül controller tanımlıysa bu sırayı izler; tanımlı değilse yanıt veren ve kapasitesi en uygun controller’a katılır.

Controller’da:

show ap summary
show wireless stats ap join summary
show wireless stats ap mac <radyo-MAC> join detailed

join summary her AP için durumu, son bağlantı kopma nedenini ve hangi aşamada (keşif, DTLS, join, yapılandırma) takıldığını gösterir. Ayrıntılı iz için AP’nin radyo MAC’ine göre RadioActive trace başlatılır: debug wireless mac <radyo-MAC>.

AP’de:

show dtls connection
debug capwap client events
debug capwap client error
debug dtls client error

show dtls connection sertifika, port, şifreleme ve DTLS sürümünü gösterir. SSH ya da Telnet ile bağlıyken debug çıktısını görmek için önce terminal monitor gerekir. Sürüm farklıysa AP imajı controller’dan indirir ve yeniden başlar; bu normal bir adımdır, sürekli tekrarlanıyorsa sorundur.

Meraki: Keşif yoktur. Kontrol listesi: UDP 7351 dışarıya açık mı, DNS Meraki adlarını çözüyor mu, NTP (pool.ntp.org) erişilebilir mi? Kuruluşa özel hedef IP adresleri ve portlar dashboard’da Help > Firewall info sayfasındadır; bu liste cihazlara, servislere ve bölgeye göre değişir. MR ayrıca bağlantı testleri yapar: düzenli aralıklarla ping, gateway’e ARP ve DNS sorgusu.

HPE Aruba Networking (Central)

Central’a bağlanan AP’de yerel bir CAPWAP controller keşfi yoktur. Bunun yerine AP, Aruba Activate üzerinden provisioning ile hangi Central adresine bağlanacağını öğrenir. Bu yüzden AP’nin Activate’e ve Central’a çıkabilmesi ve buluttaki kaydının doğru olması gerekir:

• Envanter ve abonelik: AP’nin MAC adresi ve seri numarası envanterde olmalı ve AP’ye bir cihaz aboneliği atanmış olmalıdır.
• Dışarıya erişim: TCP 443 (Central ve Activate), TCP 80 ve NTP için UDP 123. Bölgeye özel adresler Aruba’nın iletişim portları sayfasındadır.
• Offline tanımı: Central, 5 dakikadan uzun süre durum bilgisi göndermeyen cihazı offline sayar.
• Fiziksel taraf: Central’ın switch ayrıntı sayfası PoE uyarılarını ve port durumunu gösterir; AP’ye yönetim arayüzünden uzak konsolla bağlanılabilir.

Bu bilgiler Classic Central 2.5.8 dokümantasyonundandır; Central’ın yeni sürümünde arayüz farklı olabilir. Aruba AP’leri için CLI komutlarını bu yazıda doğrulayamadığımızdan vermiyoruz.

Fortinet (FortiGate + FortiAP)

Keşif: FortiAP’de keşif tipi AC_DISCOVERY_TYPE ile belirlenir: otomatik (bütün yöntemleri sırayla dener), statik, DHCP, DNS, yayın, multicast ve FortiCloud. DHCP ile keşifte varsayılan seçenek kodu 138’dir; CAPWAP kontrol portu varsayılan 5246’dır. AP_MGMT_VLAN_ID sıfırdan farklıysa FortiAP yönetim trafiğini o VLAN etiketiyle gönderir; switch portu etiketsiz bekliyorsa 2 numaralı nokta tam olarak budur.

Yetki: FortiGate’te AP kaydı arayüz bazında yapılır ve ap-discover ile kapatılabilir. Keşfedilen AP yetkilendirilmeden çalışmaz:

config wireless-controller wtp
    edit <seri-numarası>
        set admin enable
        set wtp-profile <profil>
    next
end

Neye bakılır:

diagnose wireless-controller wlac -c wtp
diagnose sniffer packet <arayüz> "port 5246" 4

İlki FortiGate’in gördüğü AP’leri ve durumlarını listeler; ikincisi AP’nin keşif ve CAPWAP paketlerinin FortiGate’in arayüzüne ulaşıp ulaşmadığını gösterir. Fortinet’in kontrol listesinde iki saha notu daha var: FortiCloud’a keşfedilen bir AP FortiGate’te online olmaz; FortiGate’in tunnel modu AP kapasitesi dolduysa AP’nin modunun değiştirilmesi gerekir. AP modeli ile FortiGate sürümünün uyumu sürüm notlarından kontrol edilmelidir.

Karşılaştırma

Sonuç

AP’nin online olmaması, AP’nin yönetim platformuna ulaşması için gereken on kontrol noktasından birinin sağlam olmamasıdır. İlk beş nokta (güç, VLAN, IP, yol, DNS ve NTP) ağın sorumluluğundadır ve yönetim ekranı bunları çoğu zaman göremez; son beş nokta (keşif, firewall, DTLS, yetki, sürüm) controller ya da bulut tarafında iz bırakır. Controller tabanlı ve bulut yönetimli mimarilerde “online” farklı şeyler ifade eder: birinde AP ile controller arasındaki CAPWAP yolu, diğerinde AP’nin internete çıkışı denetlenir. Şube gibi L3 üzerinden bağlanan AP’lerde ise keşif, firewall ve MTU birlikte düşünülmelidir.

Serinin ilerleyen yazılarında keşif ve CAPWAP sürecine ve controller bağlantısı koptuğunda ne olduğuna ayrıntılı bakacağız.

Kaynaklar

• Huawei: How an AP Joins an AC and Troubleshooting Any Join Failures (V200)
• Huawei: WLAN AC V200R022C00 Command Reference, display ap online-fail-record
• Cisco: Understand the AP Join Process with the Catalyst 9800 WLC
• Cisco: Troubleshoot Catalyst 9800 AP Join
• Cisco: DNS ile WLC keşfi
• Meraki: Upstream Firewall Rules for Cloud Connectivity
• HPE Aruba Networking: Central device troubleshooting
• HPE Aruba Networking: Central communication ports
• Fortinet: FortiAP CLI configuration and diagnostics commands (7.6)
• Fortinet: Discovery and authorization of APs (7.4)
• Fortinet Community: FortiAP offline, consolidated troubleshooting checklist