Risk boyutu	Ne anlama gelir?	Pratik örnek
Performans	Yük artışı hizmeti yavaşlatabilir	Yoğun tarama router CPU’yu zorlar
Süreklilik	Kesinti veya veri kaybı	Yanlış hedefe müdahale kritik sistemi etkiler
Gizlilik / Uyumluluk	Veri sızıntısı, KVKK/regülasyon ihlali	Log/pcap’te kişisel veri; saklama ve erişim kuralları

Yoğunluk; tekrar sayısı, zaman aralığı, veri miktarı ve eşzamanlılık gibi faktörlerle oluşan toplam yüktür. Sınır koymadan “mümkün olan en hızlı” şekilde çalıştırmak, canlı sistemlerde tahmin edilemeyen sonuçlara yol açabilir.

• Prensip: Önce düşük yoğunlukla başla, gözle, sonra karar ver.
• “Pilot doğrulama” yaklaşımı: kısa süre, düşük yük, net amaç.

Risk örneği: Masum görünen bir kontrol; yoğun yapılırsa cihazları yorabilir, log/depoma maliyetini büyütebilir, hatta hizmeti etkileyebilir.

“Önce zarar verme” yaklaşımı ağ çalışmaları için esastır.

• Üretim sistemlerinde belirsiz etkili denemeler yapılmaz.
• Gereksiz veri toplanmaz.
• Yetkin olunmayan alanda “deneyeyim” yaklaşımı tercih edilmez.
• Mümkünse önce test ortamında doğrulanır, sonra üretime uygulanır (staging/dev → production farkındalığı).

Kill-switch, “işler kötüleşirse” anında durma ve kontrollü geri çekilme planıdır.

Giriş seviyesi kill-switch planı:

• Stop conditions listesi (yavaşlama, hata artışı, beklenmeyen etki)
• Yetkili iletişim (kime haber verilecek?)
• Geri dönüş (yakalamayı durdurma, erişimi kısıtlama, veriyi güvenli saklama)
• Kayıt (durma anı ve gerekçesi rapora girecek)

Veri minimizasyonu, amaca ulaşmak için gereken en az veriyi toplamaktır. “Her şeyi kaydedeyim, sonra bakarız” yaklaşımı hem depolama hem gizlilik hem de raporlama kalitesi açısından risk taşır.

• Bazı sorunlarda tüm içerik (payload) gerekmez; çoğu durumda başlık bilgileri, zaman damgaları ve özet metrikler yeterlidir.
• İçerik toplamak zorunluysa; saklama, erişim ve maskeleme kuralları önceden tanımlanır.

Pratik soru: “Bu veri, hangi hipotezi doğrulamak için şart?” Cevap veremiyorsan veri büyük olasılıkla gereksizdir.

Log saklamak; “dosyayı bir klasöre atmak” değildir.

Asgari disiplin:

• Nerede saklanıyor? (güvenli konum)
• Kim erişebilir? (yetki)
• Ne kadar süre saklanacak? (retention)
• Paylaşım varsa maskeleme/redaksiyon nasıl?

Kanıt bütünlüğü; “bu dosya ilk aldığım dosyanın aynısı” diyebilme yeteneğidir.

• Hash: dosyanın parmak izi (örn. SHA-256)
• Saklama: güvenli yerde korunması
• Erişim kayıtları: kim, ne zaman erişti?
• Chain of custody: kanıtın kimden kime geçtiği ve hangi işlemlerden geçtiği

Basit chain of custody şablonu:

• Kanıt ID: E-001
• Kaynak: “Router log export” (temsili)
• Alınma zamanı: (tarih-saat)
• Alan kişi/rol: (ör. “Analist”)
• Hash: SHA-256: …
• Saklandığı yer: (güvenli yol)
• Transfer: (kim aldı, ne zaman)

Terim	Açıklama
Hash	Dosyanın parmak izi (örn. SHA-256)
Chain of custody	Kanıtın kimden kime geçtiği ve hangi işlemlerden geçtiği
Erişim kayıtları	Kim, ne zaman erişti?

Bölüm	Ne içerir?	Kime hitap eder?
Bulgu	Gözlenen gerçek (yorum değil)	Herkes
Etki	İş / operasyon / güvenlik etkisi	Karar verici, yönetici
Öneri	Yapılabilir düzeltme veya azaltım	Uygulayıcı ekip
Kanıt	Log, ekran görüntüsü, hash, zaman, bağlam	Teknik doğrulama, denetim

Standart format

• Bulgu: Gözlenen gerçek (yorum değil)
• Etki: İş/operasyon/güvenlik etkisi
• Öneri: Yapılabilir düzeltme/azaltım
• Kanıt: Log satırı, ekran görüntüsü, hash, zaman damgası, bağlam notu

• Yönetici özeti: teknik olmayan karar vericiler için; risk/etki/öneri netliği
• Teknik ek: komut çıktıları, log satırları, zaman çizelgesi, kanıt ID'leri; tekrar edilebilirlik

Araçlar veya savunma sistemleri bazen “şüpheli/illegal” benzeri uyarılar üretebilir.

• Yetkili test bağlamında bu tür uyarılar, savunma mekanizmalarının çalıştığını gösterebilir: “hata” değil, gözlem olabilir.
• İzinli hedef dışında böyle bir uyarı alıyorsan; bu, kapsam dışına taşmış olabileceğinin güçlü sinyalidir: derhal dur ve bildir.

Senaryo: Yetkili bir çalışmada (yazılı izin var), “ağ yavaşlığı” şikâyetini incelerken trafikte hassas içerik barındırabilecek bir akış fark ediyorsun (ör. şifresiz e-posta trafiği ve içinde şirketle ilgili kritik bilgiler olabileceğine dair göstergeler).

Nasıl düşünmelisin?

• Kapsam: Görevin “yavaşlığı” incelemek. İçerikleri okumak çoğu durumda kapsam değildir.
• Veri minimizasyonu: İçeriği kaydetmek yerine; yalnızca yoğunluk, kaynak/hedef, zaman ve protokol gibi problemle ilişkili minimum veriyi not etmek daha güvenlidir.
• Raporlama: Kişi isimlerine veya kesin ithamlara girmeden, teknik sınırda kal: “Şu kaynaktan yüksek hacimli ve hassas içerik riski taşıyan şifresiz trafik gözlendi” gibi.
• Escalation: RoE’de tanımlı kanaldan yetkili birime ilet (güvenlik/uyumluluk/BT). Bu, hem etik hem hukuki güvence sağlar.

Veri bir yerden bir yere giderken “yol”, “kurallar” ve “bağlantı noktaları” gerekir. Ağ, bu düzenin tamamıdır. Ağın ortaya çıkışındaki temel ihtiyaçlar üç başlıkta toplanır:

Senaryo	Ağ olmasaydı	Ağ ortamında
Ev	İnternet hattı tek cihaza giderdi	Wi-Fi ile telefon, tablet, TV aynı bağlantıyı paylaşır
Okul	Dosya tek tek USB ile dağıtılırdı	Ortak klasör veya portal ile tüm sınıf aynı anda erişir
Kurum	Veri her çalışanın diskinde dağınık olurdu	Veriler merkezi sunucuda; erişim kontrolü ve yedekleme yönetilebilir

Ağ türlerini ölçeğe göre düşünmek, kapsam ve gecikme (latency) beklentisini netleştirir. Ölçek büyüdükçe genelde gecikme artar, altyapı karmaşıklaşır ve yönetim farklılaşır.

Tür	Ölçek	Örnek	Teşhiste ipucu
PAN	Birkaç metre	Bluetooth kulaklık, akıllı saat	Tek cihaz çifti; diğer ağlar etkilenmez
LAN	Oda, ev, bina	Ev Wi‑Fi, ofis ağı	“Kaç kişi etkilendi?” → ortak nokta (router/AP)
MAN	Kampüs, şehir	Üniversite ağı, belediye ağı	Kurum/operatör tarafı; yerel LAN’dan sonraki halka
WAN	Şehirler / ülkeler	İnternet, kurumsal VPN	Yerel kanıt tamamsa “dışarı çıkış” veya uzak hedef

Aynı fiziksel altyapı üzerinde “kime ne açık?” sorusu, internet / intranet / extranet ayrımını getirir. Bu ayrım özellikle “bu site neden açılmıyor?” veya “sadece kurum içinde çalışıyor” gibi şikâyetleri yorumlarken işe yarar.

• Internet: Herkese açık, küresel ağ. Erişim için genelde sadece bağlantı ve gerekirse abonelik yeterlidir. “İnternet yok” dediğimizde çoğu zaman dış dünyaya (internet) çıkışın kesildiğini kastederiz.
• Intranet: Sadece kurum içi yetkililere açık ağ veya servisler. Örnek: Şirket portalı, iç dosya sunucusu, dahili e-posta. Intranet kaynaklarına dışarıdan (internet üzerinden) doğrudan erişim olmaz; VPN veya özel erişim gerekebilir.
• Extranet: Seçilmiş dış paydaşlara (tedarikçi, iş ortağı, müşteri) kontrollü erişim sunan ağ. Hem “dışarı” hem “sınırlı”: Herkese açık değildir ama sadece kurum içi de değildir.

Gerçek hayatta belirti: “Evde internet var, ofiste yok” veya tam tersi → farklı ağ türü (LAN) ve farklı çıkış noktası. “Kurum portalına evden giremiyorum” → portal intranet’te olabilir; VPN veya yetkili erişim gerekir. “Bir site açılıyor, diğeri açılmıyor” → hedefler farklı (biri intranet, biri internet) veya firewall/DNS farkı olabilir.

Network topolojisi, ağın fiziksel (kablolar/cihazlar nasıl bağlandı?) veya mantıksal (trafik hangi yolları izliyor?) dizilişidir. Bir mimarın bina planı çizmesi gibi, ağ okuryazarlığı da topolojiyi zihinde canlandırmayı gerektirir.

Topoloji, kablo maliyetinden arıza anındaki davranışa kadar her şeyi etkiler: Kablolama ve kurulum ne kadar pahalı? Bir kablo koptuğunda veya bir cihaz düştüğünde kaç kişi etkilenir? Ağı büyütmek veya arıza yerini bulmak ne kadar kolay? Bu sorulara yanıt, topolojiye göre değişir. Aşağıda her topoloji türünü yapı, avantaj/dezavantaj ve gerçek hayat örneğiyle paragraf halinde bulacaksınız.

Tüm cihazlar tek bir ana hat (backbone/omurga) üzerine bağlanır; klasik tasarımlarda hattın uçlarında sinyali sonlandıran elemanlar bulunur. Tarihsel olarak kablolama maliyeti düşüktü çünkü tek bir ortak hat kullanılıyordu. Buna karşılık ana hat koptuğunda iletişim geniş bir kesimi etkiler ve arıza yerini tespit etmek zorlaşabilir.

Günümüz modern ofis LAN’larında saf bus nadirdir; yine de “tek hat üzerinde paylaşım” mantığı bazı özel veya eski (legacy) ortamlarda kavramsal olarak karşınıza çıkabilir. Teşhiste: Aynı omurgayı paylaşan geniş bir grubun aynı anda kopması bus hipotezini destekler; sadece tek bir uç cihazın etkilenmesi ise bus yapısına göre zayıf bir işarettir.

Cihazlar kapalı bir halka oluşturacak şekilde birbirine bağlanır; veri halka üzerinde dolaşır. Bazı tasarımlarda sırayla iletimi düzenleyen “token” benzeri yaklaşımlar kullanılır. Belirli tasarımlarda düzenli akış ve net bir omurga mantığı sağlar; ancak yedeklilik yoksa tek bir kopma tüm döngüyü bozabilir. Dual-ring gibi yedekli tasarımlar bu riski azaltır.

Şehir ölçeğinde bazı fiber omurga ağlarında halka mantığıyla karşılaşılır: trafik halka üzerinde dolaşır, bir nokta koptuğunda (yedeksiz yapıda) zincirleme etki görülebilir. Teşhiste: Bir kopmanın geniş kesimi etkilemesi ve belirli bir noktadaki arızanın “döngüyü” kesmesi ring hipotezini destekler; alternatif yol olmadığı halde kesintinin hiç yansımaması ise ring düşüncesini zayıflatır.

Tüm cihazlar merkezi bir noktaya (çoğunlukla switch, bazen hub) ayrı bağlantılarla bağlanır. Ev, ofis ve sınıf ağlarının büyük kısmı pratikte bu yıldız mantığını taşır. Avantajı nettir: Bir uç kablo koptuğunda genelde sadece o uç etkilenir ve arıza tespiti nispeten kolaydır. Dezavantajı ise merkez cihazın “tek nokta arızası” (Single Point of Failure) oluşturmasıdır; merkez düşerse çok sayıda kullanıcı aynı anda etkilenir.

Gerçek hayatta tipik örnek şöyledir: Ofiste bir kişi “internet yok” derken yan masadaki kişi sorunsuz çalışıyorsa, yıldız yapısında bu durum çoğu zaman “o masaya giden bağlantı veya port” hipotezini güçlendirir. Tersine herkes aynı anda çıktıysa merkez cihaz veya merkezin dışarı çıkışı (uplink) düşünülür. Etki alanı merkez–uç mantığıyla uyuşmayan dağınık bir örüntü gösteriyorsa tek başına topoloji yetmeyebilir; başka faktörler de araştırılır.

Mesh topolojide cihazlar birden fazla yolla birbirine bağlıdır. Full mesh’te her cihaz herkesle doğrudan bağlıdır (maksimum yedeklilik, fakat maksimum maliyet); pratikte daha çok partial mesh kullanılır ve sadece kritik noktalar birden fazla bağlantıya sahip olur. Avantajı, bir yol kapandığında iletişimin alternatif yol üzerinden sürebilmesidir. Dezavantajı ise maliyet ve yönetim karmaşıklığının artmasıdır.

Kablosuz mesh ev sistemlerinde bu mantık somutlaşır: Bir düğüm zayıfladığında veya geçici olarak düştüğünde “tam kopma” yerine genelde “kalite düşüşü ama devam” davranışı görülür; trafik başka düğümler üzerinden yönlendirilir. Teşhiste: Tek bir bağlantı bozulduğunda iletişimin tamamen kesilmemesi ve “başka yoldan” devam etmesi mesh yedekliliğini destekler. Tek bir kesintinin her şeyi durdurması ise ya mesh yedekliliğinin olmadığını ya da ortak bir nokta arızasını düşündürür.

Gerçek ağlarda çoğu zaman birden fazla topoloji bir arada kullanılır: Örneğin katlar yıldız mantığıyla tek bir switch’e bağlıyken, katlar arası veya binalar arası omurga halka (ring) veya başka bir yapı olabilir. Bir okulda sınıflar star ile switch’e bağlıyken, binalar arası bağlantı farklı bir omurga ile kurulmuş olabilir.

Teşhiste “sorun nerede başlıyor, nerede bitiyor?” sorusu kritiktir. Sorun sadece belirli bir sınıfta veya tek katta görülüyorsa, hibrit yapının o alt parçası (örneğin o katın switch’i veya o sınıfın kabloları) etkilenmiş olabilir. Tüm kampüs veya tüm bina aynı anda etkileniyorsa, yerel alt parça yerine ortak omurga veya ortak çıkış (internet/gateway) olasılığı güçlenir.

Topoloji karşılaştırma tablosu (hızlı karar)

Özellik	Bus	Star	Mesh	Ring	Hybrid
Kurulum maliyeti	Düşük	Orta	Çok yüksek	Orta/Yüksek	Değişken
Tek kablo kopması etkisi	Geniş etki olabilir	Genelde tek uç	Genelde tolere eder	Yedeksizse geniş etki	Etki alanına bağlı
Genişletilebilirlik	Zor	Kolay	Zor/karmaşık	Orta	Orta
Arıza tespiti	Zor	Kolay	Karmaşık	Orta	Kapsama bağlı
Tipik kullanım	Özel/legacy	Ev/ofis/okul LAN	Kritik omurga/yedeklilik	Özel omurga	Gerçek dünya karışık

Veri iletiminde iki temel birim vardır: Bit (b) 0 veya 1 değerini alır; ağ hızları neredeyse her zaman bit cinsinden ifade edilir (Mbps, Gbps). Byte (B) ise 8 bitten oluşur; dosya boyutu ve depolama çoğunlukla byte ile ifade edilir (MB, GB). Karışıklık buradan doğar: Servis sağlayıcı “100 Mbps” dediğinde bu “saniyede 100 megabit” anlamına gelir, “saniyede 100 megabyte” değil. Teorik üst sınır yaklaşık 100 ÷ 8 ≈ 12,5 MB/s’dir; pratikte protokol ek yükleri ve ortam koşulları nedeniyle bu değerin altında kalırsınız.

Veri ağda tek parça halinde dolaşmaz; parçalara bölünerek taşınır. Packet (paket), ağlar arası taşınan ve adresleme bilgisi taşıyan veri parçası olarak düşünülebilir — kargo kutusu benzetmesi: içinde ne gideceği ve nereye gideceği yazar. Frame (çerçeve) ise yerel iletimde “hat üzerinde fiziksel olarak taşınan” birimdir; kargo kamyonu gibi, bir segment içinde paketi taşır. Bu ayrımın sistematik karşılığı katmanlı mimaride (Modül 6) netleşecek; burada amaç terimleri doğru bağlamda duymak ve frame ile packet’i karıştırmamaktır.

Bu metrikler ağın “nabzını” oluşturur; “yavaş” gibi belirsiz ifadeler yerine hangi metriğin bozulduğunu bilmek teşhisi kolaylaştırır.

Bandwidth (bant genişliği) birim zamanda taşınabilecek maksimum veri miktarını (kapasite) ifade eder; yolun şerit sayısına benzetilebilir. Büyük dosya transferlerinde süreyi doğrudan etkiler. Throughput (gerçek aktarım) ise pratikte elde ettiğiniz hızdır; bandwidth teorik üst sınırken throughput çoğunlukla daha düşüktür. Aynı iş yükünde yoğun saatlerde düşüş görüyorsanız paylaşım veya darboğaz (bottleneck) olasılığı artar; tek cihazda ve boş zamanda da düşükse uç veya bağlantı sorunu daha olasıdır.

Latency (gecikme), bir isteğin gidip gelme süresi hissidir; sıklıkla RTT (Round Trip Time) olarak ölçülür. Web sayfasının ilk açılma süresi veya oyunda komutun geç işlemesi latency ile ilgilidir. Jitter gecikmenin ne kadar dalgalandığını (istikrar) gösterir; ses veya video görüşmelerinde robotik ses ve kesiklik jitter veya paket kaybı belirtisidir. Packet loss (paket kaybı) ise gönderilen bazı paketlerin hedefe ulaşmamasıdır; video donması, görüşmede kopmalar ve TCP yeniden iletimleri nedeniyle “yavaşlık” hissi yaratabilir.

Metrik	Ne ölçer?	Belirti örneği
Bandwidth	Kapasite (max veri/saniye)	Büyük dosya çok uzun sürüyor
Throughput	Gerçek aktarım hızı	“100 Mbps aldım” ama hız düşük
Latency / RTT	Gidip gelme süresi	Tıklayınca geç tepki, oyunda gecikme
Jitter	Gecikmenin oynaklığı	Ses/video robotik, kesik
Packet loss	Kayıp paket oranı	Video donuyor, görüşme düşüyor

Kullanıcı “yavaş” veya “kesiliyor” dediğinde hangi metriğe bakacağınızı belirlemek önemlidir. Büyük dosyalar yavaş indiriliyorsa önce throughput ve bandwidth düşünülür. Tıklayınca sayfa geç açılıyorsa veya oyunda komut gecikmeli işleniyorsa önce latency (RTT) kontrol edilir. Ses veya videoda robotik ses, kesiklik veya donma varsa jitter ve paket kaybı ön plandadır. “Bazen iyi bazen kötü” davranışında ise jitter, darboğaz veya kablosuz parazit gibi değişken faktörler akla getirilir.

Bu bölüm, metrikleri “adıyla duymak” yerine çıktıda görmeye giriş sağlar. Komutlar yalnızca kendi ağında / izinli ortamda ve teşhis amacıyla kullanılmalıdır.

1) Latency ve Packet Loss gözlemi: ping
ping, karşı tarafa küçük bir istek gönderip yanıt süresini ölçer; paket kaybı yüzdesini özetleyebilir.

Komut (Windows / Linux / macOS): ping example.com

Beklenen çıktı türü (örnek, temsili): time=18ms gibi değerler: gecikme; “Lost = 0%” gibi özet: kayıp yok; “Request timed out”: cevap gelmedi (kayıp olabilir ya da ICMP engellenmiş olabilir).

Yorum ipucu (kritik satır): time değerlerinin sürekli yüksek olması → latency problemi ihtimali; time değerlerinin çok dalgalı olması → jitter ihtimali; Lost > 0 → packet loss ihtimali.

2) Yol üzerinde gecikme nerede artıyor? tracert / traceroute (giriş)
Bu komutlar paketin geçtiği ara durakları kabaca gösterir. Windows: tracert example.com — Linux/macOS: traceroute example.com. Amaç: Gecikme evden çıkarken mi artıyor, yoksa daha ileride mi? Bu modülde hedef, sadece “rota diye bir kavram var” farkındalığıdır.

Troubleshooting mini senaryosu (yerel/izinli, saldırı/tarama yok)
Belirti: Bir çalışan “Toplantıda sesim robotlaşıyor ve kesiliyor, ama büyük dosyayı indirirken hızım iyi” diyor. Olasılık: Bandwidth/throughput “kısmen yeterli” olabilir; problem daha çok jitter ve/veya packet loss ile uyumlu. Doğrulama (güvenli): Belirtiyi metriğe çevir: “Robotik ses” → jitter/loss aday. Basit gözlem: ping example.com ile 1–2 dakika izleyip time dalgalanmasına ve timeout/kayıp işaretlerine bak. Karşı kanıt düşün: time stabil ve kayıp yoksa, sorun başka yerde olabilir (ör. uygulama/cihaz). Sonuç: “Hız” değil “kalite” problemi çerçevesi güçlenir.

Belirti	Önce düşünülecek metrik
Büyük dosyalar yavaş	Throughput / bandwidth
Tıklayınca geç tepki	Latency
Ses/video robotik, aralıklı	Jitter ve/veya packet loss
Her şey bazen iyi bazen kötü	Jitter, darboğaz, kablosuz parazit

SOHO’da tipik akış (mantıksal harita):

• ISP hattı
• Modem/ONT veya ISP gateway
• Router/Gateway (evin “çıkış kapısı”)
• Dağıtım — Kablolu: LAN portları / ek switch — Kablosuz: Wi-Fi (SSID)
• İstemciler: telefon, laptop, TV, konsol, yazıcı, IoT

Gerçek hayatta belirtisi/örneği nedir?

• Telefon Wi-Fi’a bağlı ama internet yok: Kablosuz bağlantı (yerel) var; “dışarı çıkış” (gateway/ISP) tarafı problemli olabilir.
• Kablolu çalışıyor ama Wi-Fi çalışmıyor: Sorun dağıtımın kablosuz kısmında olabilir (SSID/şifre/sinyal/AP rolü).
• Sadece bir cihaz internete çıkamıyor: Uç cihaz tarafı daha olasıdır (yanlış ağa bağlanma, IP alamama, adaptör/ayar).

Nasıl doğrularım/çürütürüm? (güvenli) Katmanlı düşünmeyi 4 soruyla otomatikleştir:

• Bağlantı var mı? (Wi-Fi bağlı mı, kablo takılı mı?)
• IP aldım mı? (IP/gateway görüyor muyum?)
• Gateway’e ulaşabiliyor muyum? (yerel ping)
• Dış dünyaya çıkabiliyor muyum? (dış IP/alan adı testi)

Evde uzak köşelerde çekim zayıfladığında iki yaygın yaklaşım vardır. Tekrarlayıcı (repeater / range extender) var olan Wi‑Fi sinyalini alıp yeniden yayınlar; pratikte çoğu senaryoda toplam performansı düşürebilir ve odalar arasında dolaşırken cihazın bağlantı değiştirmesi (roaming) hissedilebilir. Mesh sistemleri ise birden fazla düğümü (node) tek bir ağ gibi çalıştırır; cihazlar arasında daha akıllı geçiş hedeflenir ve düğümler arası iletişim için ayrı bir taşıma (backhaul) mantığı kullanılabilir.

Kapsam sorusu: Tek cihaz mı etkileniyor? → uç cihaz/bağlantı/yanlış ağ. Herkes mi? → ortak nokta (gateway, ISP, güç). Sadece Wi-Fi mı / sadece kablo mu? → dağıtım katmanını daraltırsın.

İlk soru: Fiziksel veya kablosuz bağlantı gerçekten kurulmuş mu ve hangi ağa (SSID/vLAN) bağlıyım? Yanlış SSID’ye bağlıysan — örneğin misafir ağı veya kapalı bir test ağı — “internet yok” şaşırtıcı değildir; bu yüzden teşhisin ilk adımı “hangi ağdayım?” olmalıdır.

• Windows: netsh wlan show interfaces — Wi-Fi bağlı mı, hangi SSID, sinyal düzeyi (Signal), kanal (Channel). “State” connected ise bağlantı var; SSID satırı hangi ağa bağlı olduğunu gösterir.
• Linux: nmcli dev status — Cihazların (Wi-Fi/Ethernet) durumu: connected, disconnected, unavailable. nmcli connection show --active — Aktif bağlantı adı ve arayüz. Kablolu için ip link ile arayüzün state UP olup olmadığına bakılır.
• macOS: networksetup -getairportnetwork en0 — Hangi Wi-Fi ağına (SSID) bağlıyım? (en0 genelde Wi-Fi; cihaza göre farklı olabilir.) Menü çubuğundaki Wi-Fi simgesi de hızlı doğrulama sağlar.

Bağlantı “var” görünse bile cihaz IP alamamış olabilir; bu durumda üst katmanlar (internet, DNS) çalışmaz. Bu adımda amaç: IPv4/IPv6 adresi var mı? Varsayılan ağ geçidi (default gateway) tanımlı mı?

• Windows: ipconfig /all — IPv4 Address, Subnet Mask, Default Gateway, DHCP Enabled. IP yoksa veya 169.254.x.x (APIPA / link-local) görüyorsan cihaz DHCP’den IP alamamış veya statik atama yok demektir; “internet yok” bu yüzden de olabilir.
• Linux: ip a (veya ip addr) — inet satırları adres ve prefix’i verir; ip route veya ip r — “default via …” satırı varsayılan ağ geçidini gösterir. Default route yoksa subnet dışına çıkış tanımlı değildir.
• macOS: ifconfig — inet (IPv4), inet6 (IPv6); netstat -rn — Yönlendirme tablosunda “default” satırı ve gateway sütunu.

IP ve gateway “var” görünüyorsa bir sonraki mantıksal adım ulaşılabilirliktir: Önce yerel ağ geçidine, sonra (isteğe bağlı) dış bir IP’ye, en sonda isimle (DNS’i dahil etmek için) test edebilirsin.

• Gateway’e ping (kendi default gateway adresinle): Yerel ağ geçidine ulaşabiliyor muyum? Yanıt geliyorsa L3’e kadar yol yerelde açık demektir. Gelmiyorsa sorun kablo/Wi-Fi, switch veya gateway tarafında olabilir.
• Dış IP’ye ping (ör. 8.8.8.8): DNS’e takılmadan “dışarı çıkış” var mı? Başarılıysa sorun büyük olasılıkla DNS veya uygulama tarafındadır.
• Ping example.com (veya başka alan adı): İsim çözülüyor mu? “Host bulunamadı” veya “could not find host” → DNS / isim çözümleme sorunu olasılığı yüksektir. Ping’in kendisi DNS kullanır; bu yüzden bu adım DNS’i devreye sokar.
• DNS ayrıntısı için: nslookup example.com (Windows/Linux/macOS), dig example.com (Linux/macOS) — Hangi sunucu yanıt veriyor, A/AAAA kaydı dönüyor mu, zaman aşımı mı var?

Gerçek hayatta belirti: “Wi-Fi çekiyor ama internet yok” → Önce SSID ve IP/gateway; sonra gateway’e ping. “Sadece bazı siteler açılmıyor” → DNS veya hedef servis; IP’ye ping atabiliyorsan DNS şüphesi artar. “Kabloda herkes çalışıyor, Wi-Fi’de çalışmıyor” → Bağlantı ve IP/gateway Wi-Fi arayüzü için ayrıca kontrol edilir.

Cihaz / Rol	Ana görevi	Teşhiste ipucu
NIC (Ağ kartı)	Cihazı ağa bağlayan arayüz	Link ışığı, sürücü, arayüz “up”
Switch	LAN içinde trafiği MAC’e göre dağıtır	Yerel cihazlar birbirini görüyor mu?
Router / Gateway	Ağlar arası yönlendirme, çıkış kapısı	IP/gateway var mı? Subnet dışına çıkış?
Access Point (AP)	Kablolu ağı Wi‑Fi’ye açar	SSID görünüyor mu? Sinyal var mı?
Modem / ONT	ISP hattını eve/ofise taşır	WAN ışığı, ISP kesintisi

Ne anlama gelir?

• Node (Düğüm): Ağa bağlı her türlü cihaz için genel isim. Bilgisayar, yazıcı, IP kamera, akıllı priz, sunucu… hepsi birer node’dur.
• NIC (Network Interface Card / Ağ Adaptörü): Uç cihazın ağa bağlandığı arayüzdür; fiziksel katmanda link sinyali buradan başlar.
• Hub (tarihsel): Bir porttan aldığı veriyi ayırt etmeden tüm portlara kopyalar. Güncel ağlarda neredeyse kullanılmaz; collision (çarpışma) riskini artırır ve verimsizdir.
• Switch: Yerel ağ (LAN) trafiğini yönetir; cihazların hangi porta bağlı olduğunu MAC adresleri üzerinden öğrenir ve trafiği çoğunlukla yalnızca ilgili porta iletir.
• Router / Gateway: Farklı ağları birbirine bağlayan “kapı”dır; karar verirken IP adresleri üzerinden yönlendirir. Ev ağını internete çıkaran tipik çıkış noktasıdır.
• Modem / ONT: Servis sağlayıcıdan gelen hattı (DSL/kablo/fiber) ev/ofis ağına taşır; sinyali “ağın anlayacağı forma” çeviren uçtur.
• Access Point (AP): Kablolu ağı (Ethernet) kablosuz sinyale (Wi-Fi) çevirir; kablosuz istemcileri ağa dahil eder. (Kablosuz detayları Modül 5’te ele alınır.)

Switch vs Router’ı hızlı ayırt etme mantığı:

• Switch: LAN içinde dağıtır, ana referansı MAC okuryazarlığıdır.
• Router: ağlar arasında geçiş sağlar, ana referansı IP okuryazarlığıdır.

Gerçek hayatta belirtisi/örneği nedir?

• “Wi-Fi çekiyor ama internet yok” → AP çalışıyor olabilir; gateway/ISP tarafı şüpheli.
• “Kablolu çalışan var, Wi-Fi çalışmıyor” → switch/LAN sağlıklı; AP/SSID tarafı şüpheli.
• “Sadece bu bilgisayar bağlanmıyor” → NIC/port/kablo veya uç cihaz durumları şüpheli.

Nasıl doğrularım/çürütürüm? (güvenli)

• Rol doğrulaması: Cihazda WAN/Internet portu var mı? LAN portu var mı? Wi-Fi yayınlıyor mu? Bu somut işaretler rolü netleştirir.
• Kapsam doğrulaması: Tek cihaz mı, herkes mi? Sadece Wi-Fi mı, sadece kablo mu?
• Katman sırası: “Link var mı?” (Fiziksel) → “IP var mı?” (IP katmanı) sırasını bozmadan ilerle.

Ne anlama gelir?

Kablo türü	Kullanım	Teşhiste ipucu
Twisted Pair (CAT5e/6/6A)	Ev/ofis Ethernet, 100 m civarı	Link ışığı, konnektör, ezilme/parazit
Fiber optik	Uzun mesafe, EMI’ye dayanıklı	Uç temizliği, kırılma, ışık kaynağı
Koaksiyel	Modem/erişim altyapısı	Konnektör, sinyal seviyesi

Temel bağlantı aileleri:

• Twisted Pair (Bakır Ethernet kabloları): Ev/ofiste en yaygın. CAT5e: Tipik kullanımda 1 Gbps sınıfında yaygındır. CAT6 / CAT6A: Daha yüksek hedef hızlar ve daha iyi parazit dayanımı için tercih edilir. Saha sınırı (kavramsal): Bakır Ethernet’te “standart mesafe” yaklaşımı çoğunlukla 100 metre civarında düşünülür; mesafe artınca attenuation (zayıflama) etkisi belirginleşir.
• Fiber optik: Veriyi elektrikle değil ışıkla taşır. Avantaj: Uzun mesafe, elektromanyetik parazite (EMI) yüksek bağışıklık (ör. fabrika ortamı, güçlü motorlar). Dezavantaj: Kırılganlık, temizlik/sonlandırma hassasiyeti.
• Koaksiyel: Bazı erişim altyapılarında görülür (modem tarafı gibi).
• Kablosuz (radyo sinyali): Fiziksel katmanın “sinyal” boyutuna dahildir; ayrıntı ve pratik teşhis Modül 5’te.

Gerçek hayatta belirtisi/örneği nedir?

• Temassızlık: “Bazen var, bazen yok” (intermittent) kopmalar; masayı oynatınca kesilme.
• Ezilme/hasar: Link gelir ama hız düşer; yüksek trafikte kısa kopmalar/yeniden bağlanmalar görülebilir.
• Parazit (EMI): Özellikle güç kablolarına yakın güzergâhlarda dalgalı performans.
• Fiber uç kirliliği: Linkin hiç gelmemesi veya stabilite sorunları.

Nasıl doğrularım/çürütürüm? (güvenli)

• Karşılaştırmalı test: Aynı port + farklı kablo → kablo şüpheli mi? Aynı kablo + farklı port → port şüpheli mi?
• En az müdahale ilkesi: Fiziksel şüphe varken ağ ayarlarını “kurcalamak” yanlış maliyet doğurur.
• Araç kanıtı: Basit kablo test cihazı (varsa) tel çiftleri/kopukluk gibi somut sinyal verir.

Kablo tipi	Açıklama	Ne zaman kullanılır?
Düz (straight-through)	İki uç aynı standart (A–A veya B–B)	PC–switch, router–switch, yaygın patch
Çapraz (cross-over)	Uçlar farklı standart (A–B)	Tarihsel; modern cihazlarda Auto-MDIX ile çoğu zaman gerekmez

Ne anlama gelir?

• T568A / T568B: Tel dizilim standartlarıdır.
• Pratikte kritik kural: Aynı kablonun iki ucu tutarlı olmalıdır.
• İki ucu da aynı standarda göre → çoğu senaryoda “düz (straight-through/patch)” mantığı.
• Uçlar farklı standart → “çapraz (cross)” mantığı (tarihsel kullanım daha yaygındı).

Split pair (kritik hata örüntüsü): Renkler “doğru gibi” görünse bile tel çiftleri bozulduysa kablo kısa mesafede çalışıyor gibi görünüp hız düşürebilir, paket kaybı/yeniden iletim gibi belirtiler doğurabilir.

Auto-MDI/MDI-X ve Auto-MDIX (kavramsal): Modern cihazların önemli bir kısmı düz/çapraz kablo ayrımını otomatik tolere edebilir. Bu, “her hata tolere edilir” anlamına gelmez; sahada en sağlam yaklaşım doğru sonlandırma + tutarlılıktır.

Gerçek hayatta belirtisi/örneği nedir?

• Yeni krimplenmiş kabloyla link gelmiyor → sonlandırma hatası olasılığı artar.
• Link var ama hız düşüyor → split pair/temas zayıflığı gibi fiziksel kalite sorunları olabilir.
• “Her kablo çalışıyor ama bu çalışmıyor” → önce kablo/sonlandırma rasyonel adaydır.

Nasıl doğrularım/çürütürüm? (güvenli): Kablo test cihazı (varsa) en net kanıttır: tel sırası ve kopukluk sinyali verir. Bilinen sağlam kablo ile karşılaştır: Aynı uç cihaz/aynı portta sağlam kablo çalışıyorsa sorunu hızla daraltırsın. Gözle kontrol: Konnektörde tel sırası, kablonun konnektöre yeterli girişi ve çene baskısı düzgün mü?

Ne anlama gelir?

• Link: İki uç arasında fiziksel bağlantının kurulduğuna dair sinyal.
• Hız (Speed): Linkin anlaştığı kapasite.
• Duplex: İletişimin iki yönlü çalışma biçimi. Half duplex: Aynı anda tek yön (tarihsel hub dünyasında tipik). Full duplex: Aynı anda iki yön (modern switch dünyasında standart yaklaşım).
• Auto-negotiation: Cihazların “en yüksek ortak” hız/duplex üzerinde otomatik anlaşması.

Collision domain (kavramsal): Hub kullanılan tarihsel yapılarda aynı ortamı paylaşan cihazlar aynı anda konuşursa collision olurdu. Modern switch’te her port çoğunlukla kendi “yolunu” ayırdığı için çarpışma riski dramatik biçimde azalır; pratikte her switch portu ayrı bir collision domain gibi düşünülür.

Gerçek hayatta belirtisi/örneği nedir?

• Link var ama dosya aktarımı yavaş → link hızı beklenenden düşük anlaşmış olabilir.
• “Bir anda 1 Gbps yerine 100 Mbps görünüyor” → auto-negotiation düşük hıza düşmüş olabilir (kablo kalitesi/temas).
• Link ışığı yanıyor ama sık kopuyor → kablo/port kalitesi veya temas problemi.

Nasıl doğrularım/çürütürüm? (güvenli): Link hızı kanıtı: İşletim sistemi “Link Speed” gibi bir alan gösterebilir (GUI/komut). Hızlı daraltma: GUI’den link ve link hızına bak. Kesinleştirme: Komutla arayüz durumunu ve (varsa) link ayrıntılarını al; sonra kablo/port karşılaştırması yap.

Rol	Taraf	Örnek
PSE	Güç sağlayan	PoE switch, PoE enjektör (injector)
PD	Güç alan cihaz	Erişim noktası (AP), IP kamera, IP telefon

Ne anlama gelir?

Temel roller: PSE: PoE sağlayan taraf (PoE switch veya PoE enjektör). PD: PoE alan cihaz (AP/kamera vb.).

Kritik pratik: PoE bütçesi. Switch’in toplam sağlayabileceği güç sınırlıdır; cihaz sayısı arttıkça bütçe yetmeyebilir.

Gerçek hayatta belirtisi/örneği nedir? AP kabloyla bağlı görünüyor ama açılmıyor → PoE yok/yetersiz olabilir. Bazı PoE cihazları çalışıyor, yenisi çalışmıyor → bütçe dolmuş olabilir. PoE enjektör yanlış yere/yanlış hatta → veri varmış gibi görünüp cihaz açılmayabilir.

Nasıl doğrularım/çürütürüm? (güvenli): PoE kanıtı: Switch arayüzü (varsa) portun PoE verdiğini/çektiğini gösterebilir. Karşılaştırmalı test: Bilinen PoE çalışan port/kablo ile dene. Güvenli sınır: PoE elektrik taşır; rastgele pin müdahalesi yapma, standart ekipman kullan.

GUI araçları “kolay yol” değil, hızlı kanıt toplama yöntemidir. Fiziksel katman sorunlarında GUI genelde şu bilgileri hızlı verir: Adaptör etkin mi? (Enabled/Disabled) Link var mı? Link hızı (gösteriliyorsa) Hata işareti var mı (sürücü/donanım)? Windows: Ağ Bağlantıları — Bağlı/bağlı değil, etkin/devre dışı. Aygıt Yöneticisi — Ağ bağdaştırıcısında uyarı işareti var mı? macOS: Ağ ayarlarında arayüz durumları bazen “bağlı / IP alamıyor / kablo yok” gibi sinyallerle gösterilebilir. Linux: NetworkManager arayüzleri bağlantı/arayüz durumunu hızlı özetler.

Gerçek hayatta: Kullanıcı “kablo takılı” der, GUI “Disconnected” gösterir → fiziksel katman önceliklidir. GUI “Disabled” gösterir → sorun kablo değil, arayüz kapalı olabilir.

Hızlı kanıt kaynakları: Port LED’leri (link/activity); Kablo/port değişimi (“Böl ve yönet”in pratik hali); OS komutlarıyla arayüz durumu: Up/down, link ipuçları.

Komut & araç okuryazarlığı (güvenli, yerel): Windows: ipconfig /all — “Media disconnected” → link yok (kablo/port). netsh interface show interface — Arayüz etkin mi, bağlı mı? Linux: ip link — UP/DOWN. ethtool <arayüz_adı> (varsa) — Link detected, hız. macOS: ifconfig, networksetup -listallhardwareports — Hangi arayüz gerçek ethernet?

Troubleshooting mini senaryosu (yerel/izinli): Belirti: “İnternetim çok yavaş, dosya kopyalarken bekliyorum.” Olasılık: Auto-negotiation düşük hıza düşmüş olabilir (kablo/temas). Doğrulama: GUI’de Link Speed’e bak; kablo/port değişimi ile karşılaştır. Kısa rapor: Bulgu → Link hızı beklenenin altında; kablo değişimiyle normale dönüyor. Etki → Dosya aktarımı düşüyor. Öneri → Patch kabloyu değiştir; güzergâhı kontrol et. Kanıt → Link Speed gözlemi + karşılaştırmalı test.

Ne anlama gelir? Giriş seviyesinde ezber hedefi yok; aşağıdaki eksenler yeterli:

Bantlar (2.4 / 5 / 6 GHz):

• 2.4 GHz: Daha iyi duvar geçişi/menzil eğilimi; ancak daha kalabalık ve parazite açık (Bluetooth, bazı IoT, mikrodalga vb. etkileyebilir).
• 5 GHz: Daha yüksek kapasite/hız; duvar/mesafe etkisi daha belirgin olabilir (aynı odada harika, iki duvar sonra keskin düşüş görülebilir).
• 6 GHz: Daha “ferah” kanal alanı hedefi; fakat daha yüksek frekans olduğu için kapsama/duvar hassasiyeti artabilir. 6 GHz erişimi pratikte Wi-Fi 6E ile yaygınlaştı; hem erişim noktası hem istemci desteği gerekir.

Kanal genişliği (20/40/80/160 ve yeni nesilde daha geniş seçenekler): Geniş kanal teorik olarak daha yüksek kapasite demektir; ama ortam kalabalıksa geniş kanal “daha çok çakışma” anlamına da gelebilir (yanlış pozitif hız beklentisi üretir).

Cihaz yeteneği (anten sayısı, desteklenen nesil/bant, sürücü kalitesi, güç tasarrufu): Aynı SSID’de bir cihaz çok hızlıyken diğeri yavaşsa, çoğu zaman fark istemci yeteneğidir.

Gerçek hayatta belirtisi/örneği nedir? 2.4 GHz’te “çekiyor” görünür ama akşam saatlerinde dalgalanır → kalabalık/parazit olasılığı artar. 5 GHz’te aynı odada çok hızlıdır; 1–2 duvar sonra hız keskin düşer → frekans fiziği. Yeni router alındı ama eski laptopta fark az → istemci adaptörü sınırlı olabilir.

Nasıl doğrularım/çürütürüm? (güvenli): Doğrulama 1: Hangi bantta bağlıyım (2.4/5/6)? Doğrulama 2: Link/PHY rate o an ne? Karşı kanıt: Aynı noktada başka cihazla karşılaştır → sorun tek cihaz mı yoksa ortam mı?

Koşul	Soru	Teşhiste
İstemci	Telefon/laptop Wi‑Fi 7 destekliyor mu?	OS/adaptör özellikleri
AP/Router	Erişim noktası 802.11be destekliyor mu?	Cihaz veri sayfası / yönetim arayüzü
Ortam	Mesafe, duvar, kalabalık uygun mu?	RSSI, SNR, kanal

Ne anlama gelir? Bunun en kritik okuma biçimi “etiket” değil, destek zinciridir:

• İstemci (telefon/laptop) destekliyor mu?
• Erişim noktası (AP/router) destekliyor mu?
• Uygun bant/kanal koşulları var mı?
• Ortam (duvar/mesafe/kalabalık/parazit) uygun mu?

Wi-Fi 7 için sık duyacağın kavramlardan biri MLO (Multi-Link Operation)’dır: cihazların birden fazla bağlantıyı daha akıllı kullanarak kararlılık/gecikme açısından kazanım hedeflemesi. Ayrıca daha geniş kanal seçenekleri (uygun regülasyon ve donanım koşullarında) ve verimlilik iyileştirmeleri konuşulur.

Gerçek hayatta belirtisi/örneği nedir? Yeni router kuruldu ama eski cihazlarda fark az → istemci yeteneği zinciri kırıyor. Aynı SSID, iki odada çok farklı hız → nesil ne olursa olsun fizik baskındır.

Nasıl doğrularım/çürütürüm? (güvenli): İstemci yeteneğini OS üzerinden doğrula (desteklenen standartlar/bantlar). Bağlantı ayrıntılarını kaydet (band/kanal/RSSI/link). Karşı kanıt: Aynı noktada Wi-Fi 7 destekli olduğu bilinen başka cihazla kısa karşılaştırma.

Ne anlama gelir? Giriş seviyesinde en sık karşılaşılanlar:

• Bluetooth / BLE: kulaklık, saat, sensör, bazı IoT kurulumları
• NFC: “dokun-tetikle” (temassız ödeme/kimlik doğrulama)
• Zigbee/Thread (akıllı ev ekosistemleri): Wi-Fi yerine düşük güç/mesh yaklaşımı (saha farkındalığı düzeyi)
• UWB (ufuk): yakın mesafe konumlama/anahtarsız erişim senaryoları

Gerçek hayatta belirtisi/örneği nedir? Kulaklık odadan odaya giderken kopuyor → çoğunlukla Wi-Fi değil Bluetooth menzil/engel. IoT kurulumunda “yakındaki cihaz bulunamadı” → Wi-Fi’den önce Bluetooth/izin/menzil olasılığı.

Nasıl doğrularım/çürütürüm? (güvenli): Bağlantı türünü doğrula: uygulama/cihaz ekranında Wi-Fi mi PAN mi netleştir. Kapsamı doğrula: sorun sadece PAN cihazlarında mı, Wi-Fi cihazlarında da mı? Karşı kanıt: aynı PAN cihazını aynı ortamda başka telefonla dene (tek telefon/tek cihaz etkisi).

Gösterge	Anlamı	Örnek / yorum
RSSI (dBm)	Sinyal gücü	-30 güçlü, -80 zayıf; tek başına yeterli değil
Noise	Ortam gürültüsü	RSSI ile birlikte okunur
SNR	Sinyal–gürültü oranı	Kaliteyi daha iyi anlatır
Band / Channel	Bant ve kanal numarası	2.4 GHz’te 1, 6, 11 örtüşmez
Link rate	Anlaşılan fiziksel hız	İnternet hızı değil; bağlantı pazarlığı

Ne anlama gelir? Giriş seviyesinde hedef: şans denemek değil, görünmeyeni görünür kılmak.

Temel göstergeler:

• RSSI (dBm): sinyal gücü (ör. -30 çok güçlü, -80 zayıf)
• Noise: ortam gürültüsü (tek başına değil, RSSI ile birlikte okunur)
• SNR: sinyal–gürültü oranı (kaliteyi daha doğru anlatır)
• Band/Channel & kanal genişliği: ortam/çakışma yorumunu güçlendirir
• Link/PHY rate: internet hızı değildir; bağlantının o anki pazarlığıdır
• SSID/BSSID: aynı isimli ağda hangi AP’ye “yapıştığını” anlamak için

2.4 GHz kanal okuryazarlığı (giriş seviyesi pratik): 2.4 GHz’te 20 MHz kanal genişliğinde, pratikte en az çakışan klasik seçimler 1 / 6 / 11’dir.

Gerçek hayatta belirtisi/örneği nedir? “Çekiyor ama video donuyor” → RSSI orta görünse bile Noise yüksek olabilir (SNR kötü). “Kapıdan geçince hız uçtu” → band değişimi veya AP seçimi değişmiş olabilir. “Bir odada herkes yavaş” → o bölgede kanal kalabalığı/parazit/mesafe kanıtı aranır.

Komut & Araç Okuryazarlığı (güvenli, yerel): Windows: netsh wlan show interfaces (SSID/BSSID, Signal, Radio type, Channel), netsh wlan show drivers (adaptör yetenekleri). Linux: nmcli dev wifi, iw dev <arayüz> link. macOS: Option basılıyken Wi-Fi simgesine tıkla (RSSI, Noise, Tx Rate, Channel), system_profiler SPAirPortDataType.

Ne anlama gelir? Ağ iletişimi aynı anda çok fazla bileşen içerir: kablolar/elektrik sinyalleri veya radyo dalgaları, MAC ve IP adresleri, portlar, veri formatları ve uygulamalar… Bu kaosu yönetmek için mühendislikte “Böl ve Yönet (Divide and Conquer)” yaklaşımı kullanılır: Her katman kendi işini iyi yapar, üst katmana standart bir hizmet sunar.

Katmanlı düşünmenin temel kazanımları:

• Standartlaşma/uyumluluk: Ağ kartı üreticisi, tarayıcı yazan geliştiricinin detaylarını bilmez; herkes kendi katmanının standardına uyar.
• Değiştirilebilirlik: Alt katmandaki teknoloji değişse bile (ör. kablolu → kablosuz), üst katmandaki uygulamalar çoğu zaman aynı mantıkla çalışır.
• Troubleshooting: Sorunu izole etmeyi sağlar: “Kablo mu kopuk (L1), IP mi yanlış (L3), DNS mi bozuk (L7’ye yakın), yoksa uygulama servisi mi hatalı?”

Gerçek hayatta belirtisi/örneği nedir? Örnek: “Wi-Fi simgesi var ama sayfalar açılmıyor.” Bu tek cümle, birden çok katmana işaret edebilir: kablosuz kalite (L1’e yakın), IP alamama (L3), DNS (uygulama katmanına giden isim çözümleme akışı), uygulama tarafı servis sorunu… Örnek: “Kablo takılı ama bağlantı yok.” Bu daha çok alt katman sinyali verir: fiziksel bağlantı/arayüz durumu (L1/L2 sınırı).

Nasıl doğrularım/çürütürüm? (güvenli) Katmanlı bir soru setiyle ilerle: Fiziksel (L1): Link var mı? (kablo, bağlantı ışığı, arayüz “connected” durumu). Yerel iletim (L2): Aynı yerelde bir hareket var mı? (temel çerçeve trafiği). IP (L3): IP adresi var mı? Varsayılan ağ geçidi (gateway) tanımlı mı? DNS/uygulama (L7’ye yakın): İsim çözümleme çalışıyor mu? Uygulama servisi cevap veriyor mu?

Ne anlama gelir?

• L1 — Physical (Fiziksel): Görev: Bitlerin (0/1) taşınması; kablo/optik/radyo sinyali, konektörler. Sorun örnekleri: kopukluk, temassızlık, parazit. Veri birimi: Bit.
• L2 — Data Link (Veri Bağlantı): Görev: Yerel iletim; MAC adresleme, çerçeveleme; komşu cihaza teslim. Cihaz rolü: Switch, NIC (ağ kartı). Veri birimi: Frame (Çerçeve).
• L3 — Network (Ağ): Görev: Mantıksal adresleme (IP) ve ağlar arası iletim (routing mantığı). Cihaz rolü: Router. Veri birimi: Packet (Paket).
• L4 — Transport (Taşıma): Görev: Uçtan uca taşıma; TCP ile güvenilirlik / UDP ile düşük gecikme; port kavramıyla doğru servise teslim. Veri birimi: Segment (TCP) / Datagram (UDP).
• L5 — Session (Oturum): Görev: Uygulamalar arası diyaloğu başlatma, sürdürme, sonlandırma (örn. oturum zaman aşımı).
• L6 — Presentation (Sunum): Görev: Veri formatı, kodlama, sıkıştırma, şifreleme (örn. JPEG/MP3, TLS gibi) — “çevirmen” gibi.
• L7 — Application (Uygulama): Görev: Uygulama protokolleri (HTTP, DNS, SMTP vb.). Chrome/Outlook bu katman değil; bu protokolleri kullanan yazılımlardır.

Ezber yardımcısı (mnemonic): “Please Do Not Throw Sausage Pizza Away” — Physical, Data Link, Network, Transport, Session, Presentation, Application.

Katman	Veri birimi	Teşhiste tipik soru
L1 Physical	Bit	Link var mı? Kablo/Wi-Fi bağlı mı?
L2 Data Link	Frame	Yerel iletişim / MAC/ARP
L3 Network	Packet	IP/prefix/gateway tutarlı mı?
L4 Transport	Segment/Datagram	Port erişimi? Timeout/refused?
L5–L7	Uygulama verisi	DNS çözülüyor mu? Uygulama yanıtı?

Gerçek hayatta belirti: “Wi-Fi simgesi var ama sayfa açılmıyor” → L1 (sinyal) tamam olabilir; L3 (IP/gateway) veya L4/L7 (port, DNS, sunucu) şüpheli. “Kablo takılı ama link yok” → L1/L2; kablo, port veya NIC. “Ping atıyorum yanıt yok” → L2/L3 (yerel iletim veya IP yolu). Belirtiyi doğru katmana taşımak, bir sonraki kanıt adımını netleştirir.

Neden iki model? OSI yedi katmanlı bir referans modeli sunar; eğitim ve “hangi iş nerede?” tartışmalarında kullanılır. TCP/IP ise internetin gerçekte çalıştığı protokol yığınını dört katmanda toplar. Teşhis yaparken çoğu araç ve belirti TCP/IP katmanlarıyla ifade edilir; OSI ile eşleştirmek, “bu sorun fiziksel mi, veri bağlantısı mı, yönlendirme mi, taşıma mı, uygulama mı?” sorusunu netleştirir.

• TCP/IP Link (Ağ Erişimi) ≈ OSI L1 + L2: Fiziksel ortam (kablo, Wi‑Fi radyo) ve veri bağlantısı (Ethernet çerçevesi, MAC). “Kablo takılı mı? Link ışığı yanıyor mu? Wi‑Fi ağına bağlı mıyım?” bu katmana aittir.
• TCP/IP Internet ≈ OSI L3: IP adresleme ve yönlendirme. “IP aldım mı? Gateway doğru mu? Hedef aynı subnet’te mi?” soruları bu katmanda yanıt bulur.
• TCP/IP Transport ≈ OSI L4: Taşıma protokolleri (TCP, UDP) ve portlar. “Bağlantı kuruluyor mu? Port açık mı? Timeout mu refused mı?” L4 kanıtıdır.
• TCP/IP Application ≈ OSI L5 + L6 + L7: Pratikte “uygulama tarafı” birlikte düşünülür — oturum, sunum, uygulama protokolleri (HTTP, DNS, SSH vb.). “İsim çözülüyor mu? Uygulama yanıt veriyor mu?” bu katmana aittir.

TCP/IP katmanı	OSI karşılığı	Teşhiste tipik soru
Link	L1 + L2	Link var mı? MAC/ARP yerel mi?
Internet	L3	IP/prefix/gateway tutarlı mı?
Transport	L4	Port erişimi var mı? Timeout/refused?
Application	L5–L7	DNS çözülüyor mu? Uygulama yanıtı?

Belirtiyi katmana taşımak, gereksiz müdahaleleri azaltır ve doğru kanıtı toplamanı sağlar.

• “IP var ama site açılmıyor”: Internet (IP) katmanı çalışıyor olabilir; sorun Transport (port/bağlantı) veya Application (DNS, HTTP, sunucu yanıtı) tarafında olabilir. Sonraki adım: L4’te port erişimi ve DNS çözümlemesini kontrol etmek.
• “Wi‑Fi bağlı ama IP yok”: Link (L1/L2) var — ağa bağlı görünüyorsun; fakat Internet katmanı tamamlanmamış — DHCP’den IP alınamıyor veya statik atama eksik. Sorun L3’e girmeden önce L2 ve ardından DHCP/gateway tarafına bakılır.
• “Kablo takılı ama link yok”: Fiziksel veya veri bağlantısı (L1/L2) sorunu. Kablo, port, NIC veya karşı uç (switch/router) kontrol edilir.
• “Ping atıyorum, yanıt gelmiyor”: Ping hem L3 (IP) hem L2 (yerel iletişim) ile ilgilidir. Yerel gateway’e ping atmak “L3’e kadar yol var mı?” sorusuna kanıt üretir; dış bir IP’ye ping “çıkış ve L3 yönlendirme” hakkında bilgi verir.

Kısa özet: TCP/IP’de Link = fizik ve çerçeve; Internet = IP ve yönlendirme; Transport = TCP/UDP ve portlar; Application = protokoller ve uygulama. OSI’deki yedi katman bu dört blokla eşleşir; pratikte “sorun hangi blokta?” sorusunu yanıtlamak yeterlidir.

Encapsulation (kapsülleme): Gönderen tarafta veri üstten alta inerken her katman kendi “zarfını” (header, gerekirse trailer) ekler. Böylece bir alt katman, üstünden gelen veriyi “taşınacak yük” olarak görür ve kendi adresleme/kontrol bilgisini ekleyerek bir sonraki katmana veya fiziksel ortama iletir. Sonuç: Uygulama verisi en içte kalır; dışarı doğru L4, L3, L2 başlıkları sarar; en dışta fiziksel katmanda bitler iletilir.

Decapsulation (açma): Alıcı tarafta işlem tersine döner. Fiziksel katman bitleri alır, L2 çerçeveyi çıkarır, L3 paketi açar, L4 segmenti/datagramı işler ve nihayet uygulama verisi ilgili uygulamaya iletilir. Her katman yalnızca kendi “zarfını” bilir; içeriği bir üst katmana devreder.

• Payload (yük): Taşınan asıl veri. Bir katman için “payload”, bir üst katmanın gönderdiği tüm bloktur (header’ları dahil). Pratikte “içerik” veya “veri” diye düşünebilirsin.
• Header / Trailer: Katmanın eklediği yol tarifi ve kontrol bilgisi. Header genelde verinin başına, trailer (ör. Ethernet FCS) sonda eklenir. Her katman kendi header’ını okur; geri kalanını dokunmadan iletir veya üst katmana verir.
• PDU (Protocol Data Unit): Katmandaki veri biriminin adı. L4’te TCP için segment, UDP için datagram; L3’te packet; L2’de frame; L1’de bits. “Bu PDU hangi katmana ait?” sorusu teşhiste “sorun nerede?” sorusuna karşılık gelir.

Tarayıcı bir web isteği gönderiyor. Uygulama (L7) HTTP isteğini üretir. Bu veri L4’e (TCP) gider; TCP başlığı eklenir (kaynak/hedef port, sıra numarası, kontrol bilgisi) → Segment oluşur. Segment L3’e (IP) verilir; IP başlığı eklenir (kaynak/hedef IP, TTL, protokol numarası vb.) → Packet oluşur. Packet L2’ye (Ethernet) verilir; Ethernet başlığı ve (genelde) FCS trailer eklenir (kaynak/hedef MAC) → Frame oluşur. Frame fiziksel katmanda bitlere dönüştürülerek kabloya veya radyo ile ortama gönderilir.

Özet sıra: Data → Segment (L4) → Packet (L3) → Frame (L2) → Bits (L1). Alıcıda tam tersi: Bits → Frame → Packet → Segment → Data; her adımda ilgili header çıkarılır ve kalan kısım bir üst katmana devredilir.

Wireshark’ta tek bir paketi seçtiğinde “Packet Details” bölümünde katman benzeri bloklar görürsün: Frame (yakalama bağlamı, zaman, uzunluk — L1’e en yakın “kayıt” katmanı), Ethernet II (L2, MAC adresleri), Internet Protocol (L3, IP), TCP veya UDP (L4, portlar), ardından HTTP, DNS vb. (L7). Bu bloklar, encapsulation’ın somut izleridir; “bu pakette L3 var mı? L4’te hangi port?” gibi soruları satır satır yanıtlayabilirsin.

Kavram	Açıklama	Teşhiste
VLAN ID	Mantıksal ağ numarası (802.1Q tag)	Yanlış VLAN = aynı switch’te “görünmez”
Access port	Tek VLAN’a ait kullanıcı portu	Cihaz hangi VLAN’da?
Trunk port	Birden fazla VLAN taşıyan port (switch–switch)	Tag’li trafik; bu modülde konfig yok

Ne anlama gelir? VLAN, aynı switch veya aynı kablo hattı üzerinde “farklı mantıksal ağlar” oluşturma fikridir. Trafik, VLAN kimliği (VLAN ID) ile etiketlenir; switch’ler bu etikete göre hangi portlara ileteceğine karar verir. Böylece aynı fiziksel altyapıda birden fazla yayın (broadcast) alanı oluşur; bir VLAN’daki yayın diğer VLAN’lara geçmez (L3 yönlendirme olmadan).

VLAN tag (802.1Q): Ethernet çerçevesine 4 baytlık bir etiket eklenir; bu etiket “bu çerçeve hangi VLAN’a ait?” bilgisini taşır. Tag, çerçevenin kaynak MAC adresinden hemen sonra yer alır. Giriş seviyesinde sayısal yapıyı ezberlemek gerekmez; “çerçeve etiketli mi, VLAN ID kaç?” sorusunun varlığını bilmek yeterlidir.

• Broadcast alanlarını ayırır: Bir VLAN’daki broadcast, diğer VLAN’lara iletilmez (switch L2’de ayırır).
• Aynı fiziksel hat üzerinden birden çok VLAN taşınabilir: “Trunk” bağlantılarda çerçeveler etiketli gider; switch’ler etikete göre filtreler veya iletir.
• VLAN’lar arası iletişim için genelde L3 (IP) yönlendirme gerekir: Farklı VLAN’daki iki cihaz birbirine L2’de doğrudan erişemez; arada router veya L3 switch gerekir.
• Uç cihaza giden tipik “erişim (access)” portunda etiket genelde uç cihazın görmeyeceği şekilde çıkarılır; cihaz sadece “normal” Ethernet çerçevesi görür. Trunk tarafında ise etiketli trafik taşınır.

Gerçek hayatta belirtisi/örneği nedir?

• “Kablo takılı, bağlı görünüyor ama ağa çıkamıyor.” Sorun fiziksel değil; cihaz yanlış mantıksal ağa (yanlış VLAN) düşmüş olabilir. Bu tek açıklama değildir; kanıt gerekir (aynı cihaz farklı portta denendiğinde davranış değişiyor mu?).
• Aynı yerde iki porttan biri çalışıp diğeri çalışmıyorsa, fiziksel kalite aynı olsa da portların farklı VLAN’lara atanmış olması etkili olabilir.

Nasıl doğrularım/çürütürüm? (güvenli): Bu seviyede “ayar yapma” değil, kanıt desenini ararsın: Aynı cihazı farklı porta takınca davranış değişiyor mu? Aynı portta başka cihaz çalışıyor mu? OS tarafında IP var mı? (IP yoksa zaten L3’e çıkamıyorsun; yanlış VLAN olası nedenlerden biri olabilir ama tek başına kesin hüküm değildir.)

Adım	Ne yapılır?	Dikkat
Arayüz seçimi	Wi‑Fi mi Ethernet mi? Doğru arayüzü seç	Yanlış arayüz = trafik görünmez
Display filter	icmp, arp, ip.addr, dns, tcp.port	Odaklanmak için; sözdizimi araç dokümanında
Packet Details	Frame → Ethernet → IP → TCP/UDP → L7	Encapsulation’ı satır satır görürsün

Ne anlama gelir? Wireshark, ağ arayüzünden geçen trafiği yakalayıp paket/çerçeve ayrıntılarını okumaya yarayan bir paket analiz aracıdır. Kendi/izinli ortamda troubleshooting için görünürlük ve kanıt üretmek; Ders 6.4’te anlattığımız encapsulation (Data → Segment → Packet → Frame → Bits) sürecini gerçek paketlerde görmek için kullanılır.

Yakalama başlatıldığında Wireshark, seçtiğin ağ arayüzünden gelen/giden ham trafiği alır ve (varsayılan olarak) PCAP formatında saklar. Arayüz seçimi kritiktir: Sorun Wi-Fi üzerindeyse Wi-Fi arayüzünü, kablolu bağlantıdaysa Ethernet arayüzünü seçmelisin. Yanlış arayüzü seçersen ilgili trafiği hiç görmezsin; “burada trafik yok” yanıltıcı sonuç üretir. Birden fazla arayüz varsa (ör. Ethernet + Wi-Fi + sanal adaptörler) hangi arayüzün “aktif bağlantı” olduğunu ipconfig/ip a/ifconfig ile önceden netleştirmek iyi bir disiplindir.

Yakalanan paketler çok fazla olabilir; display filter, listelenen paketler arasında odaklanmanı sağlar. Örnekler: icmp — sadece ping (ICMP) trafiği; arp — ARP istek/yanıtları; ip.addr == 192.0.2.10 — Bu IP’yi kaynak veya hedef olarak içeren paketler; dns — DNS sorgu/yanıtları; tcp.port == 443 — HTTPS ile ilgili TCP trafiği. Bu modülde amaç tüm filtre sözdizimini ezberlemek değil; “hangi katmanda hangi bilgi var?” sorusunu paket detayında okuyabilmek ve gerektiğinde basit bir filtre yazabilmektir.

Bir pakete tıkladığında alt bölümde (Packet Details) katmanlar hiyerarşik görünür. Üstten alta doğru okuma, encapsulation’ı doğrular:

• Frame: L1’e yakın; yakalama zamanı, uzunluk, arayüz bilgisi.
• Ethernet II (veya 802.11 Wi‑Fi): L2 — Kaynak ve Hedef MAC adresleri; bazen VLAN tag.
• Internet Protocol (IPv4 / IPv6): L3 — Kaynak/hedef IP, TTL, protokol (TCP/UDP/ICMP vb.).
• Transmission Control Protocol / User Datagram Protocol: L4 — Kaynak/hedef port, sequence number (TCP), bayraklar.
• Hypertext Transfer Protocol, DNS, vb.: L7 — Uygulama protokolü; istek/yanıt içeriği (dikkat: şifreli trafikte payload okunamaz).

Örnek teşhis kullanımı: “Ping atıyorum ama yanıt gelmiyor” — Wireshark’ta icmp filtresi ile ICMP Echo Request gidiyor mu görülür; Reply gelmiyorsa arada engel veya hedef yanıt vermiyor olabilir. “DNS çözülmüyor” — dns filtresi ile sorgu gidiyor mu, yanıt dönüyor mu kontrol edilir.

Güvenli kullanım: Kısa ve kontrollü yakalama (ör. 20–40 saniye) tercih edilir; hassas veri (şifresiz parolalar, kişisel veri) riski azaltılır. Yalnızca kendi cihazında ve yetkili ağda, gerekli en kısa süreyle kullanılmalıdır. Yakalama dosyasını paylaşırken hassas bilgileri maskelemek veya paylaşmamak sorumluluk gerektirir.

Ne anlama gelir?

Adres	Soru	Kullanıldığı katman
IP	“Nereye?” (nihai hedef)	L3, ağlar arası yönlendirme
MAC	“Bu segmentte kime teslim?”	L2, yerel teslim (switch/NIC)

Kritik ayrım:

• IP adresi: “Nereye?” (ağlar arası yönlendirme mantığı)
• MAC adresi: “Bu yerel segmentte kime teslim edeceğim?” (komşuya teslim mantığı)

Bu yüzden MAC, “internetin öbür ucundaki adres” değildir. Paket ağlar arası giderken IP katmanı “nihai hedefi” temsil eder; fakat yerel iletimde her hop’ta yeni bir L2 zarf (frame) hazırlanır ve L2 adresleme (MAC) yerel teslimata göre güncellenir.

MAC adresinin yapısı (giriş seviyesi okuryazarlık): MAC çoğunlukla 48 bit (6 bayt) uzunluğundadır ve genellikle 00:1A:2B:3C:4D:5E biçiminde görülür. İlk 24 bit (OUI): üretici/organizasyon kimliği gibi düşünülebilir. Son 24 bit: üreticinin o arayüze verdiği cihaz-özel bölüm.

Yerel iletişimde MAC’in rolü (Switch mantığı): Yerel ağda cihazların frame’leri doğru yere teslim etmesi için ağ cihazları, çoğunlukla MAC tablosu gibi mekanizmalarla “bu MAC hangi portta?” bilgisini kullanır. L2 düzeyinde iletim MAC üzerinden; L3 düzeyinde yönlendirme IP üzerinden yapılır.

Gerçek hayatta belirtisi/örneği nedir? Aynı ağdaki iki cihaz “birbirini görmüyor” hissi: çoğu zaman L2/L3 sınırında ipucu ararsın (MAC/ARP). “Bağlı görünüyor” ama yerelde hiçbir kaynak çalışmıyor: L1 var gibi; L2’de frame alışverişi kopuk olabilir.

Nasıl doğrularım/çürütürüm? (güvenli): Kanıt 1: Doğru arayüzün MAC’ini gör (hangi arayüz üzerinden konuşuyorum?). Kanıt 2: Wireshark’ta (yerel/izinli) frame detaylarında kaynak/hedef MAC alanlarını gözle. Karşı kanıt: L2 sorunu sandığın şey L3 (IP/subnet) olabilir. Komutlar: Windows getmac /v, ipconfig /all; Linux ip link; macOS ifconfig.

Ne anlama gelir?

Temel akış:

• MAC bilinmiyorsa cihaz ARP Request gönderir (çoğunlukla broadcast): “Şu IP kimde?”
• O IP’ye sahip cihaz ARP Reply döner (çoğunlukla unicast): “Benim, MAC’im şu.”
• Eşleme bir süre ARP cache’te tutulur; böylece her seferinde yeniden sormaz.

ARP cache okuryazarlığı (kanıt kaynağı olarak): ARP cache dinamik bir tablodur; kayıtlar zamanla eklenir, “eskiyebilir”, silinebilir. Tek bir anlık görüntü ile kesin hüküm vermek yerine, kısa aralıklarla gözlemleyip desen aramak daha güvenlidir.

Tipik ARP desenleri: “incomplete / çözümlenemedi” benzeri kayıtlar: IP var ama MAC çözümlenmemiş olabilir; yerelde yanıt alınamıyordur. Tutarsız eşleme sinyali: Aynı IP’ye farklı zamanlarda farklı MAC’lerin karşılık vermesi; tek başına hüküm değildir ama “daha fazla kanıt” gerektirir.

Gerçek hayatta belirtisi/örneği nedir? “Aynı ağdaki yazıcıya erişemiyorum”: ARP çözümleme eksik/tutarsız olabilir. “Bazen var bazen yok”: cache değişimi, yerel bağlantı kararsızlığı veya adresleme tutarsızlığı olasılıkları doğar.

Nasıl doğrularım/çürütürüm? (güvenli): Kanıt 1: ARP/komşu tablosunu oku — hedef IP için MAC kaydı var mı? “incomplete” gibi bir durum var mı? Kanıt 2: Wireshark’ta arp filtresi ile ARP Request/Reply görüyor musun? Request var, Reply yoksa: hedef yanıt vermiyor olabilir veya yerel iletimde kopukluk olabilir. Komutlar: Windows/macOS arp -a; Linux ip neigh.

Bileşen	Anlamı	Eksikse belirti
IP adresi	Bu cihazın L3 kimliği	Bağlantı yok, 169.254.x.x (APIPA)
Prefix / Mask	“Hangi ağdayım?”	Yanlış subnet, komşuya erişememe
Default gateway	Subnet dışına çıkış kapısı	İnternet yok, sadece yerel

Ne anlama gelir?

Troubleshooting açısından kritik nokta: IP tek başına yeterli değildir. Her zaman şu üçlü birlikte düşünülür:

• IP + Subnet mask / Prefix (CIDR): “Benim ağım nerede başlıyor, nerede bitiyor?”
• Default gateway (varsayılan ağ geçidi): “Subnet dışına çıkmam gerekirse ilk kapım neresi?”

Pratik model: IP + Prefix = “Hangi ağdayım?” | Gateway = “Ağdan dışarı çıkış kapım var mı?”

IPv4 adresini, subnet mask/prefix iki parçaya böler: Network ID (ağ kısmı — ortak “mahalle”) ve Host ID (host kısmı — o mahalledeki “bina numarası”). Bu ayrımı mask/prefix belirler.

Public (Genel) vs Private (Özel) IP — kavramsal okuryazarlık: Public IP: İnternet üzerinde yönlendirilebilir, küresel ölçekte eşsiz olma hedefi taşır. Private IP (RFC 1918): Yerel ağlarda tekrar tekrar kullanılabilen, internette doğrudan yönlendirilmeyen adres alanlarıdır. Private adresle internete çıkmak için genellikle NAT gerekir.

Gerçek hayatta belirtisi/örneği nedir? “Wi-Fi bağlı ama sayfalar açılmıyor”: IP yok / yanlış prefix / gateway yok gibi adresleme sinyalleri sık görülür. “Aynı ağdaki cihaza erişemiyorum”: IP’ler aynı subnet’te değilse (veya mask/prefix yanlışsa) hedef “yakın” görünse bile erişim olmaz.

Nasıl doğrularım/çürütürüm? (güvenli): Kanıt 1: IPv4 adresi var mı? Kanıt 2: Prefix/mask var mı ve mantıklı mı? (/24 mü, /26 mı?) Kanıt 3: Default gateway var mı? Var ise, aynı subnet’te mi olmalı? (çoğu sahada evet). Karşı kanıt: IP/prefix/gateway tutarlı görünse bile sorun üst katmanda olabilir.

Ne anlama gelir?

Subnetting’i okumak için şu üç kavram yeterli: Prefix (CIDR) örn. /24, /26 → ağ kısmının uzunluğu; Network address = subnet’in başlangıcı; Broadcast address (IPv4) = subnet içindeki “herkese” adres. Subnet mask’i “filtre” gibi düşün: Mask/prefix cihaza “Şu kısım ağ, şu kısım host” der. Bu yüzden iki cihazın “aynı ağda” sayılması için IP + mask/prefix birlikte değerlendirilir.

Prefix (CIDR)	Host sayısı (yaklaşık)	Kullanım örneği
/24	254	Küçük ofis, tek subnet
/26	62	Birkaç alt ağa bölme
/28	14	Küçük segment (DMZ, yönetim)
/30	2	Point-to-point link (WAN)

Örnek: /24 okuma (yaygın): Ağ 192.0.2.0/24 → Pratik okuma: 192.0.2.* aynı subnet gibi düşünülebilir. Network 192.0.2.0, broadcast 192.0.2.255, hostlar arada.

Örnek: /26 okuma (daha küçük subnet): /24, /26 ile 4 parçaya bölünür; blok aralıkları: 192.0.2.0–63, 64–127, 128–191, 192–255. Cihaz IP’si 192.0.2.70 ise: 70, 64–127 aralığında → subnet: 192.0.2.64/26; broadcast: 192.0.2.127; kullanılabilir host aralığı: 192.0.2.65 – 192.0.2.126.

Gerçek hayatta belirtisi/örneği nedir? Aynı switch’e bağlı iki cihaz birbirini görmüyorsa, sorun her zaman kablo değildir; cihazlardan biri farklı subnet’e düşmüş olabilir. “Hedef aynı ağda sanıyordum” yanlış teşhisi, genelde “prefix’i görmezden gelmekten” doğar.

Ne anlama gelir? IPv6, IPv4’ün adres tükenmesine yanıt olarak geliştirilmiş, çok daha büyük adres alanı sunan bir protokoldür. Teşhiste üç pratik soru öne çıkar: Bu adres IPv6 mı, nasıl yazılmış? Prefix (örn. /64) neyi ifade ediyor? Aynı cihazda IPv4 ve IPv6 birlikte görülebilir mi? Evet; bu geçiş yaklaşımına dual-stack denir — aynı anda hem IPv4 hem IPv6 adresi atanabilir ve uygulamalar birini veya diğerini kullanabilir.

IPv6 adresi 128 bittir; insan okunabilirliği için 16’lık (hexadecimal) bloklara bölünür ve iki nokta üst üste (:) ile ayrılır. Örnek tam yazım: 2001:0db8:0001:0002:0000:0000:0000:0010. İki kısaltma kuralı vardır: (1) Bir blok içinde baştaki sıfırlar atılabilir — 0db8 → db8, 0010 → 10. (2) Ardışık tamamen sıfır blokları tek seferlik :: ile kısaltılabilir — 2001:db8:1:2:0:0:0:10 → 2001:db8:1:2::10. Dikkat: :: bir adreste yalnızca bir kez kullanılabilir; aksi halde hangi blokların sıfır olduğu belirsizleşir.

Prefix (ön ek): IPv4’teki CIDR gibi, IPv6’da da prefix uzunluğu “ağ kısmı”nı tanımlar. Örneğin /64, yerel ağ (link) okuryazarlığında sık görülür; “aynı /64 prefix’indeyiz” = aynı yerel ağ segmentindeyiz anlamına gelir. Teşhiste “aynı prefix’te miyiz?” sorusu, “aynı subnet’te miyiz?” (IPv4) sorusunun karşılığıdır.

IPv6 türü	Örnek / aralık	Kullanım
Global Unicast	2000::/3	İnternette yönlendirilebilir (public benzeri)
Link-Local	fe80::/10	Yerel segment; router geçirmez, otomatik atanır
Loopback	::1	Localhost (127.0.0.1 karşılığı)

• Global Unicast (2000::/3): İnternette yönlendirilebilir adresler. IPv4’teki “public” adrese benzer. Çoğu genel kullanım IPv6 adresi bu aralıktadır.
• Link-Local (fe80::/10): Her arayüzde işletim sistemi tarafından otomatik üretilebilir. Yalnızca aynı yerel link (segment) içinde geçerlidir; router bu adresleri bir sonraki segment’e iletmez. İki cihaz aynı kablo/aynı Wi‑Fi segment’indeyse link-local ile birbirine erişebilir; fakat link dışına çıkmaz.
• Loopback (::1): Cihazın kendisini işaret eder. IPv4’teki 127.0.0.1 karşılığıdır. “Localhost” testlerinde kullanılır.

Gerçek hayatta belirtisi/örneği nedir? Aynı arayüzde hem IPv4 hem IPv6 adresi görülebilir; bazı uygulamalar veya servisler IPv6’yı tercih edebilir. “IPv4 var ama bazı siteler veya uygulamalar garip davranıyor” gibi şikâyetlerde IPv6’nın varlığı veya yokluğu bir sinyal olabilir — örneğin IPv6 ile erişmeye çalışıyor ama IPv6 yolunda bir sorun var. Bu modülde servis analizi yapılmaz; hedef “IPv6 da var / türü şu” kanıtını çıkarabilmektir.

Nasıl doğrularım/çürütürüm? (güvenli): Kanıt 1: Cihazda IPv6 adresi var mı? (ipconfig /all, ip a, ifconfig çıktısında inet6 veya IPv6 satırları.) Kanıt 2: Prefix uzunluğu var mı? (/64 gibi.) Kanıt 3: Kısaltma doğru mu? (:: birden fazla kez kullanılmamalı.)

ipconfig — Aktif arayüzlerde IPv4/IPv6 adresi, Subnet Mask ve Default Gateway’e hızlı bakış sağlar. Çıktıda “IPv4 Address”, “Subnet Mask”, “Default Gateway” satırlarını oku. Eksik veya beklenmedik bir değer (ör. 0.0.0.0 veya boş gateway) L3 sorununa işaret edebilir.

ipconfig /all — Tüm arayüzler için ayrıntılı bilgi verir: fiziksel adres (MAC), DHCP durumu, DNS sunucuları, lease bilgisi vb. Birden fazla arayüz (Ethernet, Wi‑Fi, sanal adaptörler) varsa “hangi arayüz üzerinden gidiyorum?” sorusunu yanıtlamak için kritiktir. Yanlış arayüzü okuyorsan “her şey normal” gibi yanlış pozitif üretebilirsin.

route print — Yönlendirme tablosunu listeler. “0.0.0.0” (varsayılan rota) satırında “gateway” sütununda bir adres görülmelidir. Default route yoksa cihaz subnet dışına çıkış yolunu bilmez; “internet yok” belirtisi beklenir.

ip a (veya ip addr) — Arayüzlerin IPv4 (inet) ve IPv6 (inet6) adreslerini prefix ile birlikte gösterir. “state UP” olan arayüz bağlı; “inet” satırı yoksa o arayüzde IPv4 adresi yok demektir. Prefix /24, /64 vb. doğrudan görünür.

ip route — Yönlendirme tablosu; “default via 192.0.2.1 dev eth0” benzeri satır varsayılan ağ geçidini gösterir. “default via” satırı yoksa subnet dışı trafik hedeflenemez; dışarı çıkamama normaldir.

ifconfig — Arayüz listesi ve her arayüz için inet (IPv4), inet6 (IPv6) satırları. “status: active” bağlantının etkin olduğunu gösterir. Wi‑Fi genelde en0; Ethernet en1 veya farklı isimle olabilir — cihaza göre değişir; çıktıya bakarak karar ver.

netstat -rn — Yönlendirme tablosu (numeric, route). “default” satırı ve gateway sütunu varsayılan çıkış noktasını verir. Default yoksa dış ağlara rota tanımlı değildir.

Köprü notu: Yerel komşu çözümleme (ARP) gerekiyorsa — “aynı ağdaki cihaza ulaşamıyorum” — kanıt okuryazarlığı Modül 7’dedir (arp -a, ip neigh). Burada odak L3: IP, prefix, default gateway.

Teşhis akışı (kısa): Önce “bağlı mıyım?” (link/SSID); sonra “IP/prefix/gateway var mı?” (bu komutlar). Üçlü tutarlıysa bir sonraki adım L4 (port/servis) veya DNS/uygulama katmanına geçmektir.

Özellik	TCP	UDP
Bağlantı	Evet (3-way handshake)	Hayır (bağlantısız)
Güvenilirlik	Yeniden iletim, sıralama, ACK	Yok; kayıp kabul edilir
Kullanım	HTTP/HTTPS, e-posta, dosya	DNS (çoğu), canlı yayın, oyun
Teşhis	Timeout / refused anlamlı	Servis yanıtı ile değerlendirilir

Ne anlama gelir?

TCP (Transmission Control Protocol) — “Garantili Teslimat”: Bağlantı temelli (connection-oriented): Veri akışı başlamadan önce bağlantı kurar. 3-Way Handshake: SYN (istemci → sunucu) → SYN-ACK (sunucu → istemci) → ACK (istemci → sunucu). Hata kontrolü & yeniden iletim: Onay (ACK) gelmeyen veriyi yeniden gönderebilir. Sıralama: Paketler karışık gelse bile hedefte sıraya koyar. Tipik örnekler: HTTP/HTTPS, e-posta (SMTP), pek çok dosya aktarımı.

UDP (User Datagram Protocol) — “Hızlı Teslimat”: Bağlantısız (connectionless): El sıkışma yok; gönderir ve devam eder. Garanti yok: Kaybolan datagram için otomatik yeniden iletim beklemez. Tipik örnekler: DNS (çoğunlukla), bazı gerçek zamanlı ses/görüntü ve oyun trafiği.

Nasıl doğrularım/çürütürüm? (güvenli): Bu modülde amaç tek hamlede “sebep” bulmak değil; L4 kanıtını temizlemek. TCP’de sonuç sınıflandırma: Refused (reddedildi): “Kapıya ulaştım ama içeride dinleyen yok / aktif reddediliyor.” Timeout: “Kapıya gidemedim ya da kapı cevap vermedi.” UDP’de doğrulama yaklaşımı: UDP’nin doğası gereği “kuruldu” mesajı yoktur; bu yüzden “çalışıyor mu?” sorusu çoğu zaman servis bağlamında değerlendirilir (ör. DNS sorgusu yanıtlıyor mu?).

Aralık	Ad	Örnek
0–1023	Well-known	80 (HTTP), 443 (HTTPS), 22 (SSH), 53 (DNS)
1024–49151	Registered	Uygulama/üretici atamaları
49152–65535	Dynamic / Ephemeral	İstemci çıkış portu (geçici)

Ne anlama gelir?

Bir iletişimi anlamlı kılan üçlü: IP (hangi cihaz?) + Protokol (TCP mi UDP mi?) + Port (hangi servis?). Bu üçlü birlikte socket/endpoint fikrini oluşturur. Port aralığı: 0–65535.

Port kategorileri (okuryazarlık): Well-known (0–1023): Yaygın standart servisler (HTTP 80, HTTPS 443, SSH 22, DNS 53 vb.). Registered (1024–49151): Üreticiler/uygulamalar tarafından sık kullanılan aralık. Dynamic/Private (49152–65535): İstemcinin çıkışta geçici kullandığı portlar (ephemeral).

Yaygın port örnekleri (ezber için değil, bağlam için): 80/TCP → HTTP; 443/TCP → HTTPS; 22/TCP → SSH; 53/UDP (ve bazen TCP) → DNS; 25/TCP → SMTP.

Örnek: İstemci example.com üzerindeki HTTPS servisine bağlanıyor: Hedef example.com:443/TCP. İstemci bağlantı için geçici bir port seçebilir: ör. 198.51.100.25:50123/TCP → example.com:443/TCP. Buradaki 50123 istemcinin “çıkış kapısıdır”; sunucunun servisi değildir.

Gerçek hayatta belirtisi/örneği nedir? “Site açılmıyor” ama yalnızca HTTP (80) çalışıyor olabilir; HTTPS (443) kapalı/engelli olabilir. “Servis çalışıyor sanıyorduk” ama ilgili portta LISTENING yoksa, uygulama çalışmıyor veya yanlış porta bağlı olabilir.

Nasıl doğrularım/çürütürüm? (güvenli): Kanıt 1: Doğru port/protokol mü test ediyorum? Kanıt 2: Karşı tarafta gerçekten listening var mı? (yetkili/yerel erişim varsa). Kanıt 3: Sonuç türü nedir? (timeout vs refused).

Ne anlama gelir? Kullanıcı “site açılmıyor” veya “servise erişemiyorum” dediğinde, gerçekte ne olduğunu bilmek gerekir: Bağlantı hiç kurulmuyor mu (timeout)? Kuruluyor ama red mi ediliyor (refused)? Yoksa bağlantı var ama uygulama yanıt vermiyor mu? Güvenli test mantığı, bu üçünü ayırt etmene ve “L4 seviyesinde ne biliyoruz?” sorusuna net yanıt vermene yardım eder.

Bu sayede belirsiz “erişemiyorum” cümlesi şu tür somut ifadelere dönüşür: “TCP 443 denemesi timeout oldu.” / “TCP 443 denemesi refused döndü.” / “Yerelde dinliyor; uzaktan erişimde sorun var.” Her biri farklı bir hipotez ve sonraki adım üretir: Timeout → arada engel veya hedef ulaşılamıyor; refused → hedef ulaşılıyor ama portta servis yok veya reddediyor; yerelde dinliyor uzaktan yok → firewall veya ağ kuralı ihtimali.

Bir web sitesi veya herhangi bir servis “açılmıyor” veya “erişilemiyor” dediğinde, zihninde şu üç soruyu sırayla sor:

1. “Binaya gidiyor muyum?” — L3 adresleme sağlam mı? IP/prefix/gateway tutarlı mı? Ping veya ip route/ipconfig ile kanıt toplandı mı? Eğer L3’te sorun varsa L4 testine geçmek anlamsızdır.
2. “Kapı açık mı?” — L4 port erişimi var mı? Hedef sunucuda ilgili port (ör. 443) dinleniyor mu? İstemciden tek port testi (Test-NetConnection, nc -vz) timeout mu refused mı döndü? Bu modül özellikle bu adımı kanıtlamayı öğretir.
3. “İçeride hizmet veriyor mu?” — Bağlantı kuruluyor ama uygulama hata mı veriyor? HTTP 500, “connection reset” veya boş sayfa gibi belirtiler uygulama katmanına aittir. L4 kanıtı “bağlantı kuruldu” diyorsa sorun çoğunlukla L7 veya sunucu tarafı konfigürasyonundadır.

Bu sırayı korumak, yanlış katmanda zaman kaybetmeyi ve gereksiz müdahaleyi azaltır.

Windows: Test-NetConnection -ComputerName hedef -Port 443 — Tek hedef, tek TCP port (ör. 443). Çıktıda TcpTestSucceeded : True/False; False ise neden tek başına söylemez ama L4 erişim kanıtıdır. Linux / macOS: nc -vz hedef 443 — Aynı mantık; succeeded veya failed/timeout. Önce L3 adresleme kanıtı toplanır (Modül 8); sonra L4 servis kanıtı (bu adım); ardından gerekirse DNS/uygulama sırası korunur.

Platform	Dinleyen portlar	Tek port testi
Windows	netstat -ano (LISTENING, PID)	Test-NetConnection -ComputerName X -Port 443
Linux	ss -tulpen	nc -vz hedef 443
macOS	netstat -an \| grep LISTEN, lsof -iTCP -sTCP:LISTEN	nc -vz hedef 443

Windows: netstat -ano — Dinleyen portları ve aktif bağlantıları görmek; PID ile süreç ilişkisini kurmak. LISTENING/ESTABLISHED satırları, yerel/uzak adres ve portlar. Test-NetConnection example.com -Port 443 — Tek hedef–tek TCP port erişimi kanıtı (TcpTestSucceeded : True/False). curl -I https://example.com — Başlık düzeyinde yanıt var mı görmek; HTTP status (200/301/403 vb.).

Linux: ss -tulpen — Dinleyen TCP/UDP portları ve hangi sürecin kullandığını görmek. nc -vz example.com 443 — Tek hedef–tek TCP port için erişim kanıtı (succeeded / failed). curl -v telnet://192.0.2.10:80 (telnet yoksa) — Belirli bir porta TCP bağlantısı kurulabiliyor mu görmek.

macOS: netstat -an | grep LISTEN — Dinleyen portlara hızlı bakış. lsof -iTCP -sTCP:LISTEN — Hangi uygulamanın hangi TCP portunda dinlediğini görmek. nc -vz example.com 443 — Linux’tekiyle aynı (tek hedef–tek port).

Troubleshooting mini senaryosu (yerel/izinli): Belirti: Yeni kurulan web sunucusuna 192.0.2.50’den tarayıcıyla girilemiyor. Doğrulama: Tek port testi (Test-NetConnection / nc -vz 192.0.2.50 80). Sunucu tarafında dinleme kanıtı (netstat -ano / ss -tulpen’de 80/443 LISTEN var mı?). Karar: İstemci testinde başarısız + sunucuda LISTEN yok → servis çalışmıyor/yanlış portta. Sunucuda LISTEN var ama istemci timeout → arada kural/engel ihtimali.

Ne anlama gelir?

Giriş seviyesinde DNS’i üç katmanda okursun: Local Cache (Yerel önbellek): Cihaz önce kendi hafızasına bakar: “Bu ismi az önce çözdüm mü?” Resolver (Çözücü — genelde router/kurum DNS/servis sağlayıcı): Önbellekte yoksa cihazın ayarlı olduğu DNS sunucusuna sorulur. Hiyerarşi → Yetkili yanıt (authoritative): Resolver cevap bilmiyorsa, DNS hiyerarşisini kullanarak doğru kaynağa gider ve sonucu döndürür. DNS’in kritik noktası: İsim çözülmüyorsa, uygulama doğru IP’ye gidemez.

Örnek: Kullanıcı www.example.com yazıyor, tarayıcı “siteye ulaşılamıyor” diyor. İki ayrı soru vardır: “İsim çözülüyor mu?” (DNS) ve “Çözülen IP’ye servis erişimi var mı?” (Modül 9: L4/uygulama).

Kayıt türü	İşlevi	Örnek kullanım
A	İsim → IPv4	example.com → 93.184.216.34
AAAA	İsim → IPv6	example.com → 2606:2800:220:1:248:1893:25c8:1946
CNAME	Takma ad → başka isim	www → example.com (sonra A/AAAA)
MX	E-posta sunucusu	E-posta teslim hedefi

DNS kayıt türleri (okuryazarlık): A: İsim → IPv4 adresi. AAAA: İsim → IPv6 adresi. CNAME: Takma ad; bir ismi başka bir isme yönlendirir (sonunda A/AAAA ile IP’ye varılır). MX: E-posta teslimi için hedefleri tanımlar.

Nasıl doğrularım/çürütürüm? (güvenli): Kanıt 1 — Çözümleme var mı? example.com için IP dönüyor mu? Kanıt 2 — Kime soruyorsun? Cihaz hangi DNS sunucusunu kullanıyor? Kanıt 3 — Yanıt türü ne? “Bulunamadı” mı, “zaman aşımı” mı? Örnek: “IP’ye ping atabiliyorum ama www.example.com açılmıyor” → Ping’in çalışması L3 yolu işaret eder; alan adının açılmaması DNS ihtimalini güçlendirir.

DNSSEC (kavramsal giriş): Klasik DNS yanıtları bütünlüğü “doğası gereği” garanti etmez; DNSSEC, DNS kayıtlarına dijital imza ekleyerek cevabın yetkili kaynaktan geldiğine dair doğrulama sunar.

Ne anlama gelir?

DHCP çoğunlukla şunları dağıtır: IP adresi + prefix/mask; Default gateway; DNS sunucuları; Lease/kira süresi.

Adım	Kim	Ne yapar?
Discover	İstemci	“DHCP var mı?” (broadcast)
Offer	Sunucu	“Şu IP/gateway/DNS’i önerebilirim”
Request	İstemci	“Bu teklifi kabul ediyorum”
Ack	Sunucu	“Onaylı; lease başladı”

DORA akışı: Discover: İstemci “DHCP var mı?” diye yayın yapar. Offer: Sunucu “şu ayarları önerebilirim” der. Request: İstemci “bu teklifi istiyorum” der. Ack: Sunucu “tamam, şu süreyle senindir” diye onaylar (lease başlar).

Gerçek hayatta belirtisi/örneği nedir? “Wi-Fi bağlı görünüyor ama hiçbir şey açılmıyor” → DHCP’den doğru IP/gateway/DNS alınamamış olabilir. Bazı cihazlar çalışırken bazıları çalışmıyorsa → lease/çakışma/yanlış ağ profili veya erişim noktası kararsızlığı gibi ihtimaller doğar. Cihaz DHCP alamadığında işletim sistemi bazen “otomatik yerel adres” (APIPA) kullanabilir; bu “bağlantı var ama DHCP yok” sinyalidir.

Nasıl doğrularım/çürütürüm? (güvenli): Kanıt 1: Arayüz DHCP ile mi yapılandırılmış? Kanıt 2: Lease var mı, ne zaman alınmış/ne zaman bitecek? Kanıt 3: IP/prefix + gateway + DNS birlikte tutarlı mı? Karşı kanıt: IP/prefix/gateway/DNS tutarlıysa “DHCP bozuk” hipotezi zayıflar.

Statik IP vs DHCP (kavramsal): DHCP: Son kullanıcı cihazları (telefon/laptop) için pratik ve yönetimi kolaydır. Statik IP: Bazı sabit servisler (yazıcı/yerel sunucu gibi) için tercih edilebilir; adres değişirse erişim/bağımlılıklar etkilenebilir.

Kavram	Açıklama	Teşhiste
NAT	İç adres(ler) → dış adres çevirisi	İçeride private IP, dışarıda tek public
PAT	Port eşleştirme ile çok cihaz	Ev router’da yaygın
Belirti	“Dışarıdan bana erişilemiyor”	NAT/firewall ile uyumlu; beklenen davranış

Ne anlama gelir?

NAT (Network Address Translation), iç ağdaki çok sayıda cihazın internete çıkışını yönetmek için adres/port çevirisi yapar. Ev senaryosunda pratikte çoğunlukla PAT (Port Address Translation) görürsün: birden fazla iç istemci, dışarıda tek bir çıkış kimliği üzerinden farklı port eşleştirmeleriyle temsil edilir.

Örnek (kavramsal): İçerideki cihaz 192.0.2.10 bir web servisine gitmek ister. Router dışarıya kendi çıkış kimliğiyle (ör. 203.0.113.5) çıkar ve “hangi iç cihaz hangi dış bağlantıya karşılık geliyor?” bilgisini bir NAT tablosunda tutar. Dönüş trafiği geldiğinde router bu tabloya bakıp paketi doğru iç cihaza yollar.

Artı / eksi (giriş seviyesi yorum): Artı: Adres tasarrufu sağlar; iç cihazlar doğrudan görünmediği için “doğrudan gelen bağlantıları” varsayılan olarak zorlaştırabilir. Eksi: Dışarıdan içeriye “kendiliğinden” bağlantı başlatmak genelde zordur; özel durumlarda ek ağ yapılandırmaları gerekebilir.

Gerçek hayatta belirtisi/örneği nedir? “İnternete çıkabiliyorum ama dışarıdan bana erişilemiyor” → NAT/firewall davranışıyla uyumlu olabilir. Aynı ev ağında tüm cihazlar bir anda internete çıkamaz hale gelirse → router’ın NAT/DNS/DHCP rolleri toplu etkilenmiş olabilir. “Alan adı çözülüyor ama bağlantı kurulamıyor” → DNS tamam; NAT/firewall/L4 çizgisi güçlenir (Modül 9’daki kanıta dön).

Nasıl doğrularım/çürütürüm? (güvenli): Kanıt 1: Default gateway var mı? (Modül 8’den). Kanıt 2: İç ağdan dışa doğru “tek hedef–tek servis” erişimi kurulabiliyor mu? (Modül 9 mantığı). Kanıt 3: Sorun tüm cihazlarda mı, yoksa tek cihazda mı? Tüm cihazlarda ise router/çıkış zinciri olasılığı artar. Tek cihazda ise istemci/DNS/arayüz bazlı sorun olasılığı artar.

Platform	IP / Gateway	DNS testi
Windows	ipconfig /all (gateway, DNS satırları)	nslookup example.com, Resolve-DnsName
Linux	ip a, ip route, resolvectl status	dig example.com, host example.com
macOS	ifconfig, netstat -rn, scutil --dns	nslookup example.com

Windows: ipconfig /all — IP/prefix, default gateway, DNS sunucuları, DHCP/lease bilgilerini toplu görmek (“DHCP Enabled”, “DNS Servers”, “Default Gateway”, “Lease Obtained/Expires”). nslookup example.com — DNS çözümlemesi var mı, hangi DNS sunucusu yanıtlıyor? Resolve-DnsName example.com (PowerShell) — DNS yanıtını A/AAAA/CNAME vb. görmek. ipconfig /release ve ipconfig /renew — DHCP lease’i bırakıp yeniden istemek (dikkatli; bağlantıyı kesebilir).

Linux: ip a — Arayüzde IP var mı, arayüz up mı? ip route — Default route var mı? resolvectl status (bazı sistemlerde) — Hangi DNS sunucuları kullanılıyor? dig example.com veya host example.com — DNS sorgusunun yanıt alıp almadığını kanıtlamak. DHCP istemci yenileme (dağıtıma bağlı) — müdahaleci; yalnızca izinli/yerel.

macOS: ifconfig — Arayüz durumu ve IP varlığına bakış. scutil --dns — DNS yapılandırmasını ve resolver’ları görmek (Resolver listeleri, nameserver satırları). nslookup example.com — Windows ile aynı mantık. Arayüzü DHCP ile yenileme — müdahaleci; bağlantıyı etkileyebilir.

Troubleshooting mini senaryosu: Belirti: “Wi-Fi’ye bağlandım ama internet yok, siteler açılmıyor.” Olasılık: DHCP (doğru IP/gateway/DNS alınamamış), DNS (isim çözümleme yok), NAT/çıkış zinciri. Doğrulama: ipconfig /all, ip a + ip route + resolvectl (Linux), ifconfig + scutil --dns (macOS) — Default gateway var mı? DNS sunucuları var mı? nslookup example.com ile sonuç: yanıt var mı, “bulunamadı” mı “zaman aşımı” mı? Karar: DNS çözülmüyorsa DNS/DHCP hattı şüpheli; DNS çözülüyorsa bir sonraki adım Modül 9’da tek hedef–tek port servis erişimini doğrulamaktır.