FortiGate Firewall DHCP Sunucusu: Kapsam ve Rezervasyon

FortiGate Firewall DHCP sunucusu, bir iç arayüze bağlı cihazlara adres, ağ geçidi ve DNS bilgisini dağıtan servistir ve Network → Interfaces ekranında arayüz düzenlenirken DHCP Server bölümünde açılır.

Microsoft’un ve DHCP standardının (RFC 2131) tarif ettiği düzende Active Directory istemcileri adresi kurumun DHCP sunucusundan alır, FortiGate de isteği o sunucuya iletir (DHCP relay). Misafir, depo ve DMZ gibi AD dışındaki ağlara FortiGate kendisi dağıtır. İstemcilere yalnız onların ulaşabildiği ve iç adları doğru bilen DNS sunucuları verilir.

Bu yazı FortiGate Firewall yapılandırma rehberimizin 10. adımıdır. Lab’da VLAN yazısında açtığım VLAN’lardan ikisine DHCP sunucusu, birine DHCP relay kurdum. En öğretici iki bulgu şunlar: FortiGate fabrika ayarında istemcilere internetteki ikincil DNS’i de verdi ve relay, sunucunun başka bir adresinden gelen cevabı kapıda düşürdü.

Örnekteki sınır kapısının yanında tırların bekleme sahası vardır. Görevli gelen tıra bir bölme gösterir, ama göstermeden önce sıraya bakar; kayıtsız bir aracın durduğu bölmeyi atlar ve bir sonrakini verir. FortiGate’te bölmeler adres aralığı, kayıtsız araç da aralığın içinde statik adresle duran bir cihazdır.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde iç ağ bölümlerine adres dağıtırken kurduğumuz düzeni anlatır.

FortiGate DHCP Formu Fabrika Ayarında Ne Getiriyor?

DHCP’nin dört mesajlık akışını (Discover, Offer, Request, Acknowledge) DHCP nedir yazımızda anlattık; FortiGate aynı akışı konuşur. depo arayüzünde DHCP Server anahtarını açınca form şu değerlerle geldi:

1. Address range: ağın tamamı, 10.34.90.2-10.34.90.254.
2. Default gateway: Same as Interface IP, yani FortiGate’in bu VLAN’daki adresi.
3. DNS server: Same as System DNS, yani FortiGate’in kendi DNS ayarındaki sunucular.
4. Lease time: 604800 saniye, yani 7 gün.

Formu bu hâliyle kaydedip bir istemciyi adres istemeye bıraktım. İstemciye giden teklifin DNS satırı şuydu:

    10.34.90.1.67 > 10.34.90.3.68: [udp sum ok] BOOTP/DHCP, Reply, length 309, xid 0xa5129cd5, Flags [none] (0x0000)
      Your-IP 10.34.90.3
...
        DHCP-Message (53), length 1: Offer
        Server-ID (54), length 4: 10.34.90.1
        Lease-Time (51), length 4: 604800
        Subnet-Mask (1), length 4: 255.255.255.0
        Default-Gateway (3), length 4: 10.34.90.1
        Domain-Name-Server (6), length 8: 192.168.1.10,8.8.8.8
        RN (58), length 4: 302400
        RB (59), length 4: 529200
        Unknown (224), length 17: 70.71.86.77.69.86.66.84.52.87.80.75.85.75.65.65.0

Teklifte dört şey dikkat istiyor:

1. DNS olarak 192.168.1.10 ile birlikte 8.8.8.8 gitti. FortiGate’in kendi DNS ayarında ikincil sunucu olarak bir Public DNS’in (internetteki herkese açık DNS sunucusu) adresi yazılı ve fabrika ayarı onu istemcilere de dağıtıyor. DNS ayarı yazımızda Public DNS’in iç adları yanlış adrese çözdüğünü ölçtük; bu seçenek o tuzağı her istemciye taşıyor.
2. RN ve RB yenileme zamanları. İstemci kiranın yarısında (302400 saniye) yenilemeyi, yüzde 87,5’inde (529200 saniye) herhangi bir sunucudan almayı dener; RFC 2131’in fabrika değerleri bunlardır. İkisinin mantığını DHCP nedir yazımızın kira bölümünde anlattık.
3. Seçenek 224, FortiGate’in seri numarası. Baytlar ASCII olarak FGVMEVBT4WPKUKAA okunuyor; FortiGate her teklife kendi seri numarasını ekliyor.
4. Alan adı ve NTP gitmedi. İstemci alan adını (seçenek 15) istedi, ama formda bu alan yok. NTP seçeneği Advanced altında Specify ve boş listeyle geliyor.

Aralığın ağın tamamını kapsamasının bedelini de aşağıda ölçtüm. İkisi de aynı yere çıkıyor: form çalışır, ama doğru düzeni kendisi kurmaz.

FortiGate DHCP Düzeni Nasıl Olmalı?

Active Directory istemcilerinin olduğu ağlarda adresi kurumun DHCP sunucusu dağıtır, FortiGate isteği ona iletir. Misafir, depo ve DMZ gibi AD dışındaki ağlarda FortiGate’in kendi sunucusu kullanılır. Aralık statik adreslerin dışına konur, yönetim ve yazıcı gibi adresi değişmemesi gereken cihazlar rezervasyon alır ve her ağa yalnız o ağın ulaşabildiği DNS sunucuları verilir.

Bu düzeni dört kaynak birlikte tarif ediyor:

1. Microsoft, DNS istemci ayarları belgesi: domain üyesi bir bilgisayarın DNS ayarında yalnız AD’nin DNS sunucuları durur. Bir Public DNS’in adresi yazılmaz. DHCP’nin istemciye verdiği DNS listesi bu ayarın kendisidir.
2. RFC 2131 (Mart 1997), bölüm 2.2 ve 4.1: sunucu bir adresi vermeden önce onu yoklamalıdır (RFC dilinde SHOULD, yani güçlü öneri), istemci de aldığı adresi ARP ile yoklamalıdır. Arada relay varsa sunucu cevabı relay’in Gateway-IP alanına yazdığı adrese gönderir.
3. RFC 3046 (Ocak 2001): relay, isteğe kendi bilgisini (seçenek 82) ekleyebilir; sunucu hangi arayüzden gelindiğini buradan okur.
4. NSA, Network Infrastructure Security Guidance (Mart 2022 sürümü), bölüm 7.4: yönetici sistemlerine statik adres ya da küçük bir havuz verilir; erişim listesi ancak böyle tanımlanabilir. FortiGate’te bu, yönetici bilgisayarının rezervasyonudur.

Hangi ağın adresi kimden alacağını şu tablo özetliyor:

Seçeneklerin genişletilmiş karşılaştırmasını Windows Server DHCP kurulumu yazımızda verdik. Lab’da Windows DHCP sunucusu yok; kurumun DHCP sunucusunu sunucu ağındaki ntp01’de (192.168.1.15) çalışan bir DHCP servisiyle taklit ettim. Relay tarafı için sunucunun markası fark etmiyor.

Adres Aralığı Nasıl Bölünür?

RFC ve Microsoft bir oran vermiyor; ölçüt, statik cihazların ve büyümenin aralığın dışında kalmasıdır. Bizim planımızda her /24 ağ aynı biçimde bölünür:

Her ağda aynı bölünme, adrese bakan kişiye cihazın türünü de söyler: .50 bir rezervasyondur, .150 dinamik bir istemcidir.

FortiGate’te DHCP Sunucusu Açmak

Bu adımdan önce iki şey hazır olmalı:

1. VLAN arayüzü ve adresi. Lab’da depo, 10.34.90.1/24; açılışını VLAN yazısında anlattık.
2. Aralık planı ve DNS sunucusu. Yukarıdaki tablo ve iç DNS, lab’da dc01 (192.168.1.10).

Ayar Network → Interfaces → depo → Edit yolunda, DHCP Server anahtarı açılarak yapılır:

1. Address range: plandaki aralık, 10.34.90.100-10.34.90.199.
2. Netmask: arayüzün maskesi, 255.255.255.0.
3. Default gateway: Same as Interface IP.
4. DNS server: Specify, DNS server 1 alanına 192.168.1.10. FortiGate’in DNS ayarındaki ikincil sunucu böylece istemcilere gitmez.
5. Lease time: fabrika değeri 7 gün, öyle kaldı.

Aynı ayarın komut satırındaki karşılığı, cihazın kendi çıktısından:

config system dhcp server
    edit 3
        set default-gateway 10.34.90.1
        set netmask 255.255.255.0
        set interface "depo"
        config ip-range
            edit 1
                set start-ip 10.34.90.100
                set end-ip 10.34.90.199
            next
        end
        set dns-server1 192.168.1.10
    next
end

İstemcinin aldığı teklifte DNS satırı artık tek sunucu gösteriyor: Domain-Name-Server (6), length 4: 192.168.1.10.

Aralıktaki Statik Cihaz: FortiGate Önce Yokluyor

Planı atlasam ne olacağını, formu fabrika ayarındaki aralıkla kaydedip ölçtüm. Aynı VLAN’daki bir cihaza statik olarak 10.34.90.2’yi verdim ve yeni bir istemciyi adres istemeye bıraktım. FortiGate teklif göndermeden önce ARP ile sordu: “bu adres kimde?”

10:11:23.623895 02:00:00:34:90:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 51575, offset 0, flags [none], proto UDP (17), length 328)
...
10:11:23.625499 00:0c:29:d1:72:37 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Request who-has 10.34.90.2 tell 10.34.90.1, length 42
10:11:23.625606 00:0c:29:a0:71:ae > 00:0c:29:d1:72:37, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.34.90.2 is-at 00:0c:29:a0:71:ae, length 28
10:11:27.991586 02:00:00:34:90:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 16871, offset 0, flags [none], proto UDP (17), length 328)
...
10:11:27.993206 00:0c:29:d1:72:37 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Request who-has 10.34.90.3 tell 10.34.90.1, length 42

Statik cihaz cevap verdi, FortiGate ilk isteği cevapsız bıraktı. İstemcinin ikinci isteğinde 10.34.90.3’ü iki kez yokladı, cevap gelmeyince onu önerdi; ilk istekten teklife 5,4 saniye geçti. RFC 2131’in bölüm 2.2’de istediği yoklama budur. Kira listesi (execute dhcp lease-list depo) atlanan adresi ayrıca tutuyor:

depo
  IP		MAC-Address		Hostname            VCI                 SSID                AP                  SERVER-ID           Expiry
  10.34.90.3	02:00:00:34:90:50	                                                                                3                   Thu Oct  8 13:11:56 2026
depo [Conflicted leases]
  IP			Expiry
  10.34.90.2		Thu Oct  1 13:41:23 2026

10.34.90.2 30 dakikalığına Conflicted leases altına alındı; bu süre CLI’daki conflicted-ip-timeout 1800 satırından geliyor. Koruma işe yarıyor, ama bir güvenlik ağıdır: ARP yoklaması yalnız o an açık olan cihazı görür. Kapalı bir yazıcının adresi dağıtılır ve çakışma yazıcı açıldığında başlar. Aralığı plandaki gibi statik adreslerin dışına koymak bu yüzden yine gerekir.

FortiGate DHCP Rezervasyonu: MAC Adresine Sabit Adres

Etiket yazıcısı gibi adresi değişmemesi gereken bir cihaz için iki yol var: cihaza statik adres vermek ya da DHCP’de adresini ayırmak. Rezervasyonun kazancı, adresin tek yerden yönetilmesidir. Bu adımdan önce cihazın MAC adresi bilinmeli; lab’da 02:00:00:34:90:50. Cihaz zaten kira aldıysa tablonun Add from DHCP Client List düğmesi MAC adresini kira listesinden getiriyor.

Rezervasyon depo arayüzünün DHCP bölümünde Advanced açılınca en altta çıkan IP Address Assignment Rules tablosunda, Create New ile açılır:

1. Type: MAC Address.
2. Description: Depo etiket yazicisi.
3. MAC address: cihazın MAC adresi.
4. Action type: Reserve IP, IP alanına plandaki statik bloktan 10.34.90.50.

Tablonun altındaki örtük satır (Unknown MAC Addresses → Assign IP) kuralın geri kalanını söylüyor: tanınmayan her cihaz aralıktan adres alıyor. Formdaki eylem listesinde Block da var. Kaydedince cihaz DHCP sunucusunu şöyle yazdı:

config system dhcp server
    edit 3
        set default-gateway 10.34.90.1
        set netmask 255.255.255.0
        set interface "depo"
        config ip-range
            edit 1
                set start-ip 10.34.90.100
                set end-ip 10.34.90.199
            next
        end
        config reserved-address
            edit 1
                set ip 10.34.90.50
                set mac 02:00:00:34:90:50
                set description "Depo etiket yazicisi"
            next
        end
        set dns-server1 192.168.1.10
    next
end

10.34.90.50 aralığın dışında ve bunu bilerek yaptım: rezervasyonlar plandaki statik bloktan veriliyor. İstemci kirasını yenilerken önce eski adresini (10.34.90.3) iki kez istedi; FortiGate ikisini de reddetti, istemci baştan başladı ve ayrılmış adresi aldı:

        Requested-IP (50), length 4: 10.34.90.3
        DHCP-Message (53), length 1: Request
...
        DHCP-Message (53), length 1: NACK
...
      Your-IP 10.34.90.50
        DHCP-Message (53), length 1: ACK
        Server-ID (54), length 4: 10.34.90.1
...
        Domain-Name-Server (6), length 4: 192.168.1.10

NACK, sunucunun “bu adres artık senin değil” cevabıdır; istemci bunu alınca sıfırdan istek gönderir. Hangi cihazların rezervasyon gerektirdiğini Windows Server DHCP kurulumu yazımızın rezervasyon bölümünde tarttık; ölçüt FortiGate’te de aynıdır.

Misafir Ağına Hangi DNS Verilir?

Misafir ağı da adresini FortiGate’ten alır. misafir arayüzünde aynı formu fabrika ayarındaki DNS seçeneğiyle açtım; misafir istemcisine 192.168.1.10,8.8.8.8 gitti. Misafirin bu sunuculara sorusunu FortiGate’te izledim:

... func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=17, 10.34.60.100:46512->192.168.1.10:53) tun_id=0.0.0.0 from misafir. "
...
... func=fw_forward_handler line=719 msg="Denied by forward policy check (policy 0)"

Misafir ağından iç DNS sunucusuna giden bir kural yok ve olmamalı; soru policy 0 ile düştü, istemcide zaman aşımına uğradı. Lab’da 8.8.8.8’e giden yol DNS yazısındaki ölçüm için yönetim ağından geçtiği için o soru da aynı kurala takıldı. Gerçek bir ağda misafir ikinci sunucudan cevap alırdı, ama önce cevap vermeyen iç sunucuyu beklerdi.

Doğru düzende misafire iç DNS verilmez. DNS server satırında Specify seçip servis sağlayıcının DNS’ini yazdım; lab’da bu 203.0.113.53:

config system dhcp server
    edit 4
        set default-gateway 10.34.60.1
        set netmask 255.255.255.0
        set interface "misafir"
        config ip-range
            edit 1
                set start-ip 10.34.60.100
                set end-ip 10.34.60.199
            next
        end
        set dns-server1 203.0.113.53
    next
end

Misafir istemcisi bu kez Domain-Name-Server (6), length 4: 203.0.113.53 aldı. Dış bir ad çözüldü, iç ad ise bilinmedi:

203.0.113.66
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45753

İlk satır www.example.com’un cevabı, ikincisi dc01.ad.sistemkusu.com’un. Misafir internete çıkıyor, kurumun iç adlarını öğrenemiyor.

FortiGate DHCP Relay: Adresleri Kurumun Sunucusu Dağıtsın

muhasebe VLAN’ındaki bilgisayarlar AD üyesi ve adresi kurumun DHCP sunucusu dağıtacak. Adres isteği yayındır ve VLAN’ın dışına çıkmaz. Sunucu başka ağdaysa arada biri isteği duyup sunucuya taşımalı, sunucunun cevabını da VLAN’a geri indirmelidir. FortiGate bu işi VLAN’ın ağ geçidi olarak yapar.

Bu işin adı DHCP relay. Relay İngilizcede röle demektir. 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 kısa menzilli bir telsizin sesini alır ve daha uzağa yeniden yayınlar. DHCP relay de duyduğu isteği başka bir ağdaki sunucuya yeniden gönderir. Sunucunun kendi ağında olmayan bir VLAN’a nasıl adres verdiğini DHCP nedir yazımızın relay bölümünde diyagramla anlattık.

Bu adımdan önce iki şey hazır olmalı:

1. Sunucuda bu VLAN’ın kapsamı. Lab’da 10.34.70.100-10.34.70.199, ağ geçidi 10.34.70.1, DNS 192.168.1.10, alan adı ad.sistemkusu.com.
2. Sunucudan VLAN’a dönüş yolu. Sunucu cevabı relay’in adresine (10.34.70.1) gönderir; o adrese yolu olmalıdır.

muhasebe arayüzünün DHCP bölümünde Advanced altındaki Mode satırını Relay yaptım ve DHCP Server IP alanına sunucunun adresini yazdım:

Relay ayarı DHCP sunucu listesine değil, arayüzün kendisine yazılıyor:

config system interface
    edit "muhasebe"
        set dhcp-relay-service enable
        set dhcp-relay-ip "192.168.1.15"
    next
end

İstemci adres istedi ve sunucunun tarafında isteği şöyle gördüm:

    10.34.70.1.67 > 192.168.1.15.67: [udp sum ok] BOOTP/DHCP, Request from 02:00:00:34:70:01, length 302, hops 1, xid 0x40a2d4a2, Flags [none] (0x0000)
      Gateway-IP 10.34.70.1
        DHCP-Message (53), length 1: Discover
...
        Agent-Information (82), length 10: 
          Circuit-ID SubOption 1, length 8: muhasebe

FortiGate isteği muhasebe arayüzünün adresinden, Gateway-IP alanına da aynı adresi yazarak sunucuya iletti ve seçenek 82’ye arayüzün adını (muhasebe) ekledi. Sunucunun cevabı 192.168.1.15’ten geldi ve FortiGate onu istemciye iletti:

(xid:40a2d4a2) received request message from 0.0.0.0:68 to 255.255.255.255 at muhasebe
(xid:40a2d4a2) got a DHCPDISCOVER
(xid:40a2d4a2) Warning! can't get server id from client message
(xid:40a2d4a2) forwarding dhcp request from 10.34.70.1:67 to 192.168.1.15:67
(xid:40a2d4a2) received request message from 192.168.1.15:67 to 10.34.70.1 at port1
(xid:40a2d4a2) got a DHCPOFFER
...
(xid:40a2d4a2) Send unicast to client, devidx 19 ip 10.34.70.111 mac 2:0:0:34:70:1
(xid:40a2d4a2) sending dhcp reply from 10.34.70.1:67 to 10.34.70.111:68

Bu iz, diagnose debug application dhcprelay -1 ve diagnose debug enable ile açılıyor; satır başlarındaki tarih kısaltıldı. İstemci 10.34.70.111 adresini, 192.168.1.10 DNS’ini ve ad.sistemkusu.com alan adını aldı; formunda alan adı alanı olmayan FortiGate’in veremediği seçenek kurumun sunucusundan geldi.

Relay Cevabı Neden Kapıda Kalır?

Relay bir postane gibi çalışır: mektubu kendi adresinden gönderir, cevabı da kendi adresine bekler. FortiGate’te önemli olan, cevabın kimden geldiğidir.

Bunu dört parça anlatıyor:

1. Relay adresi (dhcp-relay-ip) görevlinin dilekçeyi gönderdiği memurdur.
2. Gateway-IP dilekçenin üstüne yazılan “cevabı bu kapıya gönderin” notudur; lab’da 10.34.70.1.
3. Oturum görevlinin defterine yazdığı satırdır: “10.34.70.1’den 192.168.1.15’e bir dilekçe gitti.”
4. Local-in denetimi FortiGate’in kendisine gelen trafiğe baktığı kapıdır. Defterde karşılığı olmayan cevap burada kural arar ve bulamaz.

Örnekteki sınır kapısında görevli dilekçeyi başka bir kapıdaki memura gönderir ve kime gönderdiğini deftere yazar. Cevap o memurun imzasıyla gelirse tıra iletilir. Aynı binadaki başka bir memurun imzasıyla gelen cevap ise defterde karşılığı olmadığı için kapıda bekler. Adımlar şöyle:

1. İstemci Discover’ı yayın olarak gönderir.
2. FortiGate isteği relay adresine tek yayın olarak iletir ve bu gidiş için bir oturum açar.
3. Sunucu cevabı Gateway-IP’ye gönderir. Cevabın kaynağı relay adresiyse oturumun dönüş yönü olarak kabul edilir.
4. Kaynak başka bir adresse cevap yeni bir trafik sayılır, local-in denetiminde kural bulamaz ve düşer.

Lab’da bunu, sunucuya ikinci bir adres (192.168.1.16) verip relay adresini ona çevirerek ölçtüm. Sunucu cevabı yine birincil adresinden (192.168.1.15) verdi ve FortiGate onu düşürdü:

... func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=17, 192.168.1.15:67->10.34.70.1:67) tun_id=0.0.0.0 from port1. "
... func=init_ip_session_common line=6024 msg="allocate a new session-00040621, tun_id=0.0.0.0"
... func=vf_ip_route_input_common line=2605 msg="find a route: flag=80000000 gw-10.34.70.1 via root"
... func=fw_local_in_handler line=500 msg="iprope_in_check() check failed on policy 0, drop"

Cevap yeni bir oturum açtı (allocate a new session), FortiGate’in kendisine gelen trafik olarak (via root) kural aradı ve bulamadı. Relay adresini sunucunun cevap verdiği adres (192.168.1.15) yapınca istemci adresini aldı. Relay adresi bu yüzden isteğin gideceği değil, cevabın geleceği adres olmalıdır; birden çok adresi olan bir sunucuda hangisi olduğunu paket yakalamada teklifin kaynak adresinden görürsünüz.

Relay Bir Süre Çalışıp Sonra Durursa: Eski Oturum

Ölçümde yanıltıcı bir ara durum da çıktı. Relay adresini .15’ten .16’ya çevirdikten hemen sonra ilk deneme çalıştı: istemci adres aldı ve izde cevap Find an existing session, ... reply direction satırıyla geçti. Sebep, .15’e giden önceki isteklerin açtığı oturumun hâlâ yaşamasıydı. Oturum listesinde o satır görünüyordu:

hook=out dir=org act=noop 10.34.70.1:67->192.168.1.15:67(0.0.0.0:0)
hook=in dir=reply act=noop 192.168.1.15:67->10.34.70.1:67(0.0.0.0:0)

Oturumları diagnose sys session filter dport 67 ve diagnose sys session clear ile temizleyince aynı ayar yukarıdaki policy 0 düşüşünü verdi. Yani relay adresini değiştirdikten sonra yapılan tek bir başarılı deneme yeterli değildir; eski oturumlar temizlenip yeniden denenir.

Örnekteki sınır kapısında görevli eski bir defter sayfasına bakarak tanıdık imzalı cevabı bir süre daha kabul eder; sayfa kapanınca aynı cevap kapıda kalır.

FortiGate DHCP Sorun Giderme: Dört Komut

Lab’da işe yarayan teşhis sırası:

1. Kira listesi: execute dhcp lease-list depo. Hangi MAC’in hangi adresi aldığını, kiranın ne zaman bittiğini ve Conflicted leases altında kenara konan adresleri gösterir.
2. Kablodaki akış: istemci tarafında DHCP paketlerini yakalayın. Teklif geliyor mu, hangi DNS ile geliyor, NACK var mı; formdan değil teklifin kendisinden okunur.
3. Relay: diagnose debug application dhcprelay -1 ve diagnose debug enable. İsteğin iletildiğini ve cevabın gelip gelmediğini ayrı satırlarda gösterir. İşiniz bitince diagnose debug disable ile kapatın.
4. Cevap gelmiyorsa: diagnose debug flow ile sunucunun adresini süzün. iprope_in_check() check failed on policy 0 satırı, cevabın relay adresinden başka bir adresten geldiğini söyler.

İstemci hiç adres alamazsa kendine 169.254 ile başlayan bir adres verir; lab’daki istemci de ilk denemede, FortiGate’in yoklaması sürerken bu adresi aldı. Bunun ne anlama geldiğini DHCP nedir yazımızda anlattık.

Doğrulama: FortiGate’in DHCP Düzeni Doğru mu?

Ayar bittiğinde beş şey kontrol edilir; her biri yukarıda lab’da ölçüldü:

1. Aralık plandaki blokta. show system dhcp server çıktısında start-ip ve end-ip statik bloğun dışındadır.
2. DNS listesi doğru. İstemciye giden teklifte AD ağında yalnız iç DNS, misafir ağında iç DNS dışında bir çözümleyici görünür.
3. Rezervasyonlar tutuyor. Rezervasyonlu cihaz yenilemede ayrılmış adresi alır; kira listesinde o adresle görünür.
4. Relay cevap alıyor. dhcprelay izinde got a DHCPOFFER ve sending dhcp reply satırları görünür; eski oturumlar temizlendikten sonra da.
5. Çakışan adres yok. Kira listesinde Conflicted leases boştur; doluysa aralıkta statik bir cihaz vardır.

Sonuç: FortiGate DHCP’de Dağıtıcıyı ve DNS Listesini Siz Seçersiniz

FortiGate’in DHCP sunucusu her iç arayüzde ayrı çalışır ve formu açtığınız anda ağın tamamını dağıtmaya hazırdır. Doğru düzende AD istemcileri adresi kurumun sunucusundan relay üzerinden alır, AD dışındaki ağlara FortiGate dağıtır, aralık statik bloğun dışında durur ve her ağa yalnız ulaşabildiği DNS verilir. Lab’da dört şey beklenenden farklı çıktı:

1. Fabrika ayarı istemcilere internetteki ikincil DNS’i de verdi. Same as System DNS, FortiGate’in kendi listesinin tamamını dağıtıyor.
2. Misafire giden iç DNS kurala takıldı. Misafir ağından iç DNS’e kural olmadığı için soru policy 0 ile düştü.
3. Relay cevabı sunucunun başka adresinden gelince düştü. FortiGate cevabı yalnız relay adresine açılan oturumun dönüş yönü olarak kabul etti.
4. Eski bir oturum yanlış ayarı birkaç dakika çalışır gösterdi. Relay adresi değiştikten sonraki ilk başarılı deneme, önceki adrese açılmış oturumdan geldi.

Örnekteki sınır kapısında görevli bölmeyi göstermeden önce sıraya bakar, ama sahanın planını çizen görevli değildir. Dilekçeyi kime gönderdiğini de deftere o yazar; cevabı ancak o imzayla kabul eder. Sıradaki adım iç ağ bölümlerini kurallar için gruplamak, yani rehberin 11. adımı; açılış listesinin kalanı 20 adımlık kontrol listesinde duruyor.

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