DHCP Nedir? Ağda IP Adresi Nasıl Dağıtılır?

DHCP (Dynamic Host Configuration Protocol), ağa bağlanan bir cihaza IP adresini ve o adresle konuşabilmesi için gereken subnet, gateway ve DNS bilgisini otomatik olarak veren protokoldür. Olmadığı bir ağda her bilgisayara, telefona, yazıcıya ve kameraya bu dört bilgiyi tek tek elle girmeniz gerekir. Elli cihazlık bir ofiste bu bir günlük iştir; sonrasında da hangi adresin kimde olduğunu hatırlamak zorunda kalırsınız.

Yeni bir apartmanı düşünün. Bina bittiğinde daireler fiziksel olarak hazırdır ama kimsenin adresi yoktur. Numaraları dağıtan yönetim olmadan kargo gelmez, fatura ulaşmaz, ambulans doğru kapıyı bulamaz.

Yönetim her daireye bir numara verir, bunu bir listede tutar, boşalan daireyi listeden düşer ve yeni gelene aynı numarayı yeniden verir. Kimse kendi numarasını kendi seçmez; seçseydi iki daire aynı numarayı alır ve kargolar karışırdı. DHCP ağda tam olarak bu yönetim rolündedir: adresi o dağıtır, süresini o belirler, kimin hangi adresi kullandığını o bilir.

Bu makale kurumsal network kurulumu hizmetimizin adresleme katmanına odaklanır. DHCP, bir kurumu ayakta tutan protokol zincirinin adres halkasıdır; zincirin tamamını, hangi protokolün ne yaptığını ve bir arızada hangi halkanın koptuğunun belirtiden nasıl anlaşıldığını kurumsal ağ protokolleri rehberimizde ele alıyoruz.

Aşağıda önce DHCP’nin ne işe yaradığını, sonra arka planda dört mesajla nasıl çalıştığını, dağıttığı bilgilerin her birinin ne anlama geldiğini, adres alınamadığında ortaya çıkan 169.254.x.x adresini ve farklı VLAN’lardaki cihazların adresi nasıl aldığını göreceğiz. Apartmana her bölümde geri döneceğiz. Elinizde şu an adres alamayan bir cihaz varsa doğrudan teşhis sırasına atlayabilirsiniz.

DHCP Nedir, Ne İşe Yarar?

DHCP, ağa bağlanan cihaza konuşabilmesi için gereken dört bilgiyi otomatik olarak veren protokoldür: IP adresi, subnet maskesi, default gateway ve DNS sunucusu. Bu dördü tamamlanmadan cihaz ağa fiziksel olarak bağlıdır ama hiçbir yere ulaşamaz. Kablo takılıdır, port ışığı yanar, hiçbir şey olmaz. Protokolün IPv4 için bugün de geçerli tanımı Mart 1997 tarihli RFC 2131 belgesidir.

Elle Adresleme Neden Ölçeklenmez?

Elle adresleme (statik IP), bu dört bilgiyi her cihaza tek tek girmek demektir ve asıl maliyeti girişte değil, sonrasında ortaya çıkar. Yirmi cihazda bir öğleden sonralık iştir. Yüz cihazda hangi adresin kimde olduğunu tutan bir liste gerekir ve o liste ya bir elektronik tabloda durur ya da birinin kafasında. İkisi de altı ay içinde gerçeği yansıtmayı bırakır.

Apartmana dönelim. Her daire sahibinin kendi numarasını kendi seçtiği bir bina düşünün. İlk beş daire sorunsuz yerleşir. Onuncu daire boş sandığı bir numarayı alır ve o günden sonra iki kapıya aynı kargo gider. Kimse yalan söylememiştir, kimse dikkatsiz de değildir; sadece kimsenin elinde tam liste yoktur.

Bu yüzden doğru soru “statik mi dinamik mi?” değil, adresin kaydını kimin tuttuğudur. Statik adres yanlış bir yöntem değildir; sahipsiz statik adres yanlıştır.

Bunun bedelini bir kurumda birebir gördüm. Danışmanlığa yeni başlamıştık, ortamda henüz Active Directory yoktu ve bir şubede DHCP sunucusu bozuldu. Birkaç gün adres dağıtılamayacağı için dağıtımı geçici olarak lokasyondaki Layer 3 switch’e aldık. Gözden kaçırdığımız şey şuydu: o şubedeki istemci sayısı /24 bir ağa rahat sığmıyordu ve switch üzerinde tanımladığımız havuz yetmedi. Bazı cihazlar adres alamadı.

Lokasyonda BT personeli yoktu. Teknik işlere bakan bir çalışan, adres alamayan her cihaza kendi inisiyatifiyle statik IP yazdı ve bunu kimseye söylemedi. Bizim tarafta switch sorunsuz dağıtıyor görünüyordu.

Sunucu tamir edilip dağıtımı geri devraldığında o statik adresler havuzun içinde kaldı ve yaklaşık kırk adres çakıştı. Asıl maliyet de tam burada çıktı: çakışan adresleri görmek kolaydı, hangi cihazlarda olduklarını bulmak zordu. Kaydı yalnız kafasında tutan kişi kurumdan ayrılmıştı ve lokasyonda soracak kimse yoktu.

Kalıcı çözüm adresleme tarafında değil, kimlik tarafında geldi. Active Directory kurulduktan sonra ağ bağdaştırıcısı ayarlarına (ncpa.cpl) erişimi Group Policy ile kapattık. Geçiş için de her açılışta ipconfig /release ve ipconfig /renew çalıştırıp adres alma ayarını otomatiğe çeken bir PowerShell script’i dağıttık; birkaç hafta sonra bütün cihazlar ayarı aldığında script’i devre dışı bıraktık. Silmedik, çünkü aynı ihtiyaç tekrar doğabilir; ilkenin açıklama alanına da neden konduğunu yazdık. Bu tür ayarları Group Policy ile yönetmeyi ayrı bir rehberde ele alıyoruz.

Hikâyenin dersi statik adresin kötü olduğu değil. Kaydı tutulmayan bir statik adres, onu yazan kişi gittiğinde kurumda kalan bir borca dönüşür.

DHCP’nin Çözdüğü Üç Problem: Çakışma, Taşınma, Envanter

DHCP’nin getirdiği kazanç “otomatik olması” değil, üç somut problemi ortadan kaldırmasıdır.

Çakışma. Adresi tek bir merci dağıttığında aynı numara iki cihaza verilemez, çünkü dağıtan taraf her seferinde kendi defterine bakar. Elle adreslemede bu güvence yoktur ve çakışma anında da anlaşılmaz: cihazlardan biri ağdan sessizce düşer, arıza günler sonra fark edilir. Makinenin çakışmayı ağda fark etmek için kullandığı ilan biçimi ise ayrı bir konudur ve gratuitous ARP başlığı altında anlatılıyor.

Taşınma. Cihaz ağ değiştirdiğinde adresinin de değişmesi gerekir. Laptop kablodan kablosuza geçtiğinde, şubeye gittiğinde ya da misafir ağına bağlandığında doğru bilgiyi bulunduğu ağdan alır ve kullanıcı hiçbir şey yapmaz. Aynı laptopta statik adres yazılıysa cihaz ikinci ağda hiç çalışmaz.

Envanter. DHCP hangi adresin ne zaman hangi cihazda olduğunu kayıt altına alır. Bu kayıt sorun giderirken işe yarar, ama bir de yasal karşılığı vardır: personeline internet erişimi veren her işletme 5651 sayılı kanun kapsamında iç IP ile cihaz eşleşmesini saklamakla yükümlüdür ve o eşleşmenin kaynağı tam olarak DHCP kira listesidir. Kapsam ve saklama süresi ayrıntıları 5651 log yönetimi rehberimizde.

DHCP Nasıl Çalışır? DORA ve Kira Döngüsü

DHCP arka planda dört mesajla çalışır ve verdiği adres kalıcı değil, sürelidir. Protokolün tamamı bu iki cümlede; geri kalan bütün davranışları bu ikisinden türer.

DORA: Discover, Offer, Request, Acknowledge

Dört mesajın İngilizce adlarının baş harflerinden gelen bu akış saniyenin altında tamamlanır ve kullanıcı hiçbirini görmez. Mesajların adları protokolde İngilizce geçer, sahada da öyle söylenir; Türkçe karşılıklarını burada bir kez veriyoruz ki hangi adımda ne olduğu akılda kalsın.

Discover (Keşif). Ağa yeni bağlanan cihazın henüz adresi yoktur, dolayısıyla belirli bir hedefe paket gönderemez. Ağdaki herkese ulaşan bir yayın (broadcast) yapar: “Burada adres dağıtan var mı?” Yeni taşınan kişinin, kimin yönetici olduğunu bilmediği için bahçeye çıkıp sesini duyurmasıdır bu.

Offer (Teklif). Yayını duyan sunucu bir teklifle döner: “Sana 192.168.10.57 numarasını verebilirim, süresi sekiz gün, sokak kapısı şu, zil panosu şurada.” Aynı ağda birden fazla sunucu varsa hepsi teklif verebilir.

Request (İstek). İstemci gelen tekliflerden birini seçer ve seçtiğini yine yayınla duyurur. Bu adımın yayın olması önemlidir: reddedilen sunucular da duyar ve ayırdıkları adresi havuza geri koyar. Yeni sakinin “on iki numarayı kabul ediyorum” diye yüksek sesle söylemesi, diğer yöneticilerin kendi listelerini düzeltmesini sağlar.

Acknowledge (Onay). Seçilen sunucu onaylar, kaydı deftere geçer, kira başlar. Sözleşme imzalanmıştır; numara artık o dairenindir.

İlk iki mesajın yayın olmak zorunda olmasının bir sonucu var ve bu makalede iki kez daha karşınıza çıkacak: yayın trafiği kendi ağ segmentinin dışına çıkmaz.

Kira Süresi (Lease Time) ve Yenileme: T1 ve T2

DHCP’nin verdiği adres kira süresi (lease time) boyunca geçerlidir; Windows tarafındaki varsayılan sekiz gündür. Süre dolmadan yenilenir, yenilenmezse adres havuza döner ve başkasına verilebilir.

Yenileme iki eşikte denenir. Sürenin yarısında (T1) istemci doğrudan adresi aldığı sunucuya gider ve uzatma ister; bu bir yayın değil, adresi bilinen sunucuya yapılan tekil bir istektir. Cevap gelmezse istemci sürenin yüzde 87,5’ine (T2) kadar bekler ve bu kez ağdaki herhangi bir sunucuya yayınla seslenir. O da cevapsız kalırsa süre dolduğunda adres bırakılır, döngü Discover’dan yeniden başlar. Sözleşme yarılandığında sakin yönetime uğrayıp uzatmayı sorar; yönetim yerinde değilse, süre dolmaya yaklaştığında kime denk gelirse ona sorar.

Bunun çok pratik bir sonucu var: DHCP sunucusu kapandığında ağ hemen kopmaz. Cihazlar kiraları bitene kadar çalışmaya devam eder. Sekiz günlük bir kirada arıza günler sonra ve hepsi aynı anda değil, dağınık biçimde ortaya çıkar. DHCP arızalarının çoğu zaman kesintinin kendisiyle değil, çok sonrasıyla ilişkilendirilmesinin sebebi budur.

Kira Süresi Ne Kadar Olmalı?

Kira süresini belirleyen tek ölçüt, o ağdaki cihaz devir hızıdır. Sabit bir ofiste cihazlar aylarca aynıdır ve sekiz günlük varsayılan rahatlıkla yeter. Misafir ağı, kafe veya etkinlik alanında ise cihaz gün içinde gelir ve gider: 254 adreslik bir havuz, günde beş yüz misafir ağırlayan bir yerde sekiz günlük kirayla daha ilk öğleden sonra dolar. Oralarda kira iki dört saate, tek günlük konferans kurulumlarında bir saate iner.

Ters uca da dikkat edin, çünkü sezgi burada yanıltır: “ne kadar kısa o kadar temiz” doğru değildir. Kira kısaldıkça cihazlar sunucuya daha sık döner ve sunucunun kısa bir kesintisi daha hızlı hissedilir. Bir saatlik kirada yarım saatlik bakım penceresi ağın yarısını etkiler; sekiz günlükte kimse fark etmez.

İkinci bedeli ise ağın kendisi öder. Burada bir incelik var: yenileme istekleri tekil (unicast) gittiği için kısa kira yayın trafiğini doğrudan katlamaz. Ama dolaylı olarak artırır. Kira kısaldıkça, uykudan uyanan ya da kablosuzda dolaşan bir cihazın kirasını dolmuş bulma ihtimali yükselir; o cihaz artık yenileme yapamaz, dört mesajlık akışı baştan işletir.

Discover ile Request birer yayındır ve bahçeye seslenen kişiyi, ilgilensin ilgilenmesin bütün blok duyar. Sunucusuna T1’de ulaşamayan her istemci de T2’de aynı bahçeye çıkar. Yüzlerce cihazın aynı düz segmentte durduğu bir ağda bu yayın yükü ölçülebilir hale gelir ve bedelini yalnız sunucu değil, yayını dinlemek zorunda kalan her cihaz öder.

Bunu yayın fırtınasıyla (broadcast storm) karıştırmamak gerekiyor, çünkü ikisi farklı şeylerdir ve çözümleri de farklıdır. Fırtına, döngüye girmiş bir Layer 2 topolojisinin ürettiği ayrı bir arızadır; ilacı kira süresi değil, döngü korumasıdır. Switch’teki döngü korumalarını STP korumaları yazımızda ölçtüm. Buradaki şey bir arıza değil, ağın sürekli ödediği bir vergidir. Dolayısıyla kirayı kısaltmak için tek geçerli gerekçe havuzun dolmasıdır. “Daha temiz olsun” diye kısaltmayın: her kısaltma hem dayanıklılıktan hem ağ veriminden bir parça alır.

DHCP Hangi Bilgileri Dağıtır? IP, Subnet, Gateway ve DNS

DHCP tek bir değer değil, bir paket teslim eder. Adresini DHCP’den almış bir Windows makinesinde ipconfig /all çalıştırdığınızda paketin tamamını tek ekranda görürsünüz:

   Connection-specific DNS Suffix  . : ad.sistemkusu.com
   IPv4 Address. . . . . . . . . . . : 192.168.10.57
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.10.1
   DHCP Enabled. . . . . . . . . . . : Yes
   DHCP Server . . . . . . . . . . . : 192.168.10.11
   Lease Obtained. . . . . . . . . . : 5 Ağustos 2026 09:14:22
   Lease Expires . . . . . . . . . . : 13 Ağustos 2026 09:14:22
   DNS Servers . . . . . . . . . . . : 192.168.10.10

DHCP Server satırı adresi kimin verdiğini, Lease Obtained ve Lease Expires satırları kiranın ne zaman başlayıp ne zaman biteceğini söyler. Aradaki fark sekiz gündür ve bu, sunucuda tanımlı kira süresidir. DHCP Enabled satırı No diyorsa ve kira satırları hiç yoksa, o makinenin adresi elle yazılmıştır; teşhise oradan devam edilir.

IP Adresi ve Subnet Maskesi: Daire Numarası ve Bina Sınırı

IP adresi cihazın ağdaki kimliğidir, subnet maskesi ise o kimliğin hangi ağa ait olduğunu söyler. Yukarıdaki çıktıda 192.168.10.57 adresi ile 255.255.255.0 maskesi birlikte okunur: cihaz 192.168.10.0/24 ağındadır ve o ağdaki adreslerle doğrudan konuşabilir.

Daire numarası tek başına bir şey ifade etmez; hangi binanın on iki numarası olduğu bilinmelidir. Maske tam olarak binanın sınırıdır. Hedef aynı binadaysa merdivenden çıkar, komşunun kapısını çalarsınız; değilse sokağa çıkmanız gerekir.

Maske yanlış yazıldığında ortaya çıkan arıza bu yüzden kafa karıştırıcıdır: cihazın adresi vardır, kendi ağındaki bazı cihazlara ulaşır, bazılarına ulaşamaz. Adrese bakıp bir şey bulamazsınız. Bakılacak yer sınırdır.

Sınırın bit düzeyinde nasıl çizildiğini, /24 gösteriminin ne anlattığını ve yanlış maskenin lab ortamında ölçülen etkisini subnet maskesi ve CIDR makalemizde ele alıyoruz.

Default Gateway: Binanın Sokak Kapısı

Default gateway, cihazın kendi ağının dışına giden trafiği teslim ettiği adrestir; pratikte ağın router’ı ya da firewall’udur. Örnekteki 192.168.10.1 bu görevi üstlenen cihazın adresidir ve hedefi kendi ağının dışında olan her paket önce oraya gider.

Binanın sokak kapısıdır. Komşuya gitmek için sokağa çıkmazsınız, ama binanın dışındaki her yer için tek çıkış oradadır.

Gateway eksik veya yanlışsa belirti çok tipiktir: yerel ağ çalışır, internet çalışmaz. Kullanıcı size “yazıcıya basabiliyorum ama hiçbir site açılmıyor” der. Bu cümle neredeyse her zaman adresin değil, çıkış kapısının sorunudur ve ipconfig /all çıktısının tek bir satırında görünür.

DNS Sunucusu: Lobideki Zil Panosu

DNS sunucusu, isimleri adrese çeviren adrestir; cihaz bir siteye ya da sunucuya ismiyle ulaşmak istediğinde önce oraya sorar. Lobideki zil panosu gibi çalışır: kimin hangi dairede oturduğunu okursunuz, numara ezberlemenize gerek kalmaz.

Kurumsal ağda bu, DHCP’nin dağıttığı en kritik bilgidir ve en sık yanlış doldurulanıdır. Domain ortamında istemcinin DNS’i iç Domain Controller olmalıdır. Buraya 8.8.8.8 gibi bir dış adres yazıldığında internet sorunsuz çalışır, ama istemci hangi Domain Controller’a başvuracağını bulamaz ve domain oturumu açılmaz. Sahada en çok yanlış teşhis edilen arızalardan biri budur, çünkü ekrandaki hata mesajında DNS kelimesi hiç geçmez. İsim çözümlemenin nasıl çalıştığını, hangi kaydın ne taşıdığını ve bir arızada nereye bakılacağını DNS nedir rehberimizde ele alıyoruz.

APIPA ve 169.254.x.x: DHCP’ye Ulaşılamadığında

Bir cihaz DHCP sunucusundan cevap alamazsa adressiz kalmaz: 169.254.0.0/16 bloğundan kendine bir adres üretir. Buna APIPA (Automatic Private IP Addressing) denir ve bir çözüm değil, bir arıza bildirimidir.

APIPA Adresi Ne Anlama Gelir, Neyi Yapamazsınız?

169.254.x.x biçiminde bir adres gördüğünüzde tek bir şey kesindir: o cihaz hiçbir DHCP sunucusundan cevap alamamıştır. Adresi kendisi üretmiştir, kimse ona vermemiştir ve ağda kimse bu adresi tanımıyordur.

Numara alamayan kişinin merdiven boşluğuna yerleşmesi gibidir. Binanın içindedir, aynı durumdaki birkaç kişiyle konuşabilir, ama kapısında numara yoktur: kargo gelmez, fatura ulaşmaz, dışarıdan kimse onu bulamaz.

Teknik karşılığı da bu kadar dardır. APIPA adresiyle cihaz yalnızca aynı segmentte ve yine APIPA’da olan cihazlarla konuşabilir. Gateway gelmez, dolayısıyla internet yoktur; DNS gelmez, dolayısıyla isimle hiçbir yere erişilemez; domain oturumu açılmaz. Cihaz ağa bağlıdır ve ağda değildir.

Buradan çıkacak en işe yarar sonuç şu: APIPA cihazın arızası değil, cihazın size verdiği rapordur. Bakılacak yer cihaz değil, cihazla sunucu arasındaki yoldur.

169.254.x.x Gördüğünüzde Sırayla Nereye Bakılır?

Bu adresi gördüğünüzde beş yeri sırayla kontrol edin. Sıra tesadüfi değil: ucuzdan pahalıya, yakından uzağa doğru ilerliyor.

1. Aynı ağdaki diğer cihazlar ne durumda? İlk soru bu olmalı, çünkü aramayı tek hamlede yarıya böler. Tek bir cihaz APIPA’daysa sorun o cihazda veya bağlı olduğu portta; herkes APIPA’daysa sorun sunucuda ya da yoldadır.

2. Fiziksel bağlantı ve switch portu. Kablo, port durumu, VLAN ataması. Ağda 802.1X yapılandırılmışsa port kimlik doğrulanana kadar hiçbir trafiğe izin vermez ve belirti birebir aynıdır: kablo takılı, adres yok. Kimlik katmanının adres katmanından önce geldiğini ağ protokolleri rehberimizde ele alıyoruz.

3. Sunucu ve servis ayakta mı, havuz aktif mi? Servis çalışıyor görünse bile yetkilendirme veya aktivasyon eksikse tek bir adres bile dağıtılmaz.

4. Havuzda boş adres kaldı mı? Dolu havuz sessizce aynı belirtiyi üretir: sunucu ayaktadır, isteği duyar ve verecek adresi yoktur. Misafir ağlarında en sık sebep budur ve çözümü sunucuyu büyütmek değil, kira süresini kısaltmaktır.

5. Cihaz sunucuyla aynı VLAN’da mı? Değilse istek sunucuya hiç ulaşmıyor olabilir. Bir sonraki bölümün konusu tam olarak budur.

Bu sırayı yürütürken istemci tarafında üç komut yeterlidir:

ipconfig /all
ipconfig /release
ipconfig /renew

ipconfig /renew sonrasında hâlâ 169.254.x.x görüyorsanız istemcide yapılacak bir şey kalmamıştır. Cevap veren yoktur ve arama artık sunucuya doğru ilerlemelidir.

DHCP Relay: Farklı VLAN’lardan Adres Almak

Broadcast Neden VLAN Sınırında Durur?

DHCP Discover mesajı bir yayındır ve yayın trafiği kendi ağ segmentinin dışına çıkmaz; router ve Layer 3 switch onu geçirmez. Bu bir eksiklik değil, bilinçli bir tasarımdır: yayınlar segment sınırında durmasaydı, kurumdaki her cihazın her yayını bütün kuruma dağılır ve ağ kendi gürültüsünde boğulurdu.

Bu sınırı çizen mekanizmanın adı 802.1Q etiketlemesidir; etiketin çerçeveye nasıl girdiğini ve portların onu nasıl işlediğini VLAN rehberimizde ele aldık.

Sonucu şu: on VLAN’a bölünmüş bir ağda DHCP sunucusu yalnızca kendi VLAN’ındaki cihazların sesini duyar. Diğer dokuz VLAN’daki her cihaz, sunucu bir kat üstte sapasağlam ayakta dururken APIPA’ya düşer. Bahçeye seslenen yeni sakini yalnızca kendi bloğu duyar; yönetim başka bloktaysa hiçbir şey duymaz ve ortada bir sorun olduğunu da bilmez.

İki yol kalır: ya her bloğa ayrı bir yönetim kurarsınız, ki bu on sunucu ve on ayrı defter demektir, ya da sesi yönetime taşırsınız.

IP Helper: Yayını Sunucuya Taşımak

DHCP relay, bir VLAN’daki DHCP yayınlarını alıp sunucuya doğrudan ileten ayardır ve o VLAN’ın gateway’i olan cihaza, yani router ya da Layer 3 switch’e yazılır. Cisco terminolojisindeki karşılığı ip helper-address komutudur.

Relay İngilizcede röle demektir ve adı işini anlatır. Gündelik hayattaki röle, bir devreden gelen küçük bir sinyalle başka bir devreyi çalıştıran ara parçadır. Telsizcilerin röle istasyonu da dağın tepesinde durur, kısa menzilli bir telsizin sesini alır ve daha uzağa yeniden yayınlar. DHCP relay de aynı işi yapar: VLAN’ın içinde kalan yayını duyar ve onu sunucuya yeniden gönderir.

Her bloğa bir kapıcı koymak gibidir. Kapıcı yönetici değildir, karar vermez; yeni gelenin talebini yönetime götürür ve cevabı geri getirir. Numaraları dağıtan taraf hâlâ tektir, defter hâlâ tek yerdedir.

Sahada bu ayarın en sık unutulduğu an, yeni bir VLAN açıldığı andır: VLAN tanımlanır, gateway yazılır, relay atlanır. Belirti o VLAN’a ilk cihaz bağlanana kadar görünmez, dolayısıyla yapılandırmayı yapan kişiyle arızayı yaşayan kişi genellikle farklı olur. VLAN açma prosedürünüze bu tek satırı ekleyin. Segment tasarımının kendisini switch ve router kurulumu makalemizde ele alıyoruz.

Başka Ağdaki Sunucu VLAN’a Nasıl Adres Verir?

İlk bakışta tuhaf görünen bir durum var. Sunucu ağında, örneğin 192.168.1.15 adresinde duran bir DHCP sunucusu, muhasebe VLAN’ındaki bir bilgisayara 10.34.70.111 gibi kendi ağında olmayan bir adres veriyor. Bunun açıklaması, adresin sunucunun üzerinde durmamasıdır. DHCP sunucusu için bir adres listedeki bir satırdır: sunucu her ağ için ayrı bir havuz tutar ve hangi havuzdan vereceğini relay’in pakete yazdığı nottan anlar.

O not, paketteki Gateway-IP alanıdır (standarttaki adı giaddr). Relay isteği iletirken bu alana kendi adresini, yani yayının geldiği VLAN’daki adresini yazar. Sunucu bu adresin hangi havuza düştüğüne bakar ve adresi o havuzdan seçer. İki kural da DHCP standardında, RFC 2131’de yazılı:

1. Havuz seçimi (bölüm 4.3.1): adres, “the address of the relay agent that forwarded the message (‘giaddr’ when not 0)” bilgisine göre seçilir.
2. Cevabın yolu (bölüm 4.1): sunucu cevabı Gateway-IP’de yazan relay’e gönderir, relay de teklifi VLAN’ın içine indirir.

Örnekteki sitede kapıcı, yeni gelenin talebini yönetime götürürken zarfın üstüne kendi blok numarasını yazar. Yönetim her bloğun daire listesini ayrı tutar. Zarftaki blok numarasına bakar, o bloğun listesinden boş bir daire seçer ve cevabı aynı kapıcıya gönderir. Yönetimin kendisinin hangi blokta oturduğu hiç önemli değildir.

Lab’daki FortiGate relay’i bu alana muhasebe VLAN’ındaki adresini (10.34.70.1) yazdı ve sunucu muhasebe havuzundan 10.34.70.111’i önerdi. Relay isterse pakete ikinci bir not da ekleyebilir: seçenek 82’de isteğin hangi arayüzden geldiğini yazar (RFC 3046). Lab’daki FortiGate oraya muhasebe yazdı.

Bu yüzden relay doğru yapılandırılmış olsa bile, sunucuda o ağ için tanımlı bir havuz yoksa adres yine gelmez. İki ayrı hata aynı belirtiyi üretir. Ayırmanın yolu istemciye bakmayı bırakıp sunucu tarafındaki havuz listesini açmaktır.

Merkezîleşmenin Sınırı Nereye Kadar?

Relay’i öğrenen herkesin aklına aynı soru gelir: madem yayını sunucuya taşıyabiliyoruz, o zaman bütün şubelere tek bir sunucudan adres dağıtsak olmaz mı? Bu soruyu bana MPLS ile bağlı 15’e yakın şubesi olan bir kurumda sordular. Her şubede kendi Windows DHCP sunucusu vardı. Arkasından ikinci bir öneri daha geldi: merkezde sunucuya bile gerek yok, oradaki firewall’un böyle bir özelliği var, doğrudan o dağıtsın.

Önce topolojiyi netleştirmek gerekiyor, çünkü sorunun asıl kaynağı oradaydı. MPLS’in klasik kurgusunda şubeler birbirine tek tek tünellerle bağlanmaz; hepsi operatörün yönlendirdiği ortak bir buluta girer. Bir şubeden diğerine giden trafik merkeze hiç uğramaz, operatörün router’ı onu doğrudan hedef lokasyona yollar. Merkeze, yani İstanbul’daki kabinete yalnızca internete çıkacak trafik gelir. Kurumdaki tek firewall da orada duruyordu: şubelerde firewall yoktu, 15 lokasyonun bütün internet trafiği o tek cihazdan geçiyordu.

Bu ayrımı kurumdaki ekip tam kavramamıştı ve bu utanılacak bir şey değil: MPLS soyut bir hizmettir, faturada tek satır olarak görünür ve içinde ne olduğu çoğu zaman kimseye anlatılmaz.

Sorunun ilk yarısının cevabı “hayır” değil, ki asıl önemli olan da bu. Merkezî DHCP, relay ile teknik olarak çalışır ve kurumsal dünyada yaygın bir tasarımdır. Yayın şubenin dışına hiç çıkmaz: şubedeki relay yayını yakalar, tekil pakete çevirir ve sunucuya öyle gönderir. Yani “yayınlar hatta taşar” korkusu doğru kurulmuş bir relay’de gerçekleşmez. Bedel başka yerde duruyor.

Tasarımda olmayan bir darboğaz yaratılır. Bu topolojide şubeler merkeze yalnızca internet çıkışı için bağımlıydı; kendi içlerindeki işleri ve birbirleriyle konuşmaları merkezden geçmiyordu. Adres dağıtımını merkeze almak o bağımsızlığı ortadan kaldırır: merkeze erişilemediğinde şube artık kendi içinde bile yeni bir cihaza adres veremez hale gelir.

Bugün birbirinden bağımsız 15 küçük arıza alanı var; o mimaride tek ve büyük bir tane oluyor. Üstelik bu anında da görünmez, kiralar sürdüğü için sekiz günlük bir kirada arıza günler sonra ve şubeler arasında dağınık biçimde patlar.

Şubedeki yapılandırma kalkmaz, yer değiştirir. Relay her şube için ayrı ayrı tanımlanır ve sunucuda her şube için ayrı havuz açılır. Merkezîleşen şey sunucu sayısıdır, yapılandırma emeği değil.

Adresleme hattın kalitesine bağlanır. İstemcinin yeniden deneme süreleri kısadır; sıkışık bir hatta adres alma yavaşlar ya da başarısız olur. Bu kurumda hatlar zaten doluydu, yani en kırılgan bileşene yeni bir bağımlılık ekleniyordu.

Önerinin ikinci yarısı, yani dağıtımı doğrudan firewall’a vermek, bu kurumda ayrıca savunulamazdı. Bir sonraki bölümde göreceğiniz iki yapısal sebebin (AD DNS kaydı yazmaması ve güvenlik katmanıyla adresleme katmanının karışması) üstüne burada somut bir üçüncüsü vardı: kapasite.

O merkez firewall’u 6-7 yıllık bir FortiGate 100F’ti ve sınırına dayanmıştı. RAM ile CPU sürekli doluydu, paket kaybı yaşanıyordu, cihaz birkaç kez aşırı ısınıp kendiliğinden kapanmıştı; nitekim kısa süre sonra 200G’ye yükselttik. 15 lokasyonun internet trafiğini tek başına taşıyan ve zaten ısınan bir kutuya bir de bütün kurumun kira tablosunu ve relay yükünü bindirmek, çekirdek bir servisi sistemin hem en yüklü hem en kritik tek noktasına asmak olurdu.

Peki soru neden iyiydi? Çünkü bu makalenin kendi mantığını sonuna kadar götürüyordu: adresi tek merci dağıtsın, kayıt tek yerde dursun. İçgüdü doğru. Cevap ise o mantığın nerede durduğunu söylüyor: merkezîleşmenin sınırı şirket değil, arıza alanıdır. Defteri merkezîleştirirsiniz, ayakta kalma bağımlılığını değil.

Yayının lokasyon sınırında durması da bu yüzden bir kısıt değil, koruma. Bir an için durmadığını düşünün: Ankara’daki bir cihazın komşusunu arayan sorgusu İstanbul’daki şubenin hattından geçer, her lokasyonun gürültüsünü bütün kurum taşır ve tek bir arızalı cihaz herkesin hattını yer. Segment sınırı, arızayı doğduğu yerde tutar.

Kurum bu tabloyu görünce şube sunucularını kaldırmaktan vazgeçti ve tam tersi yönde karar aldı: o sunucuların yenilenmesi için satın alma yaptılar.

DHCP’yi Kim Dağıtır? Sunucu, Switch ve Firewall

Aynı DHCP protokolünü dört farklı yer konuşabilir: Windows Server, Linux üzerindeki Kea, ağın kenarındaki firewall ve Layer 3 switch. Dördü de aynı DORA akışını uygular ve istemci hangisiyle konuştuğunu bilmez bile. Dolayısıyla soru “hangisi daha iyi” değil, “bu kurumda hangisi doğru” olmalıdır.

İstemcinin sunucuyu sorgulamaması bir açık da bırakır. Masa altına takılan bir ev router’ı da aynı soruya cevap verebilir ve adresi ondan alan bilgisayar kurumun ağ geçidine ulaşamaz. Switch’in bu cevabı hangi porttan geldiğine bakarak nasıl düşürdüğünü DHCP snooping nedir yazımızda ölçtüm.

Kararı belirleyen üç şey var:

1. Domain. Active Directory kullanan bir kurumda Windows tarafı adresi dağıtmakla kalmaz, dağıttığı adresi DNS’e de yazar ve zincir kendiliğinden kapanır.
2. Ölçek. On kişilik bir şubeye yalnızca adres dağıtsın diye sunucu koymak savunulamaz, oradaki firewall bu işi zaten yapıyordur.
3. Ağın türü. Misafir ağı, DMZ ve captive portal senaryolarında firewall yalnızca kabul edilebilir değil, doğru tercihtir; o cihazların kurumun DNS zone’una kayıt düşmesini zaten istemezsiniz.

Lisans tarafındaki yaygın bir yanlış anlamayı da doğru yerinden kapatalım. DHCP rolünün ayrı bir lisansı yoktur ve bu konuda Standard ile Datacenter arasında da fark yoktur; iki sürüm de rolü aynı şekilde taşır, aradaki ayrım rollerde değil sanallaştırma hakkındadır. Yine de “Windows Server’ım var, DHCP bedavaya gelir” demek eksik olur: DHCP’yi Domain Controller üstüne kurmamanız gerektiği için doğru kurulum ayrı bir member server ister ve o da bir işletim sistemi örneği tüketir.

Standard iki örnek hakkı verir, Datacenter sınırsız. İkinci hakkınız boştaysa ek maliyet gerçekten sıfırdır; iki hak da doluysa üçüncü örnek yeni lisans demektir. Sürüm hakları ve çekirdek bazlı hesabın tamamı Windows Server rehberimizde.

Dört seçeneğin senaryo bazlı karşılaştırma tablosu ile Windows tarafındaki rol kurulumu, scope yapılandırması, rezervasyon ve failover adımları Windows Server DHCP kurulumu rehberimizde ele alınmaktadır. Firewall seçeneğini, yani FortiGate’in adres aralığını, rezervasyonunu ve isteği başka bir sunucuya ileten relay’ini FortiGate Firewall DHCP sunucusu yazımızda ölçtüm.

Sonuç: Adres Dağıtımı Ağın Sessiz Omurgasıdır

Bu makalede dört mesajlık DORA akışını, adresin neden kalıcı değil kiralık olduğunu, dağıtılan dört bilginin her birinin ne işe yaradığını ve 169.254.x.x gördüğünüzde nereye hangi sırayla bakacağınızı gezdik. Akılda tutulacak tek cümle şu olabilir: DHCP arızaları neredeyse hiçbir zaman kendi adlarını söylemez. Belirti “internet yok” olur, “yazıcıya basamıyorum” olur, “sunucuya giremiyorum” olur. Adres katmanına bakmayı bilen kişi, başkalarının saatlerce aradığı arızayı tek komutla görür.

Apartman yönetimi de böyledir. İyi çalıştığı sürece kimse yöneticinin adını bilmez; numaralar yerinde, kargo doğru kapıda ve defter güncel olduğu sürece yönetim görünmezdir. Görünür hale geldiği gün, zaten bir şeyler çoktan ters gitmiştir.

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ürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn