Windows Server DHCP Kurulumu: Scope, Rezervasyon ve Failover

Windows Server DHCP kurulumu, ağdaki cihazlara IP adresini, gateway’i ve DNS bilgisini merkezi olarak dağıtan rolü devreye almak demektir. On cihazlı bir ofiste bu bilgileri elle girmek mümkündür; yüz cihazda saatler alır ve elle girilen her IP potansiyel bir çakışma kaynağıdır. Bu rehber rol kurulumundan başlayarak scope yapılandırması, IP rezervasyonu ve DHCP failover ile canlıya alma adımlarını ekran görüntüleriyle anlatıyor.

Adımlar Active Directory olmadan da uygulanabilir; DHCP rolü Windows Server çalışan her ortamda görev yapar. Ancak AD kurulu bir ortamda iki nokta değişir: DHCP sunucusunun IP dağıtmaya başlayabilmesi için önce AD’de yetkilendirilmesi gerekir ve dağıttığı adresler DNS’e otomatik kaydedilebilir. Rehberdeki yetkilendirme bölümü bu yüzden AD’ye özeldir; geri kalan her adım AD’siz ortamda da aynı şekilde uygulanır.

Rehber, Windows Server kurulumu tamamlanmış bir sunucuyu varsayar. AD entegrasyonunu kullanacaksanız sunucunun domain’e üye olması gerekir; bu adım henüz yapılmadıysa sunucuyu domain’e ekleme rehberine, ortamda henüz domain yoksa önce Active Directory kurulum rehberine göz atın.

DHCP’nin nasıl çalıştığını zaten biliyorsanız doğrudan rol kurulumuna geçebilirsiniz.

Hangi DHCP Çözümünü Kullanmalısınız?

DHCP sunucusu kurmak için tek seçenek Windows Server değildir. Linux sunucu, Layer 3 switch veya ağın kenarındaki firewall da IP dağıtabilir. Hangi senaryoda hangisinin tercih edilmesi gerektiğini bilmek, hem maliyet hem operasyon açısından doğru kararı vermenizi sağlar.

Windows Server DHCP Active Directory ortamlarında öne çıkar. IP atandığında DNS’e otomatik A ve PTR kaydı ekler (Dynamic DNS); AD ile bu entegrasyon native olarak gelir. Failover GUI üzerinden birkaç tıkla yapılandırılır. MAC prefix veya vendor class’a göre farklı scope atanabilen DHCP policies, büyük ve karmaşık ağlarda güçlü bir yönetim aracıdır. Dezavantajı Windows Server lisans maliyeti ve görece yüksek kaynak tüketimidir.

Linux DHCP (Kea) ücretsiz ve son derece hafiftir; eski donanımda bile çalışır. Windows lisansı olmayan ortamlarda veya Linux uzmanlığı olan ekiplerde güçlü bir alternatiftir. Burada bir uyarı gerekiyor: uzun yıllar fiilî standart olan ISC DHCP 2022 sonunda kullanım ömrünü tamamladı ve bakımı durduruldu. Çalışan kurulumlar çalışmaya devam eder, ama yeni bir kurulumda halefi olan Kea tercih edilmelidir; Kea failover, REST API ve hook mimarisiyle zaten daha yetenekli.

“Linux tarafında GUI yok” bilgisi de artık eskidi. ISC’nin geliştirdiği Stork, Kea için web tabanlı bir yönetim paneli sunar: havuz doluluk oranları, failover durumu ve sunucu sağlığı buradan izlenir; host rezervasyonları ile subnet’ler, ilgili Kea hook’ları kuruluysa doğrudan arayüzden eklenip düzenlenebilir. Yine de kapsamı Windows DHCP Manager kadar geniş değildir ve yapılandırmanın bir kısmı dosya tarafında kalır. Windows karşısındaki asıl fark GUI değil entegrasyondur: AD dynamic DNS kaydı Linux tarafında ekstra yapılandırma ister.

Switch DHCP ayrı bir sunucu gerektirmez; zaten mevcut olan Layer 3 switch veya router üzerinde çalışır. On cihazın altındaki küçük ofisler, şubeler veya geçici kurulumlar için pratiktir. Ancak loglama kısıtlıdır, dynamic DNS yoktur, failover yoktur ve switch CPU’su bu iş için tasarlanmamıştır; yük altında switching performansını olumsuz etkileyebilir.

Firewall DHCP sahada en sık karşılaştığımız yapılandırmadır ve çoğu zaman bilinçli bir tercih değildir: cihaz kurulurken DHCP servisi açık gelir, ağ da onun etrafında büyür. Kurumsal firewall’lar (FortiGate ve benzeri UTM sınıfı cihazlar) arayüz bazında havuz tanımlar, MAC rezervasyonu destekler, kira listesini gösterir ve gateway ile DNS forwarder’ı zaten aynı cihazda tuttuğu için tek panelden yönetim sunar. Misafir ağı, DMZ ve captive portal senaryolarında bu yalnızca kabul edilebilir değil, doğru mimaridir; o istemcilerin AD DNS bölgesine kayıt düşmesini zaten istemezsiniz. Cihazın kendisi için de ayrıntılı yapılandırma rehberimiz var: kurumsal firewall kurulumu ve yönetimi.

Domain ortamında ise iki gerçek bedeli vardır. Birincisi, Linux için söylediğimiz entegrasyon farkının daha sert halidir: firewall istemci adına AD DNS’e A ve PTR kaydı yazmaz ve bunu yaptıracak bir ayar da yoktur. Sonuç, cihazların isimle bulunamadığı, bayat kayıtlarla dolan bir DNS bölgesidir. İkincisi katman karıştırmadır: ağın kenarındaki güvenlik cihazı, çekirdek adresleme servisine dönüşür. Firmware güncellemesi, politika değişikliği ve HA testi güvenlik takviminin işidir; DHCP oraya bağlıyken her güvenlik bakım penceresi aynı zamanda bir adresleme riski taşır. Cihaz HA çiftindeyse kira tablosu eşlendiği için devir sorunsuz çalışır, tek cihazlı kurulumlarda ise DHCP’nin yedeği yoktur.

Bu makalede Windows Server DHCP ele alınmaktadır.

DHCP Server Nedir, Nasıl Çalışır?

Otel Resepsiyonu Analojisi

Büyük bir şehir otelini düşünün: Çırağan, Swissôtel, ya da İstanbul’un gözde bir köşesindeki herhangi bir beş yıldızlı tesis. Her gün onlarca misafir check-in yapıyor, yüzlerce oda hareketleniyor. Resepsiyonist her misafire bir oda anahtarı veriyor; o anahtar o misafirin konaklaması boyunca geçerli. Check-out gününde misafir anahtarı iade eder, oda temizlenerek yeniden hazır hale gelir ve bir sonraki misafire verilebilir hâle gelir. Resepsiyonist her odaya kimin girebileceğini ve ne kadar süre kalabileceğini kontrol eder; misafir bu kararın içinde değildir.

DHCP (Dynamic Host Configuration Protocol) tam olarak bu mantıkla çalışır. Bir cihaz ağa bağlandığında DHCP sunucusuna “bana bir IP adresi ver” mesajı gönderir. Sunucu havuzdan uygun bir IP atar, kira süresini (lease time) belirler ve cihaza gateway ile DNS bilgisini de iletir; tıpkı resepsiyonistin odanın numarasını, wi-fi şifresini ve sabah kahvaltısının hangi katta olduğunu tek seferde söylemesi gibi. Kira süresi dolmadan cihaz yenileme isteği gönderir; göndermezse IP havuza geri döner. Cihaz ağdan ayrıldığında IP bir başkasına verilebilir hâle gelir.

Bu otel, rehberin geri kalanını da taşıyacak. Odaların hangi kattan hangi katta dağıtılacağını belirleyen kat planı scope’a, misafire hiç açılmayan servis odaları exclusion range’e, sürekli gelen misafire ayrılmış sabit oda rezervasyona, resepsiyonun kapanmasına karşı hazır tutulan ikinci masa failover’a karşılık geliyor. Aşağıdaki bölümlerde bunları sırayla açacağız; her seferinde aynı otele geri döneceğiz.

DORA: Dört Adımlı El Sıkışma

DHCP arka planda dört mesajla çalışır ve bu akış kısaca DORA olarak anılır: istemci Discover ile ağa seslenir, sunucu Offer ile bir adres teklif eder, istemci Request ile seçtiği teklifi duyurur, sunucu Acknowledge ile kirayı başlatır. Tamamı saniyenin altında biter ve misafirin lobiye girip anahtarını alması kadar sürer.

Bu rehber açısından önemli olan, akışın hangi kurulum kararına dokunduğudur. Discover ve Request birer yayın olduğu için ağdaki her DHCP kaynağı isteği duyar ve teklif verebilir; aşağıdaki yetkilendirme bölümünün varlık sebebi budur. Acknowledge yalnız adresi değil scope seçeneklerini de taşır, yani 003 gateway ve 006 DNS ayarlarını doğru girmenizin karşılığı istemcide burada görünür. T1 ve T2 yenileme eşikleri de Address Leases listesindeki tarihleri açıklar.

Dört mesajın ayrıntısı, kira döngüsü, 169.254.x.x adresinin anlamı ve farklı VLAN’lardan adres alma DHCP nedir rehberimizde ele alınmaktadır.

Windows Server DHCP Rolü Kurulumu

Rol Ekleme

Server Manager’ı açın ve sağ üstteki Manage menüsünden “Add Roles and Features” seçeneğini tıklayın. Sihirbaz başlar; “Before You Begin” ekranını geçin ve “Role-based or feature-based installation” seçili bırakarak ilerleyin. Sunucu seçim ekranında mevcut sunucunuzu seçin. “Server Roles” adımına geldiğinizde listeden DHCP Server üzerine tıklayın; bağımlı bileşenleri eklemek için bir onay kutusu çıkar, “Add Features” ile devam edin. “Features” adımında ek bir şey seçmenize gerek yoktur. “DHCP Server” açıklama ekranını okuyup ilerleyin ve “Install” düğmesine tıklayın.

Kurulum birkaç dakika sürer. Tamamlandığında Server Manager’ın sağ üstündeki bayrak simgesinin yanında sarı uyarı simgesi belirir: “Configuration required for DHCP Server at [sunucu adı].” Bu uyarıyı görmezden gelmek büyük bir hatadır; post-install konfigürasyon tamamlanmadan DHCP servisi çalışır görünse de AD yetkilendirmesi ve yönetim grupları eksik kalır. Uyarıya tıklayın ve “Complete DHCP configuration” bağlantısını seçin.

Post-install sihirbazı iki şey yapar: DHCP yöneticileri için “DHCP Administrators” ve salt okunur izin için “DHCP Users” güvenlik gruplarını oluşturur; ardından bu grupları AD’ye veya yerel makinaya kaydeder. Küçük ortamlarda “Use the following user’s credentials” seçeneğini mevcut yönetici hesabıyla onaylayıp geçebilirsiniz. Sihirbaz tamamlandığında yönetim konsolunu açma sırası gelir. İki yol vardır: Server Manager’ın sağ üstündeki Tools menüsünde, rol kurulduktan sonra DHCP girişi belirir; ya da Win + R ile Çalıştır kutusunu açıp dhcpmgmt.msc yazarsınız. İkisi de aynı konsolu açar. Solda sunucunuz IPv4 ve IPv6 düğümleriyle listelenmiş olacak.

Yeni kurulmuş bir sunucuda konsolu menüler arasında aramak vakit kaybıdır; Windows Server’ın Başlat menüsü rol konsollarını öne çıkarmaz ve hepsi Administrative Tools klasörünün içinde birbirine benzeyen isimlerle durur. Pratikte kısayolu bilmek en hızlı yoldur.

Bu kural DHCP’ye özel değildir. Domain Controller, otelin oda anahtarlarını değil ana anahtar dolabını barındıran odadır: oradan üretilen bir yetki otelin her kapısını açar. Bu yüzden DC üzerine kurulan her ek rol, kimlik altyapısının en ayrıcalıklı katmanına dokunan kişi, yama ve yeniden başlatma sayısını artırır; o katmanda yapılan tek bir hatanın etkisi tek bir servisle sınırlı kalmaz. Bu ayrımın nasıl kurulacağını ve Domain Admin yetkili hesapların neden sıradan sunucularda oturum açmaması gerektiğini Active Directory güvenlik sıkılaştırması rehberinde Tier modeli üzerinden ele alıyoruz.

DHCP Scope Yapılandırması

Yeni Scope Oluşturma

Otele dönelim. Resepsiyonist odaları dağıtmaya başlamadan önce elinde bir kat planı olmak zorundadır: hangi oda numaraları misafire açık, hangileri kapalı, her katta kaç oda var, odalarla birlikte hangi hizmetler veriliyor. Bu plan olmadan resepsiyonist tek bir anahtar bile veremez; otelin odaları fiziksel olarak dursa da hangi odayı verebileceğini bilmiyordur.

DHCP scope, tam olarak bu kat planının ağ dünyasındaki karşılığıdır. Scope oluşturduğunuzda DHCP sunucusuna şunu söylüyorsunuz: “192.168.1.100 ile 192.168.1.200 arasındaki adreslerden oluşan bir IP havuzu yönet; bu havuzdan istemcilere lease ver ve her lease ile birlikte şu gateway ve DNS bilgilerini de ilet.” Scope tanımlanmadan DHCP sunucusu tek bir IP dahi dağıtamaz; sunucu aktif olsa bile istemciler IP alamaz.

DHCP Manager’da sol panelde IPv4 üzerine sağ tıklayın ve “New Scope” seçeneğini seçin. Sihirbaz açılır. İlk adımda scope için bir isim ve opsiyonel açıklama girin; tanımlayıcı bir isim ilerleyen dönemde yönetimi kolaylaştırır: OFIS_AGI, ZEMIN_KAT_AGI veya lokasyon kısaltmasıyla HALKALI_KAT2 gibi.

İsimlendirmede iki alışkanlık işinizi kolaylaştırır. Birincisi Türkçe karakter kullanmamak: scope adı için teknik bir zorunluluk olmasa da aynı isim er ya da geç bir PowerShell betiğine, bir dışa aktarma dosyasına veya bir raporlama aracına girer ve kodlama farkları orada sorun çıkarır. İkincisi boşluk yerine alt çizgi kullanmak; betikte tırnak içine almayı unuttuğunuzda boşluklu isim komutu bölerek anlaşılması zor hatalar üretir. Aynı disiplin GPO ve OU adlarında da geçerlidir, dolayısıyla ortamın tamamı tek bir kalıba oturur.

İkinci adımda IP aralığını tanımlarsınız: başlangıç IP, bitiş IP ve subnet mask. Bu değerleri girmeden önce ağ tasarımınızı netleştirin; subnet mask hatalı girilirse scope oluştuktan sonra değiştirmek için scope’u silip yeniden oluşturmanız gerekebilir.

Lease duration (kira süresi) adımında varsayılan 8 günü çoğu ofis ortamı için olduğu gibi bırakabilirsiniz. Sabit masaüstü bilgisayarların hâkim olduğu ortamlarda uzun kira süreleri uygundur; DHCP sunucusuna gereksiz yenileme trafiği bindirmez. Misafir ağı veya sık cihaz değişimi olan ortamlarda bu süreyi 2-4 saate indirmek boşa çıkan IP’lerin hızla havuza dönmesini sağlar.

Exclusion Range: Bazı IP’leri Dışlamak

Kat planındaki her oda misafire açık değildir. Çamaşırhane, kat şefi odası, teknik oda ve personel dinlenme odası aynı koridorda, aynı numaralandırma içindedir; plana dahildir ama misafire verilmez. Resepsiyonist bu odaları “dolu” diye işaretlemez, “dağıtılamaz” diye işaretler. İşaretlemeyi unutursa bir akşam teknik odanın anahtarını misafire verir ve o odada zaten çalışan biri vardır.

Exclusion range, scope içindeki ama DHCP’nin asla dağıtmaması gereken IP adreslerini tanımlar. Bu rehberde havuzu 192.168.1.100 ile 192.168.1.200 arasında tanımladık. Diyelim ki bu bandın son on adresini (192.168.1.190 - 192.168.1.200) ileride kuracağınız yazıcılar ve IP kameralar için elle vermek üzere ayırmak istiyorsunuz. O adreslere statik IP atadıktan sonra DHCP’nin aynı adresleri başka istemcilere teklif etmemesi için exclusion range olarak işaretlemeniz gerekir. Exclusion olmadan, havuz içinde statik IP verilmiş bir cihaz aynı adresi başkasına dağıtan DHCP ile çakışır.

Buradaki ölçüt, adresin havuzun içine düşüp düşmediğidir. Switch yönetim arayüzleriniz, sunucularınız ve access point’leriniz 192.168.1.1 ile 192.168.1.99 arasında duruyorsa onlar zaten havuzun dışındadır; DHCP o adresleri hiçbir zaman dağıtmaz, dolayısıyla exclusion da gerekmez. Havuzu tüm alt ağı kapsayacak şekilde geniş tanımlayanlar (192.168.1.1-254 gibi) ise altyapı bandını mutlaka dışlamak zorundadır. Yani exclusion, geniş havuz tercihinin bedelidir; havuzu dar tutmak aynı işi tasarımla halleder.

New Scope sihirbazında “Add Exclusions and Delay” adımında exclusion range’i girebilir ya da sihirbaz tamamlandıktan sonra DHCP Manager’da scope altındaki “Address Pool” düğümüne sağ tıklayıp “New Exclusion Range” ile ekleyebilirsiniz. Tek bir IP’yi dışlamak istiyorsanız başlangıç ve bitiş adresine aynı değeri girin.

Scope Seçenekleri: Gateway ve DNS

İyi bir resepsiyonist misafire yalnızca anahtarı uzatmaz. Aynı anda kat numarasını, asansörün nerede olduğunu, kahvaltının hangi saatte hangi salonda verildiğini ve wi-fi şifresini de söyler. Anahtar tek başına odayı açar ama oteli kullanılabilir kılmaz: misafir odaya girer, sonra kahvaltıyı bulamaz, çıkışı bulamaz, internete bağlanamaz. Anahtarla birlikte verilmesi gereken bir bilgi paketi vardır.

Scope seçenekleri (scope options) DHCP’nin bu rolünü üstlenir. Bir istemciye yalnızca IP adresi vermek yeterli değildir; istemcinin default gateway’i ve DNS sunucusunu da bilmesi gerekir. Gateway olmadan yalnızca yerel ağda iletişim kurabilir, internet trafiği bir yere gidemez. DNS olmadan alan adı çözümleyemez; dolayısıyla internet teknik olarak çalışır ama pratikte “erişilemiyor” görünür. Bu iki bilgi, her IP atamasıyla birlikte otomatik olarak iletilmesi gereken zorunlu yapılandırmalardır.

DHCP Manager’da scope altında Scope Options düğümüne sağ tıklayın ve “Configure Options” seçeneğini seçin. Açılan pencerede ilgili seçeneği işaretleyip değerini girin:

• 003 Router: Default gateway IP adresi; bu genellikle ağınızdaki router veya Layer 3 switch’in adresidir.
• 006 DNS Servers: DNS sunucusu IP’leri; Active Directory ortamında bu alan Domain Controller’ın IP’si olmalıdır.
• 015 DNS Domain Name: DNS suffix; bu değer sayesinde istemciler kısa host adıyla sorgu yapabilir.

Bu üçünden 006 ve 015’i listede hiç elle girmediğiniz halde dolu bulabilirsiniz. Sebebi şudur: New Scope sihirbazının DNS adımı, alanları sunucunun kendi ağ yapılandırmasından doldurur. DHCP sunucusu hangi domain’e üyeyse ve NIC’inde hangi DNS adresi tanımlıysa, sihirbaz onları varsayılan olarak öne koyar ve siz “İleri” dedikçe scope’a yazılır.

Kolaylık gibi görünen bu davranışın bir bedeli var: sunucunun kendi DNS ayarı yanlışsa, o yanlış ağdaki her istemciye dağıtılır. DHCP01’in NIC’inde 8.8.8.8 yazıyor olsaydı, sihirbaz hiçbir uyarı vermeden 006’ya 8.8.8.8 yazacak ve aşağıdaki uyarıda anlatılan tabloyu tek tıkla ağın tamamına yayacaktı. Sihirbazı hızlıca geçtiyseniz bile scope seçeneklerini sonradan açıp bu iki satırı gözle doğrulayın.

Server Options: Aynı Ayarı Her Scope’ta Tekrarlamamak

Otelde bazı bilgiler her misafire aynıdır: wi-fi şifresi, kahvaltının saati, santralin dahili numarası. Resepsiyonist bunları kat kat farklılaştırmaz, otelin tamamı için bir kez belirler. Bazı bilgiler ise kata özgüdür: o katın yangın çıkışı nerede, o kattan aşağı hangi merdivenle inilir. Bunları otel geneli için tek bir cevapla veremezsiniz, çünkü kattan kata değişir.

DHCP seçenekleri de tam olarak bu iki gruba ayrılır ve Windows DHCP bunu dört katmanlı bir hiyerarşiyle yönetir. En genelden en özele: Server Options, Scope Options, sınıf seçenekleri ve rezervasyon seçenekleri. Kural basittir: en özel olan kazanır. Bir seçenek hem sunucu hem scope seviyesinde tanımlıysa istemciye scope’taki değer gider; rezervasyon seviyesinde de tanımlıysa o hepsinin önüne geçer.

Bu hiyerarşinin pratik karşılığı şudur:

• 006 DNS Servers ve 015 DNS Domain Name kurum genelinde aynıdır. Tüm scope’lar aynı Domain Controller’ları ve aynı domain adını kullanır. Bunları Server Options altında bir kez tanımlayın.
• 003 Router her scope için farklıdır, çünkü her alt ağın kendi gateway’i vardır. Bu seçenek Scope Options altında, scope’a özel kalmalıdır.

Server Options tanımlamak için DHCP Manager’da IPv4 düğümünün altındaki Server Options üzerine sağ tıklayın ve “Configure Options” seçeneğini seçin; arayüz scope seçenekleriyle birebir aynıdır, tek fark kapsamıdır.

Kazanç, scope sayısı arttıkça büyür. Beş lokasyonlu bir yapıda DNS sunucusu değiştiğinde beş ayrı scope’u tek tek düzenlemek yerine tek bir yeri güncellersiniz. Daha önemlisi tutarlılık: elle tekrarlanan her ayar, er ya da geç bir scope’ta unutulur ve yalnızca o alt ağdaki kullanıcıların yaşadığı, teşhisi zor bir soruna dönüşür.

Scope Aktivasyonu

Scope tanımlandıktan sonra etkinleştirilmesi gerekir; etkin olmayan scope IP dağıtmaz. New Scope sihirbazının son adımında “Yes, I want to activate this scope now” seçeneği çıkar; bunu seçerek ilerlerseniz scope hemen aktif hale gelir. Daha sonra DHCP Manager’da scope üzerine sağ tıklayarak Activate/Deactivate ile bu durumu değiştirebilirsiniz. Aktif scope yeşil onay simgesiyle, aktif olmayan scope ise sarı uyarı simgesiyle gösterilir.

Scope aktif olduktan sonra “Address Leases” düğümüne tıklayarak hangi cihazların IP aldığını anlık olarak izleyebilirsiniz; bu liste sorun gidermede çok işinize yarayacak.

Lease Listesi Teşhis Aracıdır, Müdahale Düğmesi Değil

Danışmanlık verdiğim bir kurumda lokasyonlar MPLS ile bağlıydı ve her birinde 100 Mbps hattın arkasında iki yüze yakın uç nokta vardı. Uç nokta başına yarım megabitin altına düşen bu kapasitede yavaşlık şikayeti düzenli olarak geliyordu. Yerinde çalışan BT ekibinin bu şikayete verdiği standart karşılık, ilgili lokasyonun DHCP sunucusuna bağlanıp o scope’taki bütün lease kayıtlarını silmekti.

Ekibin bunu sürdürmesinin anlaşılır bir sebebi vardı: silme işleminden bir süre sonra yavaşlık gerçekten geçiyordu. Geçmesinin sebebi işlem değil, geçici tıkanıklığın kendiliğinden çözülmesiydi; ama iki olay arka arkaya geldiği için aradaki ilişki sebep sonuç olarak okundu ve zamanla bir rutine dönüştü.

Bu işlemin neden hiçbir şeyi çözmediğini görmek için lease’in ne olduğuna dönmek gerekir. Lease, sunucuda tutulan bir kayıttır: hangi MAC adresinin hangi IP’yi ne zamana kadar kullandığını gösterir. Trafik bu kaydın içinden geçmez. Kaydı silmek bant genişliğini serbest bırakmaz, oturumları koparmaz, hattı sıfırlamaz. Resepsiyondaki kayıt defterinden satırları silmek, odalardaki misafirleri dışarı çıkarmaz.

Nitekim istemciler adreslerini de kaybetmez. Her istemci kendi kira sayacına göre çalışır ve sunucunun kendisini unuttuğundan haberi yoktur; adresini kullanmaya devam eder. İşlemin gözle görülür bir etkisinin olmamasının sebebi budur.

Görünmeyen bir etkisi ise vardır ve ters yöndedir. Silme sonrasında sunucunun defteri boştur ama adresler hâlâ sahada kullanılmaktadır. Sunucu o adresleri boşta sayar ve yeni bağlanan bir cihaza kullanımdaki bir adresi teklif edebilir.

Bu noktada akla gelen önlem, Windows DHCP’nin çakışma denetimi (conflict detection) özelliğidir: sunucu bir adresi teklif etmeden önce ping atar, cevap gelirse adresi kullanımda sayar. İki sorun var. Birincisi, bu özellik varsayılan olarak kapalıdır; deneme sayısı sıfırdır, yani sunucu hiçbir sınama yapmaz. İkincisi ve daha önemlisi, açsanız bile güvenilmez: Windows Defender Firewall gelen ICMP echo isteklerini varsayılan olarak engeller, ilgili kural (File and Printer Sharing (Echo Request - ICMPv4-In)) kutudan kapalı gelir. Adresi fiilen kullanan bir Windows istemcisi ping’e cevap vermez, sunucu sessizliği “boşta” diye okur ve adresi yine dağıtır. Kurumsal bir ağda uç noktaların ezici çoğunluğu tam olarak bu profildedir; yani önlem, en çok ihtiyaç duyulan yerde en zayıf çalışır.

Çakışma tamamen sessiz kalmaz: adresi alan yeni istemci, kullanmaya başlamadan önce ağ katmanında bir yinelenen adres sınaması yapar ve çakışma görürse teklifi reddeder. Sunucu da o adresi scope’ta BAD_ADDRESS olarak işaretler. Sonuç ortalıkta iki cihazın sessizce aynı IP’yi paylaşması değil, ağa yeni katılan cihazların düzgün adres alamaması ve scope’ta zamanla biriken BAD_ADDRESS kayıtlarıdır. Bu kayıtların göründüğü yer de Address Leases listesidir: ekibin düzenli olarak temizlediği ekran, kendi verdiği hasarın delillerinin biriktiği ekrandır.

Dinamik DNS kaydı devredeyse ikinci bir katman daha eklenir: silinen lease’lerle birlikte ilgili A ve PTR kayıtları temizlenebilir, ad çözümlemesi bozulur. Bu da “yavaşlık” diye raporlanan şikayeti çözmek yerine üretir.

Yavaşlığın gerçek kaynağı zaten ölçülebilir durumdaydı: uç nokta başına düşen bant genişliği. Bunun karşılığı olan işler kapasite planlaması, trafik önceliklendirme ve en çok tüketen kaynakların tespitidir. Bir lokasyondaki yavaşlığın hattan mı yoksa yerel bir cihazdan mı kaynaklandığını ayırt edebilmek içinse bağımsız bir izleme altyapısı gerekir; bunu nasıl kurduğumuzu çok lokasyonlu izleme vaka çalışmamızda anlatıyoruz.

Address Leases listesi bu yüzden değerlidir, ama değeri teşhistedir: kimin hangi adresi aldığını, kiranın ne zaman dolacağını ve havuzun ne kadar dolduğunu gösterir. Okunacak bir ekrandır, basılacak bir düğme değil.

DHCP Sunucusu Yetkilendirme

Şimdi otelin lobisine biri katlanır bir masa kurup üzerine “resepsiyon” yazdığını düşünün. Misafirler farkı anlamaz; masaya yaklaşır, anahtar ister ve alır. Sorun şu ki bu masadan dağıtılan oda numaraları gerçek kat planıyla uyuşmuyordur: iki misafir aynı odaya yollanır, kimisi var olmayan bir kata çıkar, kimisi çamaşırhanenin kapısında kalır. Otel bir anda çalışmaz hale gelir ve kimse sebebini anlamaz, çünkü herkes “resepsiyondan aldım” demektedir.

Active Directory’nin DHCP yetkilendirmesi (authorization) bu masayı engellemek için vardır. Domain’e üye olan bir Windows DHCP sunucusu, IP dağıtmadan önce AD’ye sorar: “Ben bu domainide yetkilendirilmiş miyim?” Cevap “hayır” ise DHCP Server servisi başlar görünse de IP dağıtmaz; Event Viewer’da ilgili uyarı kaydedilir. Bu mekanizma, bir çalışanın masa altına ev router’ı takıp istemeden bir DHCP sunucusu devreye alması gibi senaryoları engeller. O senaryonun kendisinin de bir adı var: ağa bağlanmış yetkisiz cihaz anlamında rogue; daha geniş olarak da kurumun bilgisi dışında kullanılan her aracı kapsayan gölge BT ailesinin bir üyesi.

Yetkilendirme yapmak için DHCP Manager’da sol panelden sunucunuzun adına sağ tıklayın ve Authorize seçeneğini seçin. İşlem AD’ye birkaç saniyelik bir kayıt yapar ve tamamlanır.

Sonucu nerede göreceğinizi bilmek önemli: durum simgesi sunucu adının değil, altındaki IPv4 ve IPv6 düğümlerinin üzerinde belirir. Yetkilendirme öncesinde bu düğümler kırmızı aşağı ok rozeti taşır; işlem tamamlanıp konsol yenilendiğinde rozet yeşil onay işaretine döner. Sunucu adının yanında hiçbir zaman rozet çıkmaz, dolayısıyla oraya bakıp “bir şey değişmedi” diye düşünmeyin. Yeşil onayı gördüğünüzde IP dağıtımı aktiftir.

Doğrulama: İlk Cihaz IP Alıyor mu?

Resepsiyon kuruldu, kat planı hazır, anahtarlar dolapta. Ama otelin gerçekten çalıştığını ancak ilk misafir check-in yapıp odasına çıktığında bilirsiniz. Bu adım atlanırsa kurulumdaki sessiz bir hata haftalar sonra “internet yok” şikayeti olarak geri döner.

Ağa bağlı bir istemcide komut istemini yönetici olarak açın, mevcut kirayı bırakıp yenisini isteyin:

ipconfig /release
ipconfig /renew
ipconfig /all

Son komutun çıktısındaki dört satır kurulumun tamamını doğrular:

• IPv4 Address: Tanımladığınız scope aralığının içinde mi? 169.254.x.x ile başlayan bir adres görüyorsanız istemci hiçbir DHCP sunucusuna ulaşamamış ve kendine adres uydurmuş demektir (APIPA).
• DHCP Server: Kurduğunuz sunucunun IP’si mi? Başka bir adres görünüyorsa ağda sizin bilmediğiniz bir DHCP kaynağı var.
• Default Gateway ve DNS Servers: 003 ve 006 seçeneklerine girdiğiniz değerlerle birebir aynı mı?
• Lease Obtained / Lease Expires: İkisi arasındaki fark, scope’ta tanımladığınız kira süresini vermeli.

Aynı anı sunucu tarafından da görebilirsiniz. DHCP Manager’da scope altındaki Address Leases düğümüne tıklayın; istemcinin adı, aldığı IP adresi ve kiranın bitiş zamanı listede belirmiş olmalı. Bu liste bundan sonra sorun gidermede ilk bakacağınız yerdir: bir cihazın ağda olup olmadığını, hangi adresi aldığını ve kirasının ne zaman dolacağını tek ekranda gösterir.

İstemci hâlâ IP alamıyorsa sorun büyük ihtimalle son iki adımdadır: scope aktif edilmemiş veya sunucu AD’de yetkilendirilmemiş olabilir. Belirtiden kaynağa giden tam liste için Sık Yapılan Hatalar bölümüne bakın.

DHCP IP Rezervasyonu

Hangi Cihazlar Rezervasyon Gerektirir?

Otelin her ay aynı hafta gelen bir müşterisi vardır: aynı odayı ister, oda numarasını kartvizitine yazdırmıştır, iş ortakları onu o odadan arar. Resepsiyonist bu misafiri havuzdan oda vererek karşılamaz; kayıtta o kişinin adı belirli bir oda numarasına bağlıdır. Misafir lobiye girdiği anda oda zaten onundur, kimse ona başka bir numara teklif etmez.

DHCP rezervasyonu aynı şekilde çalışır. Bir cihazın MAC adresi belirli bir IP’ye bağlanır; o cihaz ağa her bağlandığında DHCP sunucusu her seferinde aynı IP’yi atar. Dinamik DHCP’den farkı sabitleme; statik IP’den farkı ise merkezi yönetimdir. Cihazın IP’sini değiştirmek istediğinizde cihaza dokunmanıza, Windows ağ ayarlarına girmenize, cihazın başında oturmanıza gerek yoktur: DHCP Manager’dan rezervasyonu güncellersiniz, cihaz bir sonraki yenilemede yeni adresini alır.

Hangi cihazlar rezervasyon gerektirir? Basit bir kural: sabit IP’ye ihtiyaç duyan ama cihaza elle müdahale etmek istemediğiniz her şey. Ağ yazıcıları ve çok fonksiyonlu cihazlar farklı bir IP aldığında bilgisayarlardaki yazıcı tanımlaması bozulur; bunu düzeltmek her kullanıcıda tekrar yapılmak zorundadır. NAS cihazları ve dosya sunucuları farklı IP aldığında eşlenen ağ sürücüleri kesilir. IP kameralar VMS yazılımında statik adresle tanımlanır; adres değiştiğinde kamera görüntüsü kesilir. VoIP telefonlar PBX’te sabit IP ile kaydedilir. Access point’ler ve yönetilen switch’ler yönetim arayüzünden farklı IP aldığında erişilmez hale gelir.

Kullanıcı bilgisayarlarına rezervasyon gerekmez; onlar havuzdan dinamik IP alabilir. Windows sunucularını ise DHCP rezervasyonuyla değil, doğrudan statik IP ile yönetmek daha temizdir: sunucu yeniden başladığında veya NIC değiştiğinde konfigürasyon kayması riski olmaz.

MAC Adresiyle Rezervasyon Ekleme

DHCP Manager’da ilgili scope’u genişletin ve Reservations düğümüne sağ tıklayın, “New Reservation” seçeneğini seçin. Açılan formda doldurmanız gereken alanlar:

• Reservation name: Cihazı açıklayan bir isim. Scope adlarındaki kalıbı burada da sürdürün: MUHASEBE_YAZICISI, GIRIS_KAMERASI_1, AP_ZEMIN_KAT gibi ASCII ve alt çizgili.
• IP address: Atanacak IP adresi; scope aralığı içinde ve exclusion range dışında olmalı.
• MAC address: Cihazın fiziksel adresi, 12 haneli onaltılık değer (örnek: 00155D1A2B3C). Tireli veya iki noktalı format da kabul edilir; DHCP Manager ayraçları kendisi temizler.
• Description: Konum, sorumlu kişi veya cihaz seri numarası gibi ek bilgi.

“Supported types” kısmında “Both” seçili bırakın; bu hem DHCP hem BOOTP protokolünü kapsar. Add düğmesine tıklayın; rezervasyon hemen listeye eklenir. Cihaz bir sonraki IP yenilemesinde veya ağa yeniden bağlandığında rezervasyonuyla eşleşen IP’yi alacak.

DHCP Failover

Neden Failover Gereklidir?

Otelin tek bir resepsiyon masası vardır ve o masa kapanırsa otel bir anda durmaz. Odasında olan misafirler odasındadır, anahtarları çalışmaya devam eder; kimse onları dışarı çıkarmaz. Duran şey yeni girişlerdir: lobide bekleyen misafir anahtar alamaz, konaklamasını uzatmak isteyen uzatamaz. Otel dolu göründüğü sürece sorun görünmez, sorun kapıdan girenle başlar.

Üretim ağında tek DHCP sunucusu çevrimdışı olduğunda tam olarak bu yaşanır. Mevcut istemciler lease süresi bitene kadar IP’lerini korur; IP’yi tutmak için sunucunun ayakta olması gerekmez. Ancak yeni bağlanan cihazlar, lease süresi dolan cihazlar ve yenileme yapamayan cihazlar IP alamaz hale gelir.

Bu, arızanın neden geç fark edildiğini de açıklar. Lease süresi 8 gün olarak ayarlanmışsa sabah ofise gelen çalışanlar büyük ihtimalle sorunsuz bağlanır; ama gece yarısı yeniden başlayan bir üretim sunucusu veya güncelleme sonrası yeniden başlayan bir cihaz sabah bağlanamaz. 7/24 çalışan ortamlarda, hastanelerde ve fabrikalarda bu tek nokta arızası (Single Point of Failure) kabul edilemez bir risktir. Kavramın kendisini ve kurumdaki diğer tek noktaların nasıl bulunduğunu SPoF rehberimizde ele alıyoruz.

DHCP Failover, iki DHCP sunucusunun aynı scope’u paylaşarak birbirinin yedeği olduğu yapıdır. Windows Server 2012 ile gelen bu özellik iki modda çalışır. Hot Standby modunda birincil sunucu aktif IP dağıtır; ikincil beklemededir ve yalnızca birincil erişilemez olduğunda devreye girer. Load Balance modunda her iki sunucu da aktif olarak DHCP isteklerine yanıt verir; varsayılan yük dağılımı %50-50’dir ama ayarlanabilir. Çoğu ortamda Hot Standby daha öngörülebilir davranış sunar; Load Balance ise yüksek istemci yoğunluğu olan büyük ağlar için uygundur.

Failover Yapılandırması

Failover yapılandırmak için ikinci bir Windows Server DHCP sunucusunun kurulu, domain’e üye ve yetkilendirilmiş olması gerekir; bu sunucuda scope oluşturmanıza gerek yoktur. DHCP Manager’da birincil sunucunun IPv4 düğümüne sağ tıklayın ve “Configure Failover” seçeneğini seçin.

Sihirbaz açılır:

1. Scope seçimi: Failover’a dahil edilecek scope’ları seçin; birden fazla scope olabilir.
2. Partner Server: İkinci DHCP sunucusunun adını veya IP’sini yazın; bağlantı test edilir.
3. Relationship Name: İki sunucu arasındaki ilişkiye bir isim verin; birden fazla failover ilişkisi varsa ayırt etmeye yarar.
4. Mode: Hot Standby veya Load Balance. Sihirbaz Load Balance ile açılır, yani alanı değiştirmeden ilerlerseniz yük paylaşımlı bir ilişki kurmuş olursunuz. Hot Standby istiyorsanız bu adımda bilinçli olarak seçmeniz gerekir; seçtiğinizde yüzdelik kutusu yerine hangi sunucunun aktif, hangisinin yedek olacağını ve yedeğe ayrılan adres oranını (varsayılan yüzde 5) soran alanlar gelir.
5. Maximum Client Lead Time (MCLT): Yedek sunucunun, aktif sunucu erişilemez olduktan sonra havuzun tamamını devralmadan önce beklediği süredir; varsayılan 1 saattir ve çoğu ortamda değiştirmeniz gerekmez.
6. State Switchover Interval: Otomatik devreye geçme süresini belirler; boş bırakırsanız manuel müdahale gerekir. Üretim ortamlarında otomatik geçiş için bir değer girin.
7. Shared Secret: İki sunucu arasındaki iletişimi doğrulayan paylaşılan parola; güçlü bir değer seçin ve kaydedin.

Hot Standby seçtiğinizde karşınıza çıkan iki sayı, MCLT ve yedeğe ayrılan adres yüzdesi, birlikte anlam kazanır. Yedek sunucu normal şartlarda hiç adres dağıtmaz; aktif sunucu düştüğünde de havuzun tamamını hemen devralmaz, önce MCLT süresi kadar bekler. O bekleme penceresinde elinin tamamen boş kalmaması için küçük bir pay ayrılır: varsayılan yüzde 5, yüz adreslik bir havuzda beş adres demektir ve kesintiden sonraki ilk saatte ağa yeni katılan cihazlar bu paydan hizmet alır. Süre dolduğunda yedek havuzun tamamını üstlenir.

Ölçüt şudur: aktif sunucu düştükten sonraki MCLT penceresinde kaç yeni cihaz bağlanabilir? Sabit cihazların hâkim olduğu bir ofiste yüzde 5 fazlasıyla yeterlidir. Cihaz sirkülasyonunun yüksek olduğu ortamlarda ise hem bu oranı yükseltmek hem MCLT’yi kısaltmak gerekir; aksi halde kesinti anında yedek sunucu ayakta olduğu halde yeni cihazlara verecek adresi kalmaz.

Sihirbaz tamamlandığında scope çoğaltma işlemi otomatik başlar. Doğrulamanın en hızlı yolu ikinci sunucunun konsolunu açmaktır: siz orada hiçbir scope oluşturmadığınız halde aynı scope “Active” durumda listelenmiş olmalıdır. İlişkinin adını, modunu ve anlık durumunu görmek için Get-DhcpServerv4Failover komutunu kullanın. Sağlıklı bir hot standby ilişkisinde çıktı şuna benzer:

Name                : OFIS_FAILOVER
PartnerServer       : dhcp02.ad.sercebilisim.com
Mode                : HotStandby
ServerRole          : Active
ReservePercent      : 5
MaxClientLeadTime   : 01:00:00
StateSwitchInterval : 01:00:00
State               : Normal
ScopeId             : 192.168.1.0

Üç satır kritiktir. State alanı Normal değilse ilişki kurulmuş ama sağlıklı çalışmıyor demektir; Communication interrupted iki sunucunun birbirine ulaşamadığını, Partner down ise karşı tarafın kapalı olduğunu gösterir. ServerRole, komutu çalıştırdığınız sunucunun rolüdür; DHCP01’de Active görmeniz gerekir, Standby görüyorsanız sihirbazda roller ters kurulmuştur. StateSwitchInterval boşsa otomatik devralma kapalıdır ve kesinti anında elle müdahale gerekir.

Failover ilişkisi scope seviyesinden değil, IPv4 düğümünden yönetilir. Aynı sağ tık menüsünde ilişkiyi kurduğunuz Configure Failover seçeneğinin yanında Replicate Failover Scopes de bulunur; scope ayarlarını sonradan değiştirdiğinizde değişikliği partner sunucuya elle taşımak için bu seçeneği kullanırsınız.

Failover Kurdunuz, Yine de Sabaha Ağ Ölü Kalabilir

Buraya kadar geldiyseniz artık iki DHCP sunucunuz var ve biri düştüğünde diğeri devreye giriyor. Yine de kurtarma planınızın tamamlandığını söylemek için erken. Aşağıdaki vaka, failover’ın kağıt üstünde var olup pratikte devreye girmediği bir arıza türünü anlatıyor.

Danışmanlık verdiğim bir kurumda tekrar eden bir arıza vardı: elektrik kesintisinden sonra internet geri gelmiyordu. Şikayet her seferinde “internet yok” diye ulaşıyordu ve ilk bakılan yer doğal olarak ISP hattı, sonra firewall, sonra switch’ler oluyordu. Oysa sorun bunların hiçbirinde değildi. Elektrik geri geldiğinde DHCP sunucusu kendiliğinden açılmıyor, dolayısıyla ağda kimseye IP dağıtılmıyordu. Cihazlar birer birer kirası dolarken ağdan düşüyordu; internetin gitmesi kesintinin kendisinde değil, saatler sonra gerçekleşiyordu.

Sebep bulunduğunda arızanın DHCP ile ilgisi olmadığı görüldü. DHCP sunucusu fiziksel bir makine değildi; bir hypervisor üzerinde sanal sunucu olarak çalışıyordu. Elektrik geri geldiğinde fiziksel sunucu açılıyor, hypervisor sorunsuz ayağa kalkıyordu; ancak otomatik başlatma ayarı yapılmadığı için sanal sunucu kapalı kalıyordu. Yani izleme tarafından bakıldığında fiziksel sunucu ayaktaydı ve her şey normal görünüyordu, sadece içindeki sunucu hiç açılmamıştı.

Açıldığı durumlarda da her zaman hizmet vermiyordu: sanal sunucu bazen Windows güncelleme ekranında bekliyor, servis o süre boyunca çalışmıyordu.

Buradaki asıl ders arızanın türüyle ilgili. Sunucu ölmemişti; hiç açılmamıştı. “Fiziksel sunucu açıldı” ile “servis hizmet veriyor” aynı şey değildir ve arada kaç katman varsa kurtarma zincirinin o kadar halkası vardır: elektrik gelir, donanım açılır, hypervisor açılır, sanal sunucu açılır, işletim sistemi güncellemeleri bitirir, servis başlar. Halkalardan biri kopuksa zincirin geri kalanı çalışıyor olması hiçbir şey ifade etmez.

Bu yüzden failover kurmak tek başına yeterli değildir. Failover donanım arızasına karşı korur; sanal sunucunun hiç açılmamasına karşı korumaz. Üstelik iki DHCP sunucusu aynı hypervisor üzerinde sanal sunucu olarak duruyorsa, ikisi de aynı kesintide aynı şekilde kapalı kalır. Yapılacaklar şunlardır: hypervisor tarafında sanal sunucunun otomatik başlatma eylemini ve başlatma sırasını tanımlayın (kimlik ve ad çözümleme sunucuları ona bağımlı olanlardan önce açılmalıdır), işletim sistemi tarafında güncelleme ve yeniden başlatma penceresini hizmet dışı saatlere sabitleyin, ve zinciri bir bakım penceresinde gerçekten elektriği keserek uçtan uca test edin. Bu test yapılmadığı sürece kurtarma planı bir varsayımdır.

Bu tür tekrar eden arızaların en can sıkıcı yanı, her seferinde sıfırdan teşhis edilmesidir. O kurumda bu problemi çözümüyle birlikte yazılı hale getirdik; nöbetteki kişi aynı şikayeti bir daha aldığında hattı değil servisi kontrol etti. Nasıl kayıt altına aldığımızı BT dokümantasyon sunucusu vaka çalışmamızda anlatıyoruz.

PowerShell ile DHCP Kurulumu ve Yapılandırması

Otel resepsiyonunu tek tek elle yönetmek yerine, aynı işi bir yazılımla toplu yapmak da mümkündür. Bu bölüm, makale boyunca arayüzden yaptığımız işlemlerin tamamının PowerShell karşılığıdır: rol kurulumundan scope ve seçeneklere, rezervasyondan ikinci sunucunun hazırlanması ve failover ilişkisine kadar. Tek sunucuda arayüz genellikle daha hızlıdır; ancak birden fazla sunucuya aynı yapılandırmayı kuracaksanız, kurulumu belgelemek istiyorsanız veya felaket sonrası hızlı geri dönüş için elinizde çalıştırılabilir bir kayıt bulunmasını istiyorsanız PowerShell tercih edilir.

Rol kurulumu ve post-install adımları:

Install-WindowsFeature -Name DHCP -IncludeManagementTools
Add-DhcpServerSecurityGroup
Restart-Service dhcpserver

AD’de yetkilendirme:

Add-DhcpServerInDC -DnsName "dhcp01.ad.sercebilisim.com" -IPAddress 192.168.1.5
Get-DhcpServerInDC

Scope oluşturma ve exclusion range:

Add-DhcpServerv4Scope -Name "OFIS_AGI" -StartRange 192.168.1.100 -EndRange 192.168.1.200 -SubnetMask 255.255.255.0 -State Active
Add-DhcpServerv4ExclusionRange -ScopeId 192.168.1.0 -StartRange 192.168.1.190 -EndRange 192.168.1.200

Seçenekleri doğru katmana yazmak: -ScopeId parametresi verilmezse değer Server Options seviyesine, verilirse o scope’a yazılır. DNS bilgisi kurum genelinde aynı olduğu için sunucu seviyesine, gateway her alt ağda farklı olduğu için scope seviyesine gider:

Set-DhcpServerv4OptionValue -DnsServer 192.168.1.10 -DnsDomain "ad.sercebilisim.com"
Set-DhcpServerv4OptionValue -ScopeId 192.168.1.0 -Router 192.168.1.1

Rezervasyon ekleme ve mevcut kiraları listeleme:

Add-DhcpServerv4Reservation -ScopeId 192.168.1.0 -IPAddress 192.168.1.150 -ClientId "00155D1A2B3C" -Description "Muhasebe Kat Yazicisi"
Get-DhcpServerv4Lease -ScopeId 192.168.1.0
Get-DhcpServerv4Reservation -ScopeId 192.168.1.0

İkinci sunucuyu (DHCP02) hazırlama. Bu adımlar DHCP01 üzerinden uzaktan çalıştırılabilir; sunucunun domain’e üye ve WinRM ile yönetilebilir olması yeterlidir:

Install-WindowsFeature -Name DHCP -IncludeManagementTools -ComputerName DHCP02

Invoke-Command -ComputerName DHCP02 -ScriptBlock {
    Add-DhcpServerSecurityGroup
    Restart-Service dhcpserver
}

Add-DhcpServerInDC -DnsName "dhcp02.ad.sercebilisim.com" -IPAddress 192.168.1.6
Get-DhcpServerInDC

Get-DhcpServerInDC çıktısında iki sunucunun da listelenmesi gerekir; yetkilendirilmemiş bir partner ile failover ilişkisi kurulsa bile ikinci sunucu IP dağıtmaz. DHCP02 üzerinde scope OLUŞTURMAYIN. Failover sihirbazı scope’u kendisi çoğaltır; önceden oluşturulmuş bir scope çakışmaya yol açar.

Failover ilişkisi kurma (hot standby):

Add-DhcpServerv4Failover -ComputerName dhcp01 -PartnerServer dhcp02 -Name "OFIS_FAILOVER" -ScopeId 192.168.1.0 -ServerRole Active -ReservePercent 5 -SharedSecret "<guclu-bir-parola>"
Get-DhcpServerv4Failover

DHCP Sorun Giderme ve Sık Yapılan Hatalar

DHCP arızalarının ortak özelliği, hatanın yapıldığı yerde değil bambaşka bir yerde görünmesidir. Şikayet “internet yok” veya “domain’e giremiyorum” diye gelir; DHCP’yi kimse şüpheli listesine yazmaz. Aşağıdaki tablo sahada en sık karşılaştığım belirtileri kaynaklarıyla eşleştiriyor.

Tabloya girmeyen ama tekrarlayan beş hata daha var.

DNS seçeneğini tek sunucuya bağlamak. Bu, failover kurup rahatlayan ekiplerin en sık gözden kaçırdığı noktadır. DHCP’yi yedeklediniz, iki sunucu da IP dağıtıyor; ama 006 DNS Servers alanında tek bir Domain Controller yazıyorsa o sunucu çöktüğünde ağdaki herkes ad çözümlemesini kaybeder. Dikkat çekici olan, arızanın DHCP tarafında hiçbir belirti vermemesidir: kiralar sağlıklı, adresler dağıtılıyor, gateway doğru. Kullanıcı “internet yok” der, yönetici DHCP’ye bakar ve her şeyi normal bulur. Alana en az iki DNS sunucusu yazın; tek DC’li ortamda bu zaten ikinci bir DC gerekçesidir. Adresi elle yazarken bir hane hatası yapmak da aynı sonucu verir ve daha da sinsidir, çünkü sunucu ayaktadır, sadece istemcilere yanlış adres gitmektedir.

Statik IP’leri belgelememek. Statik adresler DHCP’nin görüş alanı dışındadır: sunucu onları bilmez, listelemez, çakışma olduğunda uyarmaz. Bir yazıcıya elle IP verip kimseye söylememek, aylar sonra o adresi havuzdan alan bir dizüstü bilgisayarla çakışma üretir ve iki cihaz da düzgün çalışmaz. Kural üç adımlıdır: statik verdiyseniz adresi exclusion range’e ekleyin, bir yere yazın, ve mümkün olan her yerde statik yerine rezervasyon kullanın. Rezervasyon aynı sabitliği verir ama DHCP’nin defterinde görünür, tek yerden değiştirilir ve çakışma ihtimalini ortadan kaldırır.

Failover shared secret’ını kaydetmemek. Failover kurulumunda girilen paylaşılan parola bir daha ekrana gelmez. İlişkiyi bozup yeniden kurmanız gerektiğinde veya ikinci sunucuyu baştan kurarken bu değere ihtiyaç duyarsınız. Kurulum anında parola kasanıza yazın; sonradan öğrenmenin yolu ilişkiyi silip yeniden kurmaktır.

Scope’u silmeden subnet değiştirmeye çalışmak. Scope oluştururken girilen subnet mask sonradan düzenlenemez. Yanlış maske girildiğini fark ettiğinizde tek yol scope’u silip yeniden oluşturmaktır; bu da tüm rezervasyonların kaybolması demektir. Silmeden önce Export-DhcpServer ile yedek alın, rezervasyonları yeni scope’a aktarın.

Lease süresini gereğinden kısa tutmak. “IP’ler daha hızlı geri dönsün” diyerek süreyi 1-2 saate indirmek gereksiz yenileme trafiği üretir ve sunucuya yük bindirir. Sabit cihazların hâkim olduğu ofis ağlarında 8 günlük varsayılan değer uygundur; kısa süre yalnızca cihaz sirkülasyonunun gerçekten yüksek olduğu misafir ağlarında anlamlıdır.

Sonraki Adımlar

DHCP yapılandırıldı, IP dağıtımı otomatik ve merkezi hale geldi. Active Directory DNS yapılandırması tamamlanmışsa kullanıcı bilgisayarları artık hem otomatik IP alıyor hem internet erişimine sahip. Sıradaki adım kullanıcı kimliklerini yönetmek: Active Directory UPN Suffix yapılandırması ve Microsoft Entra ID Connect ile on-premises kimliği buluta taşıyabilirsiniz.

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.