Kurumsal Ağ Protokolleri: DHCP'den LDAP'a

Ağ protokolleri, birbirini hiç görmemiş iki cihazın aynı işi aynı sırayla yapmasını sağlayan kurallardır. Bir şirketin ağında her gün milyonlarca mesaj gidip gelir ve bunların hiçbiri “ne demek istediğini” tahmin etmez; her mesajın hangi alanı taşıyacağı, hangi sırayla geleceği ve karşı tarafın nasıl cevap vereceği önceden yazılmıştır. Protokol o yazılı kuraldır.

Bir devlet dairesinde işlem yaptırdığınızı düşünün. Formun hangi alanları taşıyacağı, hangi belgenin hangisinden önce alınacağı ve hangi gişeye hangi işlem için gidileceği baştan bellidir. Adres beyanınız yoksa sıraya bile giremezsiniz; belgeniz varsa ama süresi dolmuşsa geri çevrilirsiniz; sicilinizde yetki görünmüyorsa işlem yapılmaz. En önemlisi şu: hangi memur bakarsa baksın, hangi ilde işlem yaparsanız yapın, form aynı formdur. Kuralı uygulayan değişir, kural değişmez.

Ağ protokolleri tam olarak böyle çalışır ve bu makale boyunca aynı daireye geri döneceğiz. Aşağıda önce protokolün ne olduğunu ve en sık karıştırılan üç kavramı ayıracağız, sonra bir şirketi ayakta tutan protokolleri altı işlev grubunda gezeceğiz, ardından sabah 09:00’da açılan bir bilgisayarın bu protokolleri hangi sırayla zincirlediğini adım adım izleyeceğiz. Sonunda da en işe yarar kısma geleceğiz: zincir koptuğunda belirtiye bakıp hangi halkanın gittiğini anlamak. Elinizde şu an çözmeniz gereken bir arıza varsa doğrudan teşhis tablosuna atlayabilirsiniz. Bu makale kurumsal network kurulumu hizmetimizin kavramsal temelini oluşturur.

Protokol Nedir, Neden Var?

Protokol, iletişim kuran iki tarafın da önceden kabul ettiği bir düzendir: hangi mesaj gönderilecek, hangi sırayla gelecek, içinde hangi alanlar bulunacak ve karşı taraf nasıl cevap verecek. Bu düzen yazılı olmak zorundadır, çünkü konuşan iki taraf birbirini tanımaz. Bir yanda 2015 model bir yazıcı, öbür yanda geçen ay kurulmuş bir sunucu vardır; ikisini de farklı firmalar, farklı ülkelerde, birbirinden habersiz üretmiştir. Aralarında çalışan tek şey ortak kuraldır.

Devlet dairesi benzetmesini sürdürelim. Bir form neden matbu basılır? Çünkü onu dolduran vatandaşla işleyen memur birbirini tanımaz ve her seferinde “bu bilgiyi nereye yazayım” diye anlaşmaya çalışmak sistemi durdurur. Form standarttır ki taraflar konuşmadan anlaşabilsin. Protokol de aynı sebeple vardır: cihazlar her bağlantıda pazarlık etmesin diye.

Bu yüzden protokoller yavaş değişir ve değiştiğinde de eskisiyle uyumlu kalmaya çalışır. 2008 yılından kalma bir cihazın bugünkü bir sunucuyla hâlâ konuşabiliyor olması bir tesadüf değil, protokol tasarımının bilinçli bir tercihidir.

Protokol, Sunucu ve İstemci: Karıştırılan Üç Şey

Aynı kelime üç ayrı şey için kullanıldığı ve bu üçü karıştırıldığı için günlük tartışmaların önemli bir kısmı boşa gider. Ayrım şudur: DHCP bir protokoldür, Windows DHCP Server bir sunucudur, DHCPServer ise o sunucunun işletim sisteminde çalışan servisidir. Protokol kuraldır, sunucu kuralı uygulayan yazılımdır, servis o yazılımın çalışan örneğidir.

Bu ayrımın pratik karşılığı büyük. “DHCP çöktü” cümlesi teknik olarak anlamsızdır; çöken şey protokol değil, o protokolü konuşan sunucudur. Protokol bir belge gibi ortada durur, çökmez. Nitekim aynı protokolü Windows da konuşur, Linux tarafında kea-dhcp4 da konuşur, kenardaki firewall da konuşur. Formun kendisi değişmez; onu işleyen kurum değişir.

Servis kavramı soyut kalmasın, çünkü üzerine tıklayabileceğiniz bir şeydir. Win + R ile services.msc yazdığınızda açılan Hizmetler konsolu o makinedeki bütün servisleri listeler. Buradan bir servisi durdurabilir, yeniden başlatabilir, Başlangıç türü değerini değiştirebilir veya çöktüğünde ne yapacağını tanımlayabilirsiniz. DHCPServer da bu listede durur; orada protokolü değil, o protokolü konuşan yazılımın çalışan örneğini yönetirsiniz.

Bunun çok pratik bir karşılığı var ve genellikle yanlış anlaşılır. “Bilgisayarı kapatıp açın” tavsiyesi çoğu zaman bilgisizlik sayılır, oysa neden işe yaradığının mekanik bir açıklaması vardır: yeniden başlatma, o makinedeki yüzlerce servisi sıfırdan ve doğru bağımlılık sırasıyla ayağa kaldırır. Takılmış tek bir servisi aramak yerine hepsini birden tazeler; daireyi masa masa dolaşmak yerine ertesi sabah yeniden açmak gibidir.

Profesyonel tercih tam burada başlıyor. Son kullanıcının makinesinde hangi servisin takıldığını teşhis etmek kullanıcıyı dakikalarca bloke eder ve çoğu durumda yeniden başlatmadan pahalıya gelir; bu yüzden orada yeniden başlatmayı bilinçli olarak seçeriz. Sunucuda ise tam tersini yaparız: üzerinde başka roller de çalıştığı için kör bir yeniden başlatma yerine yalnızca ilgili servis yeniden başlatılır, gerekirse bağımlı servisleriyle birlikte. Aynı bilgi, iki farklı karar. Ayıran şey makinenin türü ve kesintinin kime mal olduğudur.

Az bilinen ama işi doğrudan etkileyen bir ayrıntı da şu: Windows istemcilerde Hızlı başlatma açıkken Kapat demek makineyi gerçekten sıfırdan başlatmaz. Çekirdek oturumu uyku dosyasına alınır ve açılışta geri yüklenir, yani servisler tazelenmez. Tam yenileme istiyorsanız kullanıcıya “kapatıp açın” değil Yeniden Başlat demeniz gerekir. Aradaki fark, aynı arızanın çözülmesiyle çözülmemesi kadar büyüktür ve telefonda söylediğiniz iki kelimeye bakar.

Sürekli unutulan üçüncü taraf da var: istemci de protokolün bir parçasıdır. Her Windows’ta Dhcp servisi, her Linux’ta dhclient ya da systemd-networkd bu işi yapar. İnsanların aklına “DHCP” deyince hep sunucu gelir, oysa masadaki bilgisayar konuşmanın yarısını üstlenmiştir. Bir arızada istemci tarafına hiç bakmadan sunucuyu suçlamak, bu yüzden sık yapılan ve çok vakit kaybettiren bir hatadır.

Port Numaraları: Hangi Kapı Kime Ait?

Port numarası, aynı IP adresine gelen trafiğin hangi servise ait olduğunu ayıran sayıdır. Bir sunucunun tek bir adresi vardır ama üzerinde onlarca servis çalışabilir; gelen paketin hangisine ait olduğunu port numarası söyler. Dairedeki gişe numarası gibidir: bina tek, kapı numarası işlemi ayırır.

Aşağıdaki tablo bu makalede geçen protokollerin kapı numaralarını topluyor. Ezberlemeniz gerekmez, ama bir firewall kuralı yazarken ya da bir bağlantı sorununu ararken bu tabloya döneceksiniz.

Son satır önemli bir istisnayı gösteriyor: her protokolün port numarası olmaz. OSPF, TCP ya da UDP kullanmadan doğrudan IP üzerinde çalışır. Bu yüzden bir OSPF sorununu port taramasıyla arayamazsınız.

Bir de taşıma katmanı seçimlerinin arkasında düşünce var. DHCP neden UDP kullanır? Çünkü istemcinin henüz IP adresi yoktur ve adresi olmayan bir cihaz TCP oturumu kuramaz. LDAP neden TCP kullanır? Çünkü LDAP konuşmaya başlandığında istemcinin adresi çoktan vardır ve dizin sorgusu güvenilir, sıralı bir kanal ister. Protokolün taşıma tercihi, o protokolün hayatının hangi anında devreye girdiğini ele verir.

Port kavramının kendisi, TCP ile UDP arasındaki farkın mekanizması ve bir bağlantı kurulmadığında arızanın hangi tarafta olduğunu paket dökümüyle kanıtlama yöntemi ayrı bir yazının konusu: Port Nedir? TCP ve UDP Farkı, Bağlantı Arızası Tespiti.

Bütün Bunlardan Önce: Adres ve Fiziksel Karşılığı

Aşağıdaki altı grubun hepsi bir şeyi varsayar: cihazın bir paketi kabloya koyabildiğini. O varsayım kendiliğinden doğru değildir ve iki ayrı şeye dayanır.

Birincisi adresin kendisidir. Bir cihaza 192.168.1.40 vermek yetmez; o sayının nerede bittiği, hangi kısmının ağı hangi kısmının cihazı gösterdiği maskeyle belirlenir. Maske yanlış yazıldığında cihaz ağa bağlıdır, ışığı yanar, hatta bazı adreslere erişir; sadece bazılarına erişemez. Adresin nasıl okunduğunu, maskenin ne işe yaradığını ve yanlış maskenin nasıl bir arıza ürettiğini IP adresi ve subnet maskesi rehberimizde ölçümlerle ele alıyoruz.

İkincisi o adresin fiziksel karşılığıdır. Kabloya konan şey IP adresi değildir; ağ kartlarının birbirini tanıdığı donanım adresidir. Cihaz her seferinde “şu IP kimde?” diye ağa sormak ve gelen cevabı kullanmak zorundadır. Bu işi yapan protokolün adı ARP’tır ve zincirin en alt basamağında durur: adres almadan, isim çözmeden, bilet almadan önce bu soru sorulur.

ARP’ın burada ayrı bir yeri var, çünkü bir servis değil, servislerin üzerinde durduğu zemindir. Ayar ekranı yoktur, günlüğe satır düşmez, hiçbir arayüzde görünmez. Ağınız yıllarca çalışır ve varlığını fark etmezsiniz; ta ki iki cihaz birbirini bulamayana kadar. Bozulduğunda da kendine ait bir belirti üretmez, üstündeki katmanın belirtisini üretir: DHCP çalışmıyor sanırsınız, DNS’i suçlarsınız, oysa sorun bir alttadır. Protokolün nasıl çalıştığını, önbellek durumlarının ne anlama geldiğini ve teşhiste hangi çıktının neyi söylediğini ARP ve MAC adresi rehberimizde gerçek paket dökümleriyle anlatıyoruz.

Bu iki katman yerindeyse, aşağıdaki altı grup çalışmaya başlayabilir. Tek bir kayıtla: buradaki adres yalnız ağınızın içinde geçerlidir. Paket kurumun sınırından çıkarken kaynak adresi değiştirilir ve dışarısı cihazınızı hiçbir zaman göremez. Kenarda olan bu çeviriyi, tuttuğu kaydı ve o kayıt silindiğinde bağlantının neden sessizce koptuğunu kenardaki adres çevirisi rehberimizde ele alıyoruz.

Şirketleri Ayakta Tutan Protokoller: Altı İşlev Grubu

Kurumsal bir ağda onlarca protokol çalışır, ama bunları katman katman ezberlemek yerine ne teslim ettiklerine göre gruplamak hem öğrenmeyi hem arıza çözmeyi kolaylaştırır. Altı grup var: bağlanmak, kanıtlamak, iş yapmak, görmek, taşımak ve yönetmek.

Bu sıralamanın gizli bir faydası var ve makalenin en işe yarar tarafı da orada. İlk üç grup aynı zamanda bağımlılık sırasıdır. Adresiniz yoksa kimliğinizi kanıtlayamazsınız; kimliğinizi kanıtlayamazsanız iş yapamazsınız. Dolayısıyla bir arızada belirtinin hangi gruba düştüğünü bulmak, sorunun kaynağını bir hamlede daraltır. Daireye adres beyanı olmadan gitmenin anlamı yoktur; sıraya bile giremezsiniz.

Son üç grup bu zincirin dışında durur, çünkü onlar son kullanıcıya değil BT tarafına hizmet eder: biri ağın kendini anlatmasını sağlar, biri boruların nasıl döşendiğini yönetir, biri de yöneticinin uzaktan müdahale etmesini mümkün kılar. Kullanıcı bunların hiçbirini görmez, ama üçü de kesildiğinde ilk üç grubu ayakta tutacak kimse kalmaz.

Dört grup her şirkette vardır: bağlanmak, kanıtlamak, iş yapmak ve yönetmek. İzleme çoğu küçük ve orta ölçekli kurumda kurulu değildir, ama burada bir ayrım yapmak gerekiyor: izlemenin olmaması bir tercih değil, bir eksikliktir. Yönlendirme protokolleri ise gerçekten her şirkette yoktur ve olmaması bir eksiklik sayılmaz.

Bağlanmak: DHCP, DNS ve NTP

Bu üç protokol olmadan bir kurumsal ağda hiçbir şey başlamaz; bunlar pazarlık dışıdır. Cihazın önce bir adresi, sonra o adresle kime ulaşacağını bulacak bir rehberi, sonra da karşı tarafla aynı saati gösteren bir saati olmak zorundadır.

DHCP ağa bağlanan cihaza IP adresini ve o adresle konuşabilmesi için gereken subnet, gateway ve DNS bilgisini otomatik olarak verir. Adres bir kira süresiyle gelir, süre dolmadan yenilenir, yenilenmezse havuza döner. Protokolün nasıl çalıştığını, kira döngüsünü ve 169.254.x.x adresinin ne anlama geldiğini DHCP nedir rehberimizde ayrıntılı olarak ele alıyoruz. Dağıtılan adresin kendisinin nasıl okunduğu, ağ kısmı ile cihaz kısmının nereden ayrıldığı ise IP adresi nedir makalesinin konusu.

DNS ismi adrese çevirir. Ama kurumsal ağda işi bundan çok daha büyüktür: domain ortamında istemciler hangi Domain Controller’a başvuracaklarını DNS’teki SRV kayıtlarından öğrenir. Yani DNS yalnızca “isimden adres bulan” bir servis değil, kimlik altyapısının adres defteridir. Sahada gördüğüm Active Directory arızalarının önemli bir kısmı aslında DNS arızasıdır ve hata mesajı DNS’ten hiç bahsetmez. Kök, TLD ve yetkili sunucu zincirini, kayıt türlerini, TTL ile önbelleğin neden değişikliği geciktirdiğini ve arızada hangi komutla nereye bakılacağını DNS nedir rehberimizde ayrıntılı olarak ele alıyoruz.

NTP listenin en sessiz üyesi ve en çok hafife alınanı. Kerberos, bilet doğrularken istemciyle sunucu arasındaki saat farkının belirli bir toleransı aşmamasını şart koşar; Active Directory’de bu tolerans varsayılan olarak beş dakikadır. Saati kayan bir cihaz ağdan kopmaz, sadece kimlik doğrulayamaz. Ve ürettiği hata mesajının içinde “saat” kelimesi geçmez. Belgenin üstündeki tarih tutmuyorsa memur işlemi yapmaz; itiraz edemezsiniz, çünkü kural budur. Stratum hiyerarşisini, kurumda tek saat kaynağı kurmayı ve saat kaydığında ödenen bedelleri NTP ve saat senkronizasyonu rehberimizde ele alıyoruz.

Kanıtlamak: Kerberos, LDAP ve RADIUS

Bu grup “sen kimsin ve neye yetkilisin” sorusunu cevaplar. Adresiniz olduktan sonra sıradaki soru budur ve kurumsal ağı ev ağından ayıran asıl fark da buradadır.

Kerberos kimlik doğrulamanın kendisidir ve bilet mantığıyla çalışır. Kullanıcı oturum açtığında parolası ağda dolaşmaz; bunun yerine Domain Controller üzerindeki KDC’den süreli bir bilet alır ve sonraki her erişimde o bileti gösterir. Biletin ömrü vardır, Active Directory’de varsayılan on saattir, süresi dolunca yenilenir. Adı da zaten oradan geliyor: elinizde süresi belli, onaylı bir belge var ve her gişede o belgeyi ibraz ediyorsunuz. Bileti üreten KDC mimarisini, oturum açmadan servise erişmeye kadar akan altı mesajı ve Kerberos arızalarında belirtiden hata koduna giden teşhis sırasını Kerberos nedir rehberimizde ele alıyoruz.

LDAP dizini sorgulama protokolüdür. Kerberos “bu kişi gerçekten o” der, LDAP “bu kişi hangi gruplarda, hangi OU’da, neye yetkili” sorusuna cevap verir. Burada çok yapılan bir kavram hatası var: Active Directory, LDAP değildir; Active Directory LDAP konuşur. AD bir dizin servisidir ve LDAP onun arayüzlerinden yalnızca biridir. Yanında Kerberos kimlik doğrular, DNS onu bulunur kılar, SMB politika dosyalarını taşır. Mimarinin tamamı Active Directory rehberimizde. Dizin ağacının nasıl kurulduğunu, bir sorgunun base DN ve filtre ile nasıl daraltıldığını ve 389 ile 636 arasındaki farkın parola güvenliği açısından ne anlama geldiğini LDAP nedir rehberimizde paket düzeyinde ele alıyoruz.

RADIUS ise kapıdaki kontroldür. Kablosuz ağa bağlanan ya da 802.1X yapılandırılmış bir switch portuna kablo takan cihaz, henüz ağa alınmadan önce kimlik sorulur. Windows tarafında bu işi NPS rolü üstlenir, Linux tarafında FreeRADIUS. Buradaki incelik şu: RADIUS diğer ikisinden önce çalışır. Kimliğinizi kanıtlayamazsanız ağa hiç giremezsiniz, dolayısıyla DHCP’ye bile ulaşamazsınız. Binaya girmeden önceki güvenlik noktası gibi düşünün. Protokolün dört mesajlık sorgu akışını, PEAP ile EAP-TLS arasındaki farkı ve ağa bağlanamayan bir kullanıcıda izlenecek teşhis sırasını RADIUS sunucusu nedir rehberimizde ele alıyoruz.

İş Yapmak: HTTP, SMB, SMTP ve Dosya Aktarımı

Bu grup kullanıcının gerçekten gördüğü tek katmandır. Diğerleri doğru çalıştığında kimse farkına varmaz; bu grup bozulduğunda ise telefon hemen çalar, çünkü insanlar işlerini yapamaz.

Grubun en çok kullanılan üyesi bugün HTTP ve şifreli hali HTTPS’tir. Bir kurumda çalışanın gün içinde dokunduğu şeylerin çoğu bu protokolün üstünde taşınır: intranet, bordro ekranı, ERP’nin web arayüzü, bulut tabanlı e-posta ve neredeyse bütün abonelik yazılımları. Dairedeki matbu form benzetmesi burada da geçerli, yalnız form artık ekranda dolduruluyor; alanların adı, hangi sırayla gideceği ve karşı tarafın hangi kodla cevap vereceği yine baştan yazılıdır.

Bu makale açısından bilinmesi gereken iki şey var. Birincisi, 80 ile 443 arasındaki fark bir port numarası farkı değildir: şifresiz bağlantıda adres, form alanları ve parola dahil isteğin gövdesi aynı ağdaki bir başkası tarafından okunabilir. İkincisi, HTTPS’in gizlediği şeyin sınırı vardır; hangi siteye gittiğiniz bilgisi ağda tamamen görünmez olmaz. Bir isteğin içinde tam olarak ne taşındığını, durum kodlarının ne anlama geldiğini, TLS el sıkışmasında neyin konuşulduğunu ve şifresiz bir oturumun paket dökümünde nasıl göründüğünü HTTP ve HTTPS nedir rehberinde paket düzeyinde ele alıyoruz.

Dosya tarafına geçmeden işe yarar bir ayrım yapalım, çünkü ikisi sürekli karıştırılıyor: dosya paylaşımı ile dosya aktarımı aynı şey değildir. Paylaşımda dosya olduğu yerde durur, siz uzaktan üzerinde çalışırsınız ve yetkiyi dizin belirler; ağ sürücüsü açtığınızda olan budur. Aktarımda ise dosyanın bir kopyası bir yerden başka bir yere taşınır, genellikle kurum sınırının dışına. İkisi farklı protokoller ister ve birini diğerinin yerine kullanmak, hem güvenlik hem performans tarafında sorun üretir.

SMB Windows dünyasının paylaşım protokolüdür ve işi sanılandan geniştir. Ağ sürücüleri, paylaşılan klasörler ve yazıcı kuyrukları bunun üzerinden yürür. Ama kritik olan şu: domain ortamında grup ilkelerinin dağıtıldığı SYSVOL paylaşımı da SMB üzerinden okunur. Yani SMB kapalıysa kullanıcı oturum açabilir ama üzerine hiçbir politika uygulanmaz ve bu, teşhis edilmesi en sinir bozucu arızalardan biridir. Rollerin ayrıntısı Windows Server rehberimizde. Protokolün sürüm farklarını, SYSVOL bağımlılığını ve paylaşım ile NTFS izinlerinin nasıl kesiştiğini SMB nedir rehberimizde ele alıyoruz.

NFS aynı işi Unix ve Linux dünyasında yapar; sanallaştırma datastore’u, sunucular arası ortak dizin ve NAS cihazlarındaki ikinci paylaşım yolu olarak karşınıza çıkar. Karma ortamlarda ikisi yan yana koşar: aynı klasör Windows istemcilere SMB, Linux sunuculara NFS ile sunulur ve yetkilendirme mantıkları farklı olduğu için izin çakışmaları buradan doğar. Bu çakışmanın tam olarak nereden doğduğunu, NFS’in kullanıcıyı neden isimle değil sayısal bir numarayla tanıdığını ve root_squash ayarının ne işe yaradığını NFS nedir rehberimizde paket düzeyinde ele alıyoruz. WebDAV ise paylaşımı HTTP üzerinden yapar; SharePoint ve OneDrive kütüphanelerini sürücü olarak eşlediğinizde çalışan protokol budur.

Aktarım tarafında FTP en eskisi ve en sorunlusu. Kullanıcı adı ve parola ağda düz metin dolaşır, tıpkı Telnet gibi. Üstelik komut ile veri için ayrı kanal kullandığından firewall arkasında ek yapılandırma ister; pasif moddaki geniş port aralığını açmayı unutmak, “içeriden çalışıyor dışarıdan çalışmıyor” arızasının bir numaralı sebebidir.

Burada isim benzerliğinden doğan ve sürekli yanlış yapılandırmaya yol açan bir karışıklık var. FTPS ile SFTP aynı şey değildir. FTPS, FTP’nin üzerine TLS eklenmiş halidir; hâlâ FTP’dir, hâlâ iki kanal kullanır, firewall tarafındaki derdi sürer. SFTP ise FTP ile hiçbir akrabalığı olmayan, SSH’ın içinde çalışan ayrı bir protokoldür. Tek kanal kullanır, 22 numaralı porttan geçer ve SSH zaten açık olduğu için ek kural gerektirmez. “Güvenli FTP kuralım” denip FTPS yapılandırılan, oysa SFTP kastedilen projelere sık rastlıyorum. Yeni bir kurulumda varsayılan tercihiniz SFTP olmalı. Üçünün mimari farkını, aktif ve pasif modun firewall arkasında neden kırıldığını ve aynı dosyanın üç protokolle aktarılıp yakalandığında ağda neyin okunabildiğini FTP, FTPS ve SFTP farkı rehberimizde paket düzeyinde ele alıyoruz.

Yazdırma tarafında iki dünya var. Windows ortamında baskı işleri çoğunlukla yine SMB ve RPC üzerinden merkezi bir Print Server’a gider. Kurumsal yazıcıların büyük kısmı ise ayrıca IPP destekler; bu protokol yazdırmayı işletim sisteminden bağımsız hale getirir ve Linux ile macOS istemcilerinin aynı yazıcıyı sorunsuz kullanmasını sağlar. Karma ortamlarda IPP’yi baştan planlamak, sonradan sürücü savaşı vermekten çok daha ucuza gelir.

E-posta bu grubun en çok kullanılan ama en az anlaşılan üyesi. Buradaki temel yanılgı, “mail protokolü” diye tek bir şeyin olduğunu sanmaktır; oysa gönderme ve alma işini ayrı protokoller yapar. SMTP yalnızca gönderir, IMAP (993) ve POP3 (995) ise yalnızca alır. İkisi arasındaki fark davranıştır: IMAP postayı sunucuda tutar ve klasörleri tüm cihazlarınızda eşitler, POP3 ise indirip geleneksel olarak sunucudan siler. Bugün neredeyse her kurumsal kurulumda doğru tercih IMAP’tir. Gönderme tarafını, yani 25 ile 587 numaralı portların neden aynı işi yapmadığını ve şifreleme devreye girmeden önce bir SMTP oturumunda nelerin açıkta okunduğunu SMTP nedir rehberimizde ölçümle ele alıyoruz. Alma tarafını, yani okundu bilgisinin neden bazı kurulumlarda cihazlar arasında eşitlenmediğini ve bunun arşivi tek bir diske nasıl bağladığını IMAP ile POP3 farkı rehberimizde ayırıyoruz.

En öğretici tarafı ise şu: e-postanın karşı tarafa ulaşması, bu makalenin ilk grubuna bağlıdır. Alıcı sunucunun adresi DNS’teki MX kaydından bulunur; gönderdiğiniz mailin sahte olmadığını kanıtlayan SPF, DKIM ve DMARC kayıtları da yine DNS’te durur. Zincir burada da kendini gösteriyor: üçüncü gruptaki bir arızanın kaynağı birinci grupta duruyor.

Görmek: SNMP ve Syslog

Bu iki protokol ağın kendi kendini anlatmasını sağlar. Geri kalan her şey yolunda giderken bunlar da sessizdir; bir yerde iş ters gittiğinde haber veren taraf bunlardır. İkisi de izleme yapar ama yönleri terstir ve bu fark önemlidir.

SNMP sormaya dayanır: izleme sunucusu belirli aralıklarla cihaza bağlanır ve “port doluluğun ne, CPU’n kaç, kaç paket düştü” diye sorar. Bu yönteme polling denir. Ters yönde de çalışabilir; cihaz kritik bir olayda kendiliğinden bildirim gönderir, buna trap denir ve 162 numaralı porta düşer. Zabbix ve Cacti gibi araçların ağ cihazlarından veri toplama biçimi budur. Protokolün mekanizmasını, MIB ve OID kataloğunu ve sürümler arasındaki güvenlik farkını SNMP protokolünü ele aldığımız rehberde ayrıntılı anlatıyoruz.

Syslog ise anlatmaya dayanır: cihaz olay ürettikçe kendi kayıt defterinden merkezi bir sunucuya satır gönderir. Firewall’un engellediği bağlantı, switch’in kapanan portu, sunucunun başarısız oturum denemesi bu kanaldan akar. Satırın anatomisini, baştaki öncelik alanının facility ve severity olarak nasıl çözüldüğünü ve protokolün neyi garanti etmediğini Syslog protokolü rehberimizde ele alıyoruz. Türkiye’de bu protokolün ayrı bir önemi var, çünkü 5651 sayılı kanunun istediği log arşivinin omurgası pratikte syslog akışıdır; konunun hukuki ve teknik tarafını 5651 log yönetimi makalemizde ele alıyoruz.

En yaygın hata bu ikisini kurup sahipsiz bırakmaktır. Bildirimler kurulur, herkese gider, kimse bakmaz. Bir yıl sonra alarm sesi gürültüye dönüşür ve gerçek olay geldiğinde fark edilmez. Bu grubun değeri kurulumunda değil, kime ne zaman haber vereceğinin yazılı olmasındadır.

Taşımak: BGP, OSPF ve Yedeklilik Protokolleri

Bu grup muhtemelen sizde yoktur ve olmaması bir eksiklik değildir. Önceki dört grup kullanıcıya hizmet eder; bu grup boruların kendisini yönetir ve ancak belirli ölçekten sonra devreye girer.

BGP farklı ağlar arasında hangi yolun kullanılacağını pazarlık eder. İnternetin omurgasını çalıştıran protokoldür, ama kurumsal tarafta karşınıza dört senaryoda çıkar: iki ISP’li bir merkezde hat düştüğünde trafiğin diğerine kayması, şubeler arası IPSec tünellerinin üzerinde SD-WAN kurgusu, bulut sağlayıcıya kurulan özel bağlantılar, ve MPLS ile internet VPN’i arasında geçiş. Dördü de gerçek KOBİ ve orta ölçek senaryosudur; bunları yapılandırdığınız yer de genelde ağ kenarındaki firewall olur, ayrıntısı için kurumsal firewall kurulumu makalemize bakabilirsiniz.

OSPF ise kurum içinde çalışır ve birden fazla omurga cihazı arasında yol öğrenmeyi otomatikleştirir. Tek binalı, tek omurgalı bir yapıda gereksizdir; statik yönlendirme yeter ve daha öngörülebilirdir. Kampüs ölçeğinde ise elle yazılmış yolları bakımda tutmak imkansız hale gelir, işte orada anlamlıdır.

VRRP ve HSRP aynı sorunun iki markalı çözümüdür: iki router ya da Layer 3 switch tek bir sanal gateway adresini paylaşır, biri düşünce diğeri devralır ve istemciler bunu fark etmez. 802.1Q ise trafiği VLAN’lara ayıran etiketleme standardıdır; tek fiziksel kablo üzerinden birden fazla mantıksal ağı taşımak bunun sayesinde mümkün olur. Etiketin çerçevenin neresine girdiğini, access ile trunk portun farkını ve etiketsiz çerçevenin hangi VLAN’a düştüğünü VLAN ve 802.1Q rehberimizde gerçek paket dökümüyle ele aldık. Bu ikisinin tasarım tarafı switch ve router kurulumu makalemizde işleniyor.

Bu gruba ne zaman ihtiyaç duyulduğunu somutlaştırmak gerekirse:

Buradaki dürüst tavsiye şu: bu protokolleri “kurumsal görünsün” diye devreye almayın. Her biri bir arıza senaryosuna cevap verir ve o senaryo sizde yoksa yalnızca yönetim yükü ekler. Tek binalı, tek omurgalı bir yapıda statik yönlendirme hem yeter hem daha öngörülebilirdir.

Yönetmek: RDP, SSH ve Telnet

Bu grup son kullanıcının değil, sistemi yönetenin kapısıdır ve güvenlik açısından en hassas olanıdır. Diğer beş grup çalışmaya devam etsin diye birinin uzaktan bağlanıp müdahale etmesi gerekir; bu grup o bağlantıyı taşır. Dairenin vatandaş girişi değil, personel kapısıdır.

RDP (3389) Windows’un uzak masaüstü protokolüdür ve iki ayrı hayatı vardır. Birincisi yöneticinin sunucuya bağlanıp müdahale etmesidir. İkincisi son kullanıcıya masaüstü dağıtmaktır; terminal sunucu kurgusunda onlarca kullanıcı aynı sunucuda kendi oturumunu açar ve kendi bilgisayarında çalışıyormuş gibi hisseder. İkinci senaryoda RDP artık bir yönetim protokolü değil, doğrudan iş yapma katmanıdır. Bu ayrımı bilmek lisanslamayı da etkiler, çünkü terminal sunucu kullanımı ayrı bir erişim lisansı ister. Protokolün ekran yerine çizim tarifi taşımasını, sunucunun kimlik doğrulanmadan önce ağa ne söylediğini ve Remote Desktop Users yetkisinin aslında nereden geldiğini RDP nedir rehberimizde ölçümlerle ele alıyoruz.

RDP hakkında bilinmesi gereken tek bir kural varsa şudur: internete doğrudan açılmaz. Fidye yazılımı vakalarında en sık görülen ilk giriş yolu, dışarıya açık bırakılmış bir RDP portudur. Doğru kurgu bağlantıyı VPN arkasına almak, RD Gateway kullanmak ya da bir atlama sunucusu üzerinden geçirmektir; Ağ Düzeyinde Kimlik Doğrulama da açık bırakılmalıdır. “Sadece geçici olarak açtık” diye bırakılmış portların ne kadar kalıcı olduğunu görmek insanı şaşırtıyor.

HTTPS (443) bu grubun en çok kullanılan ama en az fark edilen üyesidir. Bugün bir firewall’u, sanallaştırma yöneticisini, NAS’ı, yönetilebilir switch’i veya sunucunun uzaktan yönetim kartını yapılandırırken karşınıza çıkan o web arayüzü bu protokolle çalışır. Yani HTTPS yalnızca kullanıcıların internette gezdiği protokol değil, altyapının kumanda paneli. HTTP (80) ise aynı işi şifresiz yapar ve bir yönetim arayüzünde kabul edilemez; parola düz metin gider.

Buradaki yaygın sorun sertifikadır. Yönetim arayüzleri çoğunlukla kendinden imzalı sertifikayla gelir, tarayıcı uyarı verir, ekipler de bu uyarıyı tıklayıp geçmeye alışır. Alışkanlık tehlikelidir: gerçek bir ortadaki adam saldırısında aynı uyarı çıkacak ve aynı refleksle geçilecektir. Doğru hamle kurum içi sertifika otoritesinden düzgün sertifika dağıtmak ve uyarıyı istisna değil kural dışı hale getirmektir. Sertifikanın yanında ikinci bir soru daha var ve çoğu zaman hiç sorulmaz: o arayüz hangi TLS sürümünü konuşuyor? Sunucunuzun ne konuştuğunu ölçmek, sanıldığından sık olarak eski bir sürümün hâlâ açık kaldığını gösterir. RDP için söylediğimiz kural burada da aynen geçerli: yönetim arayüzleri internete açılmaz.

SSH (22) Linux sunucuların ve ağ cihazlarının yönetim kapısıdır. Trafiği şifreler, bağlandığınız cihazın kimliğini bir anahtar parmak iziyle kanıtlar ve parola yerine anahtar tabanlı kimlik doğrulamayı destekler; doğru yapılandırmada parolayla giriş tamamen kapatılır. El sıkışmada ne olduğunu, parmak izinin neyi kanıtladığını ve gerçek bir cihazda hangi varsayılanların tehlikeli kaldığını SSH rehberimizde ölçümlerle ele alıyoruz. İşi yalnızca komut satırı da değildir, dosya aktarımı ve tünelleme aynı kanaldan yürür. Modern switch ve firewall’ların yönetim arayüzü de bu protokolü konuşur, yani SSH yalnız sunucucunun değil ağ ekibinin de günlük aracıdır.

Telnet (23) aynı işi şifresiz yapar. Parolanız ağda düz metin olarak dolaşır; trafiğin geçtiği yolda durabilen herkes onu okuyabilir. Yıllar önce emekli olması gereken bu protokolü hâlâ buluyoruz: bir kez yapılandırılıp bir daha dokunulmamış switch’lerde, konsol sunucularında ve endüstriyel cihazlarda açık duruyor. Doğru hamle kapatmaktır; eski bir cihaz yüzünden kapatılamıyorsa en azından ayrı bir yönetim VLAN’ına hapsedilmelidir. Gerçek bir yönetilebilir switch’ten alınmış paket dökümünü, kapatma sırasını ve kapatırken cihazın dışında kalmamanın yolunu Telnet nedir rehberimizde ele alıyoruz.

Ağ cihazlarının yanında bir de TFTP (69) durur. Adı FTP’yi çağrıştırsa da onunla akraba değildir; kimlik doğrulaması hiç yoktur ve sadece yerel yönetim ağında anlamlıdır. Switch ve router yapılandırmalarının yedeklenmesi ile ağ üzerinden işletim sistemi kurulumu (PXE) bu protokolle yürür. Yönetim VLAN’ının dışına asla çıkarılmaz. Protokolün nasıl çalıştığını, isteğin 69’a gidip cevabın neden başka bir porttan döndüğünü ve bir switch yedeğinin paket dökümünde nasıl göründüğünü TFTP nedir makalemizde ele alıyoruz.

Burada makalenin başındaki ayrıma güzel bir örnek çıkıyor. Telnet protokolünün kullanımı bırakılmalıdır, ama telnet istemcisi hâlâ işe yarar: telnet sunucu 25 yazıp bir portun açık olup olmadığını saniyeler içinde test edersiniz. İşin ilginci, o sırada Telnet protokolünü konuşuyor bile değilsinizdir; istemci yalnızca ham bir TCP bağlantısı açar ve yazdıklarınızı olduğu gibi karşıya geçirir. Protokol ile onu konuşan yazılım aynı şey olmadığı için biri emekliye ayrılırken diğeri alet çantasında kalabiliyor.

Bir Oturum Açmanın Anatomisi: Protokoller Nasıl Zincirlenir?

Buraya kadar protokolleri tek tek gezdik, ama gerçek değerleri tek tek çalışmalarında değil, birbirini şart koşmalarında. Bunu görmenin en iyi yolu tek bir olayı baştan sona izlemek: sabah 09:00, bir çalışan domain’e üye laptopunu açıyor ve oturum açıyor. Kullanıcı tek bir parola giriyor. Arkada altı protokol sırayla devreye giriyor ve her biri bir öncekinin çıktısına muhtaç.

1. Kapıdan giriş. Kablo takılır ya da kablosuz ağa bağlanılır. Ağda 802.1X yapılandırılmışsa switch portu daha hiçbir trafiğe izin vermeden kimlik ister; istek RADIUS sunucusuna gider. Doğrulama başarısızsa hikaye burada biter. Cihaz kablonun takılı olduğunu görür ama hiçbir şey olmaz, ki bu belirti çoğu teknisyeni yanlış yere bakmaya götürür.

2. Adres alınır. Cihaz DHCP ile konuşur ve IP adresini, subnet maskesini, gateway’ini ve hangi DNS sunucusunu kullanacağını öğrenir. Bu adımın çıktısı bir sonraki adımın girdisidir; DNS sunucusunun adresi de bu pakette gelir. Adres alınamazsa cihaz 169.254.0.0/16 bloğundan kendi kendine bir adres üretir ve zincir daha ikinci halkada kopar.

3. Kim nerede, öğrenilir. Laptop hangi Domain Controller’a başvuracağını bilmez. DNS’e sorar ve _ldap._tcp.dc._msdcs altındaki SRV kayıtlarından kendisine en uygun DC’yi öğrenir. Burada kritik bir ayrıntı var: istemcinin birincil DNS’i iç Domain Controller değil de bir dış DNS ise, bu sorgu cevapsız kalır. İnternet çalışır, sayfalar açılır, ama domain oturumu açılmaz. Sahada en çok yanlış teşhis edilen arıza tam olarak budur.

4. Saatler karşılaştırılır. Cihaz saatini domain hiyerarşisi üzerinden NTP ile senkronize eder. Fark beş dakikayı aşıyorsa bir sonraki adım baştan başarısız olur. Belgenin üstündeki tarih tutmuyor demektir.

5. Bilet alınır. Kerberos devreye girer. Önce bilgisayar hesabı, sonra kullanıcı kimlik doğrular ve KDC’den süreli bir bilet alır. Parola ağ üzerinden gitmez; bundan sonraki her erişimde bu bilet ibraz edilir.

6. Yetki sorulur. Oturum açıldı, ama bu kullanıcı neye yetkili? LDAP ile dizin sorgulanır: hangi gruplarda, hangi OU’da, üzerine hangi grup ilkeleri düşüyor.

7. İş yapılır. Son olarak SMB devreye girer. SYSVOL paylaşımından politika dosyaları okunur ve uygulanır, ağ sürücüleri bağlanır, kullanıcı dosya sunucusundaki klasörünü görür. Masaüstü açıldığında kullanıcının “çalışıyor” dediği an burasıdır.

Bu listede numarası olmayan bir adım daha var. Laptop bir paketi kabloya her koyduğunda, hedefin donanım adresini bilmek zorundadır: DHCP’den adresi aldıktan sonra DNS sunucusuna ulaşabilmek için, DC’yi bulduktan sonra ona bilet sorabilmek için, SYSVOL’e bağlanabilmek için. Bu iş ARP ile yapılır ve numarası yoktur, çünkü sırada bir yeri yoktur: adımların arasındadır. Bozulduğunda kendi adıyla şikayet etmez, o an hangi adımdaysanız o adımın protokolü suçlanır. Sessiz çalışan bu katmanın teşhisi bu yüzden ayrı bir konudur.

Yedi adım, altı protokol, bir parola. Kullanıcı bunların hiçbirini görmez ve görmemesi gerekir. Ama siz gördüğünüzde, bir sonraki bölümdeki teşhis tablosu kendiliğinden anlam kazanır.

Aynı Protokol, Farklı Uygulama: Windows, Linux ve Ağ Cihazları

Protokol standarttır, onu konuşan yazılım tercihtir. Aynı DHCP protokolünü Windows Server da konuşur, Linux üzerindeki Kea da, kenardaki firewall da, Layer 3 switch de. Dördü de aynı DORA akışını uygular ve istemci hangisiyle konuştuğunu bilmez bile. Hangi memur bakarsa baksın form aynı formdur.

O halde soru “hangisi daha iyi” değil, “bu kurumda hangisi doğru” olmalıdır. Cevabı belirleyen şey marka tercihi değil ölçek, mevcut altyapı ve ekibin yetkinliğidir.

Tablodaki ilk satır önemli bir dürüstlük noktası içeriyor. Domain kullanan bir kurumda Windows tarafını seçmek çoğu zaman doğru karardır ve bunun sebebi lisans satmak değil, zincirin kendiliğinden kapanmasıdır: DHCP dağıttığı adresi DNS’e yazar, DNS kaydı domain oturumunu mümkün kılar, oturum grup ilkesini tetikler. Aynı işi Linux tarafında kurmak mümkündür ama dinamik DNS entegrasyonunu elle kurmanız gerekir ve o el emeği bir kereye mahsus değildir, ömür boyu bakımdadır.

Öte yandan on kişilik bir şubeye yalnızca adres dağıtsın diye sunucu koymak da savunulamaz. Oradaki firewall bu işi zaten yapıyordur ve doğru cevap odur. Karar, ürünün iyiliğine değil senaryonun büyüklüğüne bakar.

Protokoller Bozulduğunda: Teşhis Sırası

Arıza çözerken en çok vakit kaybettiren şey yanlış katmandan başlamaktır. İşlev gruplarını bağımlılık sırasına göre kurmuş olmamızın asıl faydası burada ortaya çıkıyor: belirti size zincirin nerede koptuğunu söyler, siz de aramayı tek hamlede daraltırsınız.

Kural basit. Aşağıdaki halka çalışmıyorsa yukarıdakini kontrol etmenin anlamı yoktur. Adres alamamış bir cihazda Kerberos ayarlarını incelemek, adres beyanı olmayan vatandaşın sicil kaydını sorgulamaya benzer.

Son satır teknik bir arıza değil, ama en pahalıya patlayanı o. Bir sorunun günlerce fark edilmemesi, o sorunun kendisinden daha çok zarar verir.

Zincirin ilk üç halkasını tek tek yoklamak için üç komut yeterli. Sırayla çalıştırın, ilki hangi adımda çuvallarsa arıza oradadır:

# 1. Adres alınmış mı, hangi sunucudan, kirası ne zaman doluyor
ipconfig /all

# 2. İstemci hangi Domain Controller'ı buluyor (boş dönerse DNS yanlış)
nslookup -type=srv _ldap._tcp.dc._msdcs.ad.sercebilisim.com

# 3. Saat farkı Kerberos toleransını aşmış mı
w32tm /query /status

# 4. Hedef porta gerçekten ulaşılıyor mu (445 = SMB, 88 = Kerberos)
Test-NetConnection dc01 -Port 445

Linux tarafında karşılıkları ip addr, dig SRV _ldap._tcp.dc._msdcs.ad.sercebilisim.com, chronyc tracking ve nc -vz dc01 445 olur. Komutlar değişir, sorulan soru aynıdır.

Bu tabloyu kullanırken tek bir alışkanlık kazanmanız yeterli: hata mesajını değil, zincirdeki konumu dinleyin. Protokol hataları neredeyse hiçbir zaman kendi adlarını vermez. DNS yanlış yazıldığında ekranda “DNS” yazmaz, “etki alanına ulaşılamıyor” yazar. Saat kaydığında “saat” yazmaz, güven ilişkisinden bahseder. Belirtiyi doğru katmana oturtmak, hata metnini okumaktan çok daha güvenilir bir yöntemdir.

Sonuç: Görünmeyen Ama Her Şeyi Taşıyan Katman

Bir şirkette hiç kimse sabah işe gelip “bugün Kerberos nasıl” diye sormaz. Protokoller doğru çalıştığında görünmezdir; kullanıcı yalnızca masaüstünün açıldığını ve dosyasının yerinde olduğunu bilir. Bu görünmezlik onların başarısıdır, önemsizliği değil.

Bu makalede altı işlev grubunu gezdik, tek bir oturum açmanın yedi adımını izledik ve belirtiden kopan halkaya giden bir teşhis sırası kurduk. Buradan çıkarılacak tek bir cümle varsa şudur: protokoller tek tek değil, zincir olarak çalışır. Bir kurumun ağını sağlam yapan şey, en güçlü halkası değil, en zayıf halkasının nerede olduğunun biliniyor olmasıdır.

Kurumsal altyapıda çalışırken bunun pratik karşılığı da nettir. Bir arızada önce zincirin başına gidin, ürün seçerken ölçeğe bakın, izlemeyi kurarken sahibini de yazın. Serçe Bilişim olarak network projelerinde ilk yaptığımız iş yeni cihaz önermek değil, bu zincirin hangi halkasının gerçekten sağlam olduğunu ölçmektir; çünkü çoğu zaman sorun eksik donanımda değil, kimsenin bakmadığı bir halkada durur.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.