AP Online Ama İstemci IP Alamıyor: Sorun Gerçekten DHCP mi?

Kablosuz ağlarda en sık duyulan şikâyetlerden biri:

• AP yönetim ekranında online.
• SSID yayında, telefon ağı görüyor.
• İstemci bağlanıyor, şifre kabul ediliyor.
• Ama IP adresi yok. Ya hiç adres almıyor ya da 169.254.x.x ile kalıyor.

İlk refleks DHCP sunucusunu suçlamak olur. Oysa bu tabloda DHCP sunucusu çoğu zaman masumdur. AP’nin online olması yalnızca yönetim (kontrol) trafiğinin çalıştığını kanıtlar. İstemcinin veri trafiğinin doğru yere gittiğini kanıtlamaz.

Bu yazıda sorunu üreticiden bağımsız bir yöntemle sırayla eleyeceğiz. Sonra aynı kontrollerin Huawei, Cisco Catalyst 9800 ve Meraki, HPE Aruba ve Fortinet’te nerede yapıldığına bakacağız. AP’nin hiç online olmadığı durum, DNS ve gateway sorunları ve 802.1X hataları serinin ilerleyen yazılarının konusu.

Senaryo

Güvenlik serisindeki kampüs devam ediyor. Kablosuz kullanıcılar kablolu personelle aynı VLAN’a düşer; AP’ler için tek bir yönetim VLAN’ı ekleniyor.

Erişim switch’inde L2 yazısındaki gibi DHCP snooping açık; core switch’e bakan port 48 güvenilir port.

Önce mantık: istemcinin DHCP paketi nereden geçer?

İstemci bağlandıktan sonra bir DHCP Discover yayınlar. Bu paketin izlediği yol, SSID’nin forwarding moduna göre tamamen değişir.

• Bridge / local / direct forwarding: AP istemci trafiğini kendi uplink portundan, SSID’nin VLAN’ıyla switch’e bırakır. Controller veri yolunda yoktur. Discover’ın gateway’e ulaşması için VLAN 20’nin AP’nin switch portunda ve oradan gateway’e kadar her trunk’ta izinli olması gerekir.
• Tunnel / central switching: AP istemci trafiğini bir tünelle merkeze taşır. Discover kablolu ağa tünelin sonlandığı noktadan çıkar: mimariye göre bir controller ya da gateway. AP’nin switch portunda VLAN 20 gerekmez; tünelin sonlandığı cihazın uplink’inde gerekir.
• Meraki NAT modu: AP’nin kendisi DHCP sunucusudur ve istemcilere 10.0.0.0/8 aralığından adres verir. Bu modda VLAN etiketi kullanılamaz; kablolu taraftaki relay ve DHCP sunucusu devreye girmez. Bu yazının geri kalanındaki relay ve havuz adımları bu modda geçerli değildir.

Arıza ağacının ilk sorusu bu yüzden hep aynıdır: Bu SSID hangi modda çalışıyor? Yanlış yere bakmanın en hızlı yolu bunu bilmeden başlamaktır.

Discover gateway’e ulaştıktan sonra iki ihtimal vardır: gateway’in kendisi DHCP sunucusudur ya da bir DHCP relay’dir. Bizim senaryomuzda core switch relay’dir. Relay, yayını sunucuya unicast olarak iletir ve pakete giaddr (gateway IP) alanını yazar. Sunucu havuzu bu giaddr’a bakarak seçer ve Offer’ı yine giaddr’a gönderir.

Bu akışta iki sessiz kırılma noktası vardır: sunucuda giaddr ile eşleşen havuzun olmaması ve sunucunun giaddr adresine (10.0.20.1) ulaşamaması. Bu erişim varsayılan rota üzerinden de sağlanabilir; sunucuda ayrıca bir /24 rotası olması şart değildir. Önemli olan, sunucunun Offer’ı giaddr’a gönderebilmesidir. İkisinde de istemcide görülen belirti aynıdır: IP yok.

Yedi kırılma noktası, tek belirti

Aşağıdaki yedi durumda AP online kalır, SSID yayında kalır, istemci bağlanır ve IP alamaz.

Notlar:

• Havuz dolu (5) özellikle misafir ağında sık görülür: çok sayıda kısa süreli ziyaretçi ve uzun kira süresi, havuzu gün içinde tüketir. Misafir VLAN’ı 60’ta kira süresini kısa tutmak ve havuz doluluğunu izlemek bu yüzden önemlidir.
• Relay kaynak adresi (4) sessiz bir tuzaktır. Cisco’ya göre Catalyst 9800’de DHCP relay kaynak arayüzü değiştirilirse giaddr de değişir ve sunucuda bu yeni adrese uyan bir havuz gerekir.
• Snooping (7) kontrolünün yapılacağı switch, gerçek DHCP yoluna göre değişir: bridge modunda AP’nin bağlı olduğu erişim switch’i, tunnel modunda controller’ın bağlı olduğu switch. En sık iki neden: uplink’in güvenilir yapılmaması ve relay’in beklemediği option 82 bilgisi. Ayrıntılar L2 yazısında.
• Yanlış gateway bilgisi bu listede yok, çünkü belirtisi farklıdır: istemci IP alır ama başka ağlara çıkamaz. 802.1X sonrası RADIUS’un switch’te ya da controller’da tanımlı olmayan bir VLAN döndürmesi de üreticiye göre farklı sonuç verir; NAC yazısında değindik, ayrıntısı 802.1X sorun giderme yazısına kalıyor.

Arıza aramaya başlamadan önce, aynı SSID’de IP alabilen bir istemci varsa onu karşılaştırma noktası olarak kullanın: sorun tüm istemcilerde mi, tek bir AP’de mi, tek bir istemci tipinde mi?

Troubleshooting yöntemi: paketi takip et

Hangi üretici olursa olsun sıra aynıdır: önce istemcinin gerçekten bağlı ve doğru VLAN’da olduğunu, sonra forwarding moduna göre Discover’ın gateway’e ulaştığını, en son relay, sunucu ve dönüş yolunu doğrulayın. En hızlı kanıt paket yakalamadır: Discover’ın ya da Offer’ın hangi linkte görünüp hangisinde kaybolduğu, kırılma noktasını doğrudan gösterir.

Aynı problem dört üreticide

Mantık ortak; değişen, ayarın nerede durduğu ve nereye bakıldığı. 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 alana bakılacağı yazılı.

Huawei (AC + Fit AP)

Nerede ayarlanır: VAP profilinde. Forwarding modu (direct-forward, tunnel ya da SoftGRE) ve servis VLAN’ı bu profilde tanımlanır; SSID ve güvenlik profilleri de VAP profiline bağlanır.

Neye bakılır:

display vap-profile name <profil-adı>

Çıktıdaki Forward mode alanı forwarding modunu, Service VLAN ID alanı istemcinin düşeceği VLAN’ı gösterir. Bizim senaryoda servis VLAN’ı 20 olmalıdır. Komut ve alan adları WLAN AC V200R010C00 komut referansındandır.

Relay yapan Huawei S serisi switch’te relay ayarı ve kullanılan gateway adresi:

display dhcp relay interface vlanif 20

Çıktı, relay’in kullandığı gateway adresini (10.0.20.1) ve DHCP sunucusunu gösterir. Relay bir sunucu grubuyla yapılandırılmışsa çıktıda sunucu adresi yerine grup adı görünebilir; bu durumda sunucunun 10.0.30.11 olduğunu display dhcp server group ile ayrıca kontrol edin. Relay, VLANIF arayüzünde dhcp select relay ve dhcp relay server-ip ile, DHCP de global olarak dhcp enable ile açılır (S serisi V200R011C10 yapılandırma kılavuzu). Sunucu grubu kullanımı ve display dhcp server group komutu Huawei’nin AR V200R010 IP servisleri kılavuzunda anlatılır.

Cisco Catalyst 9800 ve Meraki

Catalyst 9800, nerede ayarlanır: VLAN ve forwarding bilgisi policy profile’da durur. Local mode AP’de istemci DHCP’si CAPWAP tüneliyle controller’a taşınır ve controller tarafından iletilir (central switching). FlexConnect local switching’de AP, DHCP isteğini doğrudan yanındaki hop’a bırakır; bu durumda istemci VLAN’ının flex profile’da tanımlı olması ve AP’nin switch portunda, yerel VLAN AP yönetim VLAN’ı olacak şekilde trunk’ta izinli olması gerekir.

Neye bakılır:

show wireless client mac-address <MAC> detail
show wireless client summary
show wireless vlan details

İstemci durumu kimlik doğrulamayı geçmiş ama IP Learn aşamasında takılı kalmışsa, sorun DHCP yolundadır; IP aldığında durum Run’a geçer. Ayrıntılı iz için Cisco’nun RadioActive trace’i istemci MAC’ine göre başlatılır:

debug wireless mac <MAC>

Policy profile’daki ipv4 dhcp required ayarı açıksa, istemcinin DHCP’den adres alması zorunludur. Cisco’ya göre bu durumda önceki bir SSID’nin VLAN’ından kalma adresi isteyen istemciye controller NAK döner. Bu davranış, “başka ağdan gelince bağlanamıyor” türü şikâyetlerde akılda tutulmalıdır.

Meraki, nerede ayarlanır: SSID’nin istemci IP atama modunda. DHCP akışı moda göre tamamen değişir:

• Bridge modu: İstemci adresini kablolu taraftaki DHCP sunucusundan alır; VLAN etiketi kullanılabilir. Yukarıdaki karar ağacı aynen geçerlidir.
• NAT modu: Adresi Meraki AP’nin kendisi, 10.0.0.0/8 aralığından verir. VLAN etiketi kullanılamaz; relay ve sunucu adımları geçerli değildir.
• Layer 3 roaming (concentrator ile): İstemci trafiği bir tünelle mobility concentrator’a taşınır; Discover kablolu ağa concentrator’dan çıkar. Tunnel moduna benzer düşünülmelidir.

Meraki’de bakılacak yer dashboard’daki istemci ayrıntısı ve olay kayıtlarıdır.

HPE Aruba Networking (AOS 10)

Nerede ayarlanır: WLAN profilinin forwarding modunda. AOS 10’da üç mod vardır:

• Bridge: AP istemci trafiğini kendi uplink’inden istenen VLAN’la bırakır; VLAN AP’nin kablolu uplink’inde bulunmalıdır. Kimlik doğrulayıcı AP’dir; VLAN ve rol kararını AP verir.
• Tunnel: AP istemci trafiğini birincil gateway kümesine tüneller; VLAN o kümede bulunmalıdır. Kimlik doğrulayıcı gateway’dir.
• Mixed: AP, istemcinin VLAN’ına göre trafiği bridge ya da tunnel eder: VLAN gateway kümesinde varsa tünellenir, yoksa bridge edilir. Bu mod, bridge ve tunnel istemciler için ayrı VLAN’lar ister.

Aruba’nın dokümanına göre bir WLAN profilinin forwarding modu kaydedildikten sonra değiştirilemez. Bu yüzden “Discover nereden çıkıyor?” sorusunun cevabı profilin oluşturulduğu anda belirlenmiştir. Mixed modda ise cevap istemciye göre değişir: aynı SSID’deki iki istemcinin DHCP yolu farklı olabilir. AOS 10 için CLI komutlarını bu yazıda doğrulayamadığımızdan vermiyoruz; istemcinin durumu, VLAN’ı ve rolü yönetim arayüzündeki istemci ayrıntısından izlenir.

Fortinet (FortiGate + FortiAP)

Nerede ayarlanır: SSID’nin trafik modunda:

• Tunnel: İstemci trafiği FortiGate’e tünellenir ve FortiGate’te SSID adıyla bir arayüz oluşur. Erişim switch’inde yalnızca yönetim VLAN’ı gerekir; DHCP bu SSID arayüzünde FortiGate’in kendisi ya da tanımlı bir relay ile verilir.
• Local bridge: FortiAP istemci trafiğini bağlı olduğu switch portuna bırakır; izinli VLAN’ın erişim switch’inde tanımlı olması gerekir. DHCP kablolu taraftan gelir. FortiWiFi cihazları local bridge modunu desteklemez.

Neye bakılır:

diagnose wireless-controller wlac -d sta online
diagnose wireless-controller wlac sta_filter <MAC> 1
execute dhcp lease-list <arayüz>

İlk komut bağlı istemcileri ve IP adreslerini listeler; IP alanı boş kalan istemci DHCP adımında takılıdır. İkincisi tek bir istemcinin bağlantı adımlarını filtreler. Üçüncüsü, DHCP’yi FortiGate veriyorsa o arayüzdeki kiraları gösterir. Local bridge modunda DHCP mesajları FortiGate’in istemci debug’ında görünmez; kablolu taraftaki VLAN arayüzünde ya da gateway’de aranmalıdır.

Karşılaştırma

Sonuç

AP’nin online olması bir kontrol düzlemi başarısıdır. İstemcinin IP alması ise veri düzlemi başarısıdır ve tamamen başka bir yoldan geçebilir. Arızayı çözmenin anahtarı DHCP sunucusuna değil, Discover paketinin izlediği yola bakmaktır: önce forwarding modu, sonra VLAN, relay, havuz ve dönüş yolu. Meraki NAT modu gibi AP’nin kendisinin adres dağıttığı modlarda ise bu yolun büyük kısmı hiç yoktur.

Serinin bir sonraki yazısında bir adım geriye gidiyoruz: AP hiç online olmuyorsa ne yapılır?

Kaynaklar

• Huawei: WLAN AC V200R010C00 Command Reference, display vap-profile
• Huawei: AR V200R010, Configuring a DHCP Relay Agent (sunucu grubu)
• Huawei: S1720/S2700/S5700/S6720 V200R011C10, DHCP relay example
• Cisco: Troubleshoot DHCP Client Connectivity Issues on Catalyst 9800 WLC
• Cisco: Troubleshoot Catalyst 9800 Client Connectivity
• Meraki: SSID Modes for Client IP Assignment
• HPE Aruba Networking: AOS 10 traffic forwarding modes
• Fortinet Community: SSID Local bridge vs Tunnel mode
• Fortinet Community: How to troubleshoot wireless station connection issues
• Fortinet: FortiAP 7.4.4 configuration guide, station verification
• Fortinet Community: DHCP address leases on a FortiGate