Wi-Fi Bağlı Ama İnternet Yok: DNS, Gateway ve Firewall Analizi

Kullanıcının bildirimi kısa: “Wi-Fi’ye bağlıyım ama internet yok.” Yönetim ekranında ise her şey yolunda görünür:

• AP online, SSID yayında.
• İstemci bağlı ve 10.0.20.x adresini almış.
• Ama sayfalar açılmıyor; Windows “İnternet yok” diyor.

Bu noktada kablosuz tarafın işi büyük ölçüde bitmiştir. AP’nin ağa katılmasını AP Online Olmuyor, istemcinin adres almasını AP Online Ama İstemci IP Alamıyor yazısında ele aldık; bu tabloda ikisi de başarılı. İnternete çıkış artık başka bir zincire bağlı: gateway, yönlendirme, firewall politikası ve NAT. DNS bu zincirin yanında ayrı bir bağımlılıktır.

Bu yazıda arızanın hangi halkada olduğunu tahminle değil, testlerle ve paket yakalamayla göstermeyi hedefliyoruz. 802.1X ve captive portal ayrıntıları serinin ilerleyen yazılarında.

Senaryo

AP Online Ama İstemci IP Alamıyor yazısındaki kampüs devam ediyor; bu yazı için firewall bağlantısı ekleniyor.

VLAN 20’de ACL yazısındaki PERSONEL-IN listesi duruyor: 10.0.30.11’e DNS’i, 70. kuralla da internete giden trafiği izinli kılıyor. Örnek istemci 10.0.20.25; testlerde ad için example.com, IP için 1.1.1.1 kullanıyoruz. WAN tarafındaki 203.0.113.0/24 adresleri RFC 5737 ile yalnızca dokümantasyon için ayrılmıştır; gerçek internette WAN adresi olarak kullanılamaz.

Forwarding modu: Yazıdaki yol bridge (local) forwarding içindir. AP istemci trafiğini VLAN 20 etiketiyle erişim switch’ine bırakır; ilk L3 durak core’daki SVI’dır. Tunnel modunda trafik önce controller’a (Huawei AC, Catalyst 9800 local mode), Aruba AOS 10’da gateway’e, Fortinet’te doğrudan FortiGate’e taşınır. İlk L3 durak ve ilk filtre o cihaz olur. Testler değişmez; değişen, yakalamanın yapılacağı yerdir. Forwarding modlarının ayrıntısı DHCP yazısında.

“Bağlı” ile “internet var” aynı şey değil

“İnternet yok” uyarısı neyi ölçer?

İşletim sistemindeki uyarı bir testin sonucudur. Windows’un NCSI bileşeni www.msftconnecttest.com/connecttest.txt adresine HTTP isteği gönderir ve “Microsoft Connect Test” içeriğini bekler. Windows 11’de bu HTTP testi her zaman kullanılır; DNS yalnızca test sunucusunu bulmaya yarar. Yanıt farklıysa ya da yönlendirme (302) dönüyorsa NCSI ağın bir captive portal (hotspot) arkasında olduğunu varsayar.

Bu yüzden uyarı bir ipucudur, kanıt değil. Test adresleri kurumsal politikayla engellenmişse ya da trafik proxy’den geçiyorsa uyarı internet çalışırken de çıkabilir. Microsoft da test sunucularını sabit IP adresiyle izinli kılan firewall kurallarının testi bozabileceği konusunda uyarır. Teşhis aşağıdaki testlerle yapılır.

Paketin yolu: istemciden internete ve geri

Gidiş: İstemci 1.1.1.1’in kendi ağında olmadığını görür ve paketi gateway’e gönderir. Bunun için önce 10.0.20.1’in MAC adresini ARP ile öğrenir. Core switch paketi varsayılan rotayla 10.0.254.2’ye iletir. Firewall politikayı kontrol eder, kaynak adresi 10.0.20.25’ten 203.0.113.1’e çevirir (SNAT) ve paketi ISP’ye gönderir.

Dönüş: Yanıt 203.0.113.1’e gelir ve firewall’daki session ile eşleşir. Hedef adres geri çevrilir; firewall paketi 10.0.0.0/16 rotasıyla core’a, core da VLAN 20’ye verir. Dönüş rotası eksikse ya da yanıt başka bir yoldan geliyorsa stateful firewall paketi düşürür (asimetrik yönlendirme).

DNS: İstemcinin sorgusu 10.0.30.11’e gider ve firewall’dan geçmez. Ama DNS sunucusunun dış dünyaya sorduğu sorgular firewall’dan geçer. “DNS çalışmıyor” gibi görünen bir sorunun kaynağı, sunucunun kendi internet yolu olabilir.

Önce istemci: dört değer

ipconfig /all                  (Windows)
ip route get 1.1.1.1           (Linux: hangi gateway ve arayüz kullanılacak)
resolvectl status              (Linux: arayüz başına DNS sunucuları)

Seçenekler, DHCP yazısında anlatılan havuzla aynı yerde tanımlanır. Elle adres girilmiş istemci ayrı bir tuzaktır. DHCP snooping ve DAI açık bir ağda kaydı olmayan statik adresin ARP paketleri düşer (L2 yazısı); istemci “bağlı” görünür ama gateway’e bile ulaşamaz. Cihazdaki VPN istemcisi ya da proxy ayarı da aynı belirtiyi verebilir; ağa geçmeden önce bunları dışlayın.

DNS mi, erişim mi? Dört test

ping 10.0.20.1                                (ardından: arp -a)
Test-NetConnection 1.1.1.1 -Port 443
nslookup example.com 10.0.30.11
nslookup example.com 1.1.1.1

1. Gateway: Ping yanıtı ya da ARP tablosunda 10.0.20.1 için bir MAC adresi, istemcinin ilk L3 durağa ulaştığını gösterir. SVI’da ICMP kapatılmış olabilir; bu yüzden ARP kaydı ping’den daha güçlü bir bulgudur.
2. IP ile erişim: TcpTestSucceeded : True sonucu, bu akış için rota, politika ve NAT’ın çalıştığını gösterir. Test bilerek bir IP adresine yapılır; DNS denklemden çıkar. Ping yerine TCP 443 kullanılır, çünkü birçok politika web trafiğine izin verip ICMP’yi kapatır. Ping’in başarısız olması tek başına erişim olmadığını kanıtlamaz.
3. İç DNS: nslookup adı ikinci parametredeki sunucuya sorar. Hiç yanıt yoksa ya 10.0.30.11’e ulaşılamıyordur (ACL, rol) ya da DNS servisi çalışmıyordur. Sunucu yanıt veriyor ama hata dönüyorsa, sunucuya ulaşılmış ama sunucu dışarıyı çözememiştir.
4. Dış DNS: Kurumsal ağların çoğu istemcilerin doğrudan dış DNS’e çıkmasını bilerek engeller; DNS’i iç sunucuda toplamak loglama ve filtreleme içindir. Bu test başarısızsa önce politikayı sorun; bu beklenen sonuç olabilir. Başarılıysa ve 3. test başarısızsa sorun iç taraftadır: DNS sunucusunun kendisi olabileceği gibi 10.0.30.11’e giden yol, ACL ya da kullanıcı rolü de olabilir. Bu test teşhis içindir; istemcilere dış DNS dağıtmak bir çözüm değildir.

Gateway ve yönlendirme

Core switch’te üç şey kontrol edilir:

• SVI ve ARP: VLAN 20’nin SVI’ı çalışıyor ve 10.0.20.1/24 adresine sahip mi? Core’un ARP tablosunda istemcinin kaydı var mı? Kayıt varsa istemci gateway’e ulaşmıştır.
• Varsayılan rota: 0.0.0.0/0 → 10.0.254.2 rotası tabloda aktif mi? Rota tabloda olsa bile next hop’un (10.0.254.2) ARP kaydı çözülmüyorsa paket iletilemez.
• SVI ACL’i: PERSONEL-IN listesinden 70. kural kaldırılırsa DNS (40 ve 50. kurallar) çalışır, internet çalışmaz. Belirti “DNS var, internet yok”tur ve arıza firewall’a hiç ulaşmaz.

Firewall tarafında dönüş rotası unutulur. Yeni bir kullanıcı ağı 10.0.0.0/16 dışında bir adresle açılmışsa yanıt core’a dönemez. tracert -d 1.1.1.1 yolun nerede kesildiğine dair ipucu verir. Firewall’lar çoğu zaman traceroute’a yanıt vermediği için sonuç bir bulgudur, hüküm değildir.

Firewall: politika, NAT, profiller ve loglar

Teste bir trafik üretin (istemciden 1.1.1.1:443) ve firewall’da aynı akışı sırayla izleyin:

1. Politika: Kaynak adres nesnesi 10.0.20.0/24’ü kapsıyor mu? Kural sırası doğru mu? Örtük ret (implicit deny) loglanıyor mu? Loglanmıyorsa reddedilen trafik hiç iz bırakmaz.
2. Session: Session hiç yoksa paket firewall’a hiç gelmiyordur ya da politika veya rota yüzünden reddediliyordur. Session var, ileri sayaç artıyor, geri sayaç sıfırsa yanıt gelmiyordur.
3. NAT: Session’daki çevrilmiş kaynak adres 203.0.113.1 mi? Değilse SNAT kuralı eşleşmiyordur. Özel adresle internete çıkan paketin yanıtı geri dönmez.
4. Güvenlik profilleri: Web filtresi, DNS filtresi, IPS ya da uygulama kontrolü bağlantıya izin verip içeriği engelleyebilir. Belirti çoğu zaman engelleme sayfası, sıfırlanan bağlantı ya da DNS filtresinin döndürdüğü farklı bir yanıttır. Loglarda politika numarası ile profil eylemi birlikte okunur.
5. Paket yakalama: Aynı akış firewall’un iç (④) ve dış (⑤) arayüzünde yakalanır.

Yakalama bir bulgudur, hüküm değil. Donanımsal hızlandırma (offload) kullanan firewall’larda trafik yakalamada görünmeyebilir. Dış arayüzdeki filtre özgün adresle (10.0.20.25) yazılırsa NAT’lı paket yakalanmaz; filtre 203.0.113.1 ya da hedef adresle yazılmalıdır. Tek bir paket de sonuç değildir. Her bulgu session tablosu ve loglarla doğrulanmalıdır.

WLAN tarafındaki kısıtlar

Trafik firewall’a hiç ulaşmıyor ve core’da da bir sorun yoksa sıradaki şüpheli kablosuz tarafın kendi politikasıdır:

• SSID ACL’i ya da kullanıcı rolü: Bağlantı sırasında istemciye uygulanan politika internete giden trafiği AP’de, controller’da ya da gateway’de düşürebilir. Firewall loglarında iz yoksa ilk bakılacak yer burasıdır. RADIUS’un döndürdüğü rol ve VLAN için NAC yazısına bakın.
• Misafir ağı: VLAN 60’ta iç ağa giden trafiği engelleyen kural doğru tasarımdır (segmentasyon). Misafire iç DNS dağıtılmışsa bu kural DNS’i de kesebilir; kuralın DNS’e istisna tanıyıp tanımadığı platforma göre değişir.
• Captive portal: Doğrulamadan önce istemci genellikle yalnızca DHCP, DNS ve portala erişebilir. Portal açılmazsa sonuç “bağlı ama internet yok”tur. Ayrıntılar serinin captive portal yazısında.

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ı. Doğrulayamadığımız komutları vermiyoruz; o noktalarda nereye bakılacağı yazılı.

Huawei

Core’daki S serisi switch’te varsayılan rota ve istemcinin ARP kaydı:

display ip routing-table 0.0.0.0
display arp all | include 10.0.20.25

Rotanın next hop’u 10.0.254.2 olmalıdır. Komut biçimleri S1720/S2700/S5700/S6720 V200R011C10 (ARP) ve S9300 V200R019C10 (yönlendirme tablosu) dokümanlarındandır.

USG firewall’da session tablosu:

display firewall session table verbose

verbose çıktısında ileri (-->) ve geri (<--) paket sayaçları, eşleşen politika (PolicyName) ve --> sonrasında köşeli parantez içinde NAT sonrası adres görünür. Huawei’nin sorun giderme kılavuzuna göre session hiç yoksa üstteki cihazlar ve rotalar, güvenlik politikası reddi ve saldırı koruması kontrol edilir. Komut kaynak, hedef, politika ve zone filtreleriyle daraltılabilir.

AC tarafında SSID’ye uygulanan ACL ve kullanıcı izolasyonu komutlarını bu yazı için doğrulayamadık. Bakılacak yer, VAP profiline bağlı profillerdir.

Cisco Catalyst 9800, Secure Firewall ve Meraki

Catalyst 9800: İstemcinin hangi policy profile’a düştüğü:

show wireless client mac-address <MAC> detail

VLAN ve istemciye uygulanan politika bu profilde durur. Cisco istemci durumlarını IP Learn, Webauth Pending ve Run olarak ayırır. Webauth Pending’de kalan istemci web doğrulamasını (captive portal) bekliyordur; trafiği bu aşamada kısıtlıdır.

Catalyst core switch:

show ip route 0.0.0.0

Secure Firewall Threat Defense: Cisco’nun aracı packet-tracer, sanal bir paketi firewall’un işlem aşamalarından (rota, erişim kuralı, NAT) geçirir ve her aşamanın sonucunu gösterir:

show route 0.0.0.0
packet-tracer input inside tcp 10.0.20.25 55555 1.1.1.1 443
capture cin interface inside trace match ip host 10.0.20.25 host 1.1.1.1
capture cout interface outside match ip host 203.0.113.1 host 1.1.1.1
capture asp type asp-drop match ip host 10.0.20.25 host 1.1.1.1

inside ve outside cihazdaki mantıksal arayüz adlarıdır. Dış yakalama NAT sonrası adresle (203.0.113.1) yazılır. asp-drop yakalaması, firewall’un düşürdüğü paketleri gösterir. packet-tracer bir simülasyondur; gerçek trafiği gösteren yakalamayla birlikte okunmalıdır. Komutlar Cisco’nun FTD 7.6.5 üzerinde hazırlanmış belgesindendir.

Meraki MR: SSID’nin Layer 3 firewall kuralları durumsuzdur (stateless), yukarıdan aşağı okunur ve ilk eşleşen uygulanır; hiçbiri eşleşmezse varsayılan kural her şeye izin verir. Layer 7 kuralları uygulama ya da kategori bazında engeller. Misafir SSID’ler için önerilen “Deny Local LAN” kuralı RFC 1918 adreslerini kapsar; Meraki’ye göre DNS ve DHCP bu kuraldan muaftır, NAT modunda yalnızca DNS muaftır. Bakılacak yer, SSID’nin ve varsa grup politikasının firewall ve traffic shaping ayarlarıdır.

HPE Aruba Networking (AOS 10)

AOS 10’da politika kullanıcı rolüne bağlıdır. Her WLAN profili için otomatik bir varsayılan rol oluşur; RADIUS ya da Central NAC başka bir rol döndürebilir. Dönen rol yoksa varsayılan rol uygulanır. Rol erişim kurallarını, VLAN’ı ve captive portal ayarını taşıyabilir.

Bridge forwarding’de roller AP’nin yapılandırma grubunda, tunnel forwarding’de gateway’de de tanımlanır. Aruba’nın tasarım belgesi, global istemci rolleri için DHCP ve DNS gibi temel servislere izin veren oturum ACL’leri (SACL) atanması gerektiğini belirtir. Hangi rol olursa olsun DNS izni eksikse sonuç bu yazının belirtisidir: adres var, ad çözümü yok. Bakılacak yer, Central’da istemciye atanan rol ve rolün kurallarıdır. AOS 10 AP ve gateway CLI komutlarını bu yazı için doğrulayamadık.

Fortinet (FortiGate + FortiAP)

Tunnel moddaki SSID: FortiGate’te SSID adıyla bir arayüz oluşur ve istemci DHCP’yi çoğu zaman bu arayüzden alır. İnternete çıkış için SSID arayüzünden WAN’a ayrı bir firewall politikası gerekir; Fortinet’in FortiAP 7.4.4 rehberindeki örnekte bu politikada NAT açıktır. Politika yoksa istemci adres alır ama internete çıkamaz: bu yazının belirtisi tam olarak budur. Local bridge modunda trafik switch ve core üzerinden gelir; politika iç arayüzden WAN’a yazılır.

Akışın FortiGate içindeki yolunu debug flow gösterir:

diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter saddr 10.0.20.25
diagnose debug flow filter daddr 1.1.1.1
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable

Çıktıda find a route seçilen gateway’i ve çıkış arayüzünü, Denied by forward policy check hiçbir politikanın eşleşmediğini gösterir. allocate a new session yeni session oluştuğunu belirtir. Bitirmek için diagnose debug disable ve diagnose debug reset kullanılır.

Aynı akışı arayüzler üzerinde görmek için sniffer:

diagnose sniffer packet any "host 1.1.1.1" 4 0 l

Ayrıntı seviyesi 4, paketin hangi arayüzden girip çıktığını gösterir. Aynı paketin iç arayüzde 10.0.20.25, WAN’da 203.0.113.1 kaynağıyla görünmesi SNAT’ın çalıştığını gösterir.

Offload sınırı: Fortinet’in donanım hızlandırma belgesine göre NP işlemcisine offload edilen trafik sniffer’da görünmez. Session’ın offload edilip edilmediği diagnose sys session list çıktısındaki npu info alanından anlaşılır. Teşhis için ilgili politikada set auto-asic-offload disable ile offload geçici olarak kapatılabilir; iş bitince yeniden açılmalıdır.

Karşılaştırma

Sonuç

“Bağlı” ve “IP var”, internetin yalnızca ön koşullarıdır. Sonrası bir zincirdir: gateway, yönlendirme, politika, NAT ve yanında DNS. Arızayı hızlı bulmanın yolu DNS’i denklemden çıkaran bir IP testiyle başlamak, sonra aynı akışı halka halka izlemektir. “İnternet yok” uyarısı da bir paket yakalaması da tek başına hüküm değildir; her bulgu bir başka testle doğrulanmalıdır.

Kaynaklar

• Microsoft: NCSI frequently asked questions
• Microsoft: Test-NetConnection
• Microsoft: nslookup
• Debian: ip-route(8)
• man7: resolvectl(1)
• Huawei: S1720/S2700/S5700/S6720 V200R011C10, Checking ARP Entries
• Huawei: S9300 V200R019C10, Displaying and Maintaining an IP Routing Table
• Huawei: USG6000/USG9500 V500, V600 Troubleshooting Guide, Checking the Session Table
• Cisco: Troubleshoot Catalyst 9800 Client Connectivity
• Cisco: Catalyst 9800 common troubleshooting
• Cisco: show ip route
• Cisco: IP Routing Protocol-Independent Command Reference (IOS XE 17)
• Cisco: Troubleshoot Traffic Issues on Secure Firewall CLI
• Meraki: MR Firewall Rules
• Meraki: Deny Local LAN settings in MR firewall
• HPE Aruba Networking: AOS 10 roles, fundamentals
• Fortinet: FortiAP 7.4.4, Configuring WPA2-Personal security
• Fortinet Community: Debug flow tool
• Fortinet Community: First steps to troubleshoot connectivity (sniffer ve debug flow)
• Fortinet: FortiOS 7.6.5, Checking that traffic is offloaded by NP processors