FortiGate Firewall WAN Ayarı: Statik IP, DHCP ve PPPoE

FortiGate Firewall WAN ayarı, internete bakan arayüze servis sağlayıcının hattını tanıtır ve Network → Interfaces ekranında, arayüzün rolü WAN seçilerek yapılır. CISA, NSA ve NIST’in tarif ettiği düzende bu arayüzde yönetim servisi açık olmaz, internetten gelip kaynağında özel bir adres taşıyan paket kapıda düşer ve hattın verdiği DNS iç DNS’in yerine geçmez.

Adres kipini hattın kendisi belirler: statik IP, DHCP ya da PPPoE. Bu yazı FortiGate Firewall yapılandırma rehberimizin 8. adımıdır. Lab’da üç kipi de aynı arayüzde ölçtüm. En çarpıcı bulgu kaynak doğrulamasında çıktı: fabrika ayarındaki FortiGate, internetten gelip iç ağdan geliyormuş gibi davranan bir paketi geçirdi ve paket sanal IP üzerinden iç web sunucusuna ulaştı. Yani sahte kaynaklı paketi kapıda durduran koruma fabrika ayarında gelmiyor.

Örnekteki sınır kapısında dış bariyer ana yola açılır ve bariyerdeki memur ana yoldan yalnız yükü içeri alır. Kulübenin yönetim kapısı ana yola açılmaz. Belgesinde “içerideki şehirden çıktım” yazan bir araç ana yoldan gelirse geri çevrilir. Ana yolun alçak geçidine sığmayacak yük daha kapıda ayarlanır.

FortiGate’te ana yol servis sağlayıcının hattı, dış bariyer WAN arayüzü, araç belgesindeki çıkış yeri paketin kaynak adresi, alçak geçit de hattın paket boyutu sınırıdır.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde her yeni hatta adresin, rotanın ve DNS’in nereden geldiğini ve dışarıdan kapıya neyin yaklaşabildiğini nasıl kontrol ettiğimizi anlatır.

FortiGate WAN Arayüzü Nedir? Fabrika Ayarında Ne Geliyor?

WAN arayüzü, FortiGate’in internete bakan bacağıdır. Network → Interfaces ekranında arayüz düzenlenirken Role satırında LAN, WAN, DMZ ve Undefined seçenekleri durur. Lab cihazımda dış ağ portu port3, takma adı dis-ag. Ölçüme başlamadan önce arayüzün ve cihazın ilgili satırları şöyleydi:

config system interface
    edit "port3"
...
        set mode static
...
        set ip 203.0.113.1 255.255.255.0
        set allowaccess ping
...
        set src-check enable
...
        set role wan
...
        set dns-server-override enable
...
config system settings
...
    set strict-src-check disable

Satırlar sırayla şunu söylüyor:

1. mode static, ip: adres elle yazılmış; servis sağlayıcının verdiği 203.0.113.1/24.
2. allowaccess ping: arayüzde açık olan tek yönetim yolu ping.
3. src-check enable ve strict-src-check disable: kaynak adres doğrulaması açık, ama fabrika ayarındaki feasible path (uygun yol) kipinde. Bu ikilinin ne yaptığını aşağıda ölçtüm.
4. dns-server-override enable: hat DHCP ya da PPPoE ile DNS verirse, o DNS iç DNS’in önüne geçer. Statik kipte etkisizdir, kip değişince devreye girer.

Rota tablosunda varsayılan rota dış hattaki ağ geçidini gösteriyordu:

S*      0.0.0.0/0 [10/0] via 203.0.113.80, port3, [1/0]
...
C       10.34.30.0/24 is directly connected, port2
...
C       203.0.113.0/24 is directly connected, port3

0.0.0.0/0 satırı “bilinen ağların dışındaki her adres için dış hatta git” der. Bu satır internete çıkışı açar; aynı satırın kaynak doğrulamasını nasıl etkisiz bıraktığı yazının en önemli ölçümü oldu.

FortiGate WAN Arayüzü Nasıl Olmalı?

WAN arayüzünde yönetim servisi açık olmaz; HTTPS, HTTP, SSH ve SNMP işaretsiz kalır. İnternetten gelip kaynağında özel bir adres taşıyan paket kapıda düşer. Kurumda iç DNS varsa hattın DNS’i onun yerine geçmez. Adres kipi hattın sözleşmesine göre seçilir.

Bu düzeni beş kaynak birlikte tarif ediyor:

1. CISA, BOD 23-02 (13 Haziran 2023): router, switch, firewall ve VPN cihazlarının yönetim arayüzü internetten erişilebilir bırakılmaz. Böyle bir arayüz bulunduktan sonra 14 gün içinde internetten kaldırılır ya da arayüzün kendisinden ayrı bir erişim denetim noktasının arkasına alınır. Yönerge ABD federal kurumlarını bağlıyor; CISA herkese uygulamayı öneriyor.
2. NSA, Network Infrastructure Security Guidance (Mart 2022 sürümü), bölüm 7.4 ve 8.2: yönetim servislerine yalnız yöneticilerin sistemleri bağlanır. Çevre cihazının dış arayüzlerinde kaynak adres doğrulaması (uRPF) açılır; iç arayüzlerde ve yolların simetrik olmadığı yerde açılmaz, çünkü gerçek paketi de atabilir.
3. NIST, SP 800-41 Rev. 1 (Eylül 2009), bölüm 4.1.1: internetten gelen ve kaynağı RFC 1918 özel aralıklarında (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) olan trafik çevrede düşürülür. Firewall’un kendisine gelen trafik de, firewall o servisi dışarıya vermiyorsa engellenir.
4. RFC 3704 (BCP 84, Mart 2004), bölüm 2.2 ve 2.3: kaynak doğrulamasının iki kipini tanımlar. Strict RPF (sıkı kip) yalnız yolların simetrik olduğu yerde uygulanabilir ve RFC’ye göre bu durum, servis sağlayıcıya bakan kenar arayüzlerinde yaygındır.
5. RFC 2516 (Şubat 1999), bölüm 7: PPPoE’de 1492 bayttan büyük bir MRU pazarlık edilemez. Hattın paket sınırı budur.

Kurumun hattı hangi kiple geliyorsa ayar ona göre yapılır. Üç kipin farkı şöyle:

Kurumsal hatlarda sabit adres çoğu zaman statik IP ile gelir; modem köprü modundaysa oturumu firewall kurar ve kip PPPoE olur. PPPoE’nin nasıl çalıştığını ve modemin köprü modunu PPPoE nedir yazımızda, hat seçeneklerini kurumsal internet hattı yazımızda anlattık. Tablonun son iki satırı, DHCP ve PPPoE’nin hattan DNS de getirdiğini gösteriyor; bunun bedelini DHCP bölümünde ölçtüm.

İnternetten Gelen Paket “İçeriden Geliyorum” Derse Ne Olur?

Bir zarfın arkasındaki gönderen adresini mektubu gönderen kişi yazar. Postane o adresi doğrulamaz; zarfın arkasına başka bir şehrin adını yazıp mektubu bulunduğunuz yerden atabilirsiniz. İnternetteki paketler de böyledir: kaynak adresini paketi gönderen bilgisayar kendisi yazar ve yoldaki cihazlar onu doğrulamak zorunda değildir. Bu yüzden internetten gelen bir paket, kaynak adresine iç ağdaki bir bilgisayarın adresini yazabilir.

Kapının bunu nasıl yakaladığını dört parça anlatıyor:

1. Kaynak adres aracın belgesindeki çıkış yeridir. Belgeyi sürücü kendisi doldurur.
2. Yönlendirme tablosu kulübedeki yön tabelalarıdır: hangi yere hangi bariyerden gidilir.
3. Varsayılan rota en alttaki “Geri kalan her yön: dış bariyer” tabelasıdır.
4. Kaynak adres doğrulaması memurun belgeye bakıp “bu yerden çıkan bir araç bu bariyere gelebilir mi?” diye tabelalara bakmasıdır. Adı İngilizcede reverse path forwarding, kısaca RPF; NSA’nın deyişiyle uRPF.

Örnekteki sınır kapısında dış bariyere bir araç gelir ve belgesinde “içerideki şehirden çıktım” yazar. Sonucu, memurun tabelalara nasıl baktığı belirler:

1. Feasible path (uygun yol kipi), FortiGate’in fabrika ayarı: memur o şehre dış bariyerden giden herhangi bir tabela var mı diye bakar. “Geri kalan her yön” tabelası her yeri kapsadığı için cevap evettir ve araç geçer. Ad RFC 3704’ten geliyor.
2. Strict RPF (sıkı kip): memur yalnız o şehre giden en iyi tabelaya bakar. En iyi yol iç bariyerden geçiyorsa araç dış bariyere gelemezdi; belge sahtedir ve araç geri çevrilir.
3. Ret kuralı: bariyerin önündeki levha tabelalara hiç bakmaz, yalnız belgeyi okur: “Çıkış yeri içerideki bir şehirse bu bariyerden geçemez.”

Kaynak doğrulamasının kazancı iki tanedir:

1. Dışarıdan gelen paket iç ağdaki bir adresin kılığına giremez. Lab’da kılık değiştiren paket iç web sunucusuna ulaştı ve sunucu cevabını internete değil, iç ağdaki 10.34.30.50’ye göndermeye çalıştı.
2. Log yanıltılamaz. Sahte paketin log satırında bile kaynak olarak srcip=10.34.30.50 yazıyor; doğrulaması olmayan bir ağda bu satır olayı inceleyen kişiyi içerideki masum bir bilgisayara yönlendirir.

Strict RPF’in bedeli, yolları simetrik olmayan ağdır. Bir adrese giden en iyi yol başka bir arayüzdeyse, o adresten bu arayüze gelen gerçek paket de düşer; NSA’nın uRPF’i iç arayüzlerde ve asimetrik yönlendirmede önermemesinin sebebi budur. FortiOS 7.0’da arayüz başına yalnız doğrulamayı açıp kapatabiliyorsunuz (set src-check enable ya da disable); strict RPF ise bütün arayüzler için birlikte açılır. Yani sıkı kipi açma kararı yalnız WAN’ı değil, cihazdaki bütün arayüzleri ilgilendirir.

FortiGate’te Statik IP ile WAN Ayarı

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

1. Servis sağlayıcının verdiği adres, maske ve ağ geçidi. Lab’da 203.0.113.1/24, ağ geçidi 203.0.113.80.
2. İç DNS sunucusu. Lab’da dc01 (192.168.1.10); ayarını DNS ayarı yazımızda anlattık.
3. Yönetim erişimi yönetim ağında. Lab’da 192.168.10.0/24; neden yalnız orada olduğunu yönetim erişimi yazımızda anlattık.

Ayar Network → Interfaces → port3 → Edit yolunda yapılır:

1. Alias: portun görünen adı. Lab’da dis-ag.
2. Role: WAN. Bu rolde formda tahmini hat hızının yazıldığı Estimated bandwidth alanları duruyor.
3. Addressing mode: Manual.
4. IP/Netmask: servis sağlayıcının verdiği adres. Lab’da 203.0.113.1/255.255.255.0.
5. Administrative Access: HTTPS, HTTP, SSH ve SNMP işaretsiz. Lab’da hattın ucundan erişim denenebilsin diye yalnız PING işaretli; ona da ihtiyacınız yoksa hiçbirini işaretlemeyin.

Aynı arayüzün komut satırındaki karşılığı:

config system interface
    edit "port3"
        set ip 203.0.113.1 255.255.255.0
        set allowaccess ping
        set alias "dis-ag"
        set role wan
    next
end

Statik kipte FortiGate hattan başka hiçbir şey öğrenmez. Varsayılan rota Network → Static Routes altında elle yazılır; lab’daki rota şu:

config router static
    edit 1
        set gateway 203.0.113.80
        set device "port3"
        set comment "Varsayilan rota, birincil hat"
    next
end

Rotanın nasıl yazıldığını FortiGate Firewall statik rota yazımızda, tabloda nasıl seçildiğini yönlendirme tablosu nedir yazımızda anlattık. Statik kipin iyi yanı, hiçbir şeyin kendiliğinden değişmemesidir. Kötü yanı da aynıdır: servis sağlayıcı ağ geçidini değiştirirse FortiGate bunu kendisi öğrenemez.

Yönetim kutularının boş olduğunu dışarıdan da sınadım. Dış ağdaki makineden (203.0.113.80) WAN adresinin yönetim portlarını taradım; FortiGate yalnız ping’e cevap verdi:

PORT      STATE    SERVICE
22/tcp    filtered ssh
23/tcp    filtered telnet
80/tcp    filtered http
443/tcp   filtered https
541/tcp   filtered uucp-rlogin
20443/tcp filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 1.33 seconds
2 packets transmitted, 2 received, 0% packet loss, time 1004ms

Listedeki 20443, lab cihazının yönetim portu; 541 de FortiGate’in merkezi yönetim bağlantısının portu. Hepsi filtered, yani dışarıdan bakan birine kapının arkasında yönetim servisi olduğunu bile söylemiyor.

FortiGate’te DHCP ile WAN Ayarı

Hat adresini DHCP ile veriyorsa Addressing mode satırında DHCP seçilir. Form üç seçenek getirir ve üçü de fabrika ayarında açık ya da dolu gelir:

1. Retrieve default gateway from server: varsayılan rota, DHCP sunucusunun verdiği ağ geçidinden yazılır. Açık kalır.
2. Distance: bu rotanın mesafesi, fabrika ayarında 5. Birden çok rota olduğunda küçük mesafeli olan seçilir.
3. Override internal DNS: sunucunun verdiği DNS, sistemin DNS’inin yerine geçer. Kurumda iç DNS varsa kapatılır.

Aynı ayarın komut satırındaki karşılığı:

config system interface
    edit "port3"
        set mode dhcp
        set dns-server-override disable
    next
end

defaultgw enable ve distance 5 fabrika değerleri olduğu için show çıktısında görünmez. Kaydettikten sonra arayüz lab’daki DHCP sunucusunun aralığından bir adres aldı, rota tablosuna da varsayılan rota girdi:

IP=203.0.113.148->203.0.113.148/255.255.255.0 index=5 devname=port3
...
S*      0.0.0.0/0 [5/0] via 203.0.113.80, port3, [1/0]

Elle yazılmış rota 1 ([10/0]) bu sırada tablodan çekildi; mesafesi küçük olan DHCP rotası geçti. Statik kipten DHCP’ye geçerken eski varsayılan rotayı silmeseniz de çalışır, ama tabloya bakan biri iki rotadan hangisinin geçerli olduğunu mesafeye bakarak okur.

Override internal DNS: Hattın DNS’i İç Adları Kaybettiriyor

Bu seçeneğin bedelini fabrika ayarında, yani açıkken ölçtüm. Sistemin DNS ayarında iç DNS (192.168.1.10) ve ikincil olarak 8.8.8.8 yazılıydı; DHCP sunucusu da DNS olarak 203.0.113.53’ü veriyordu. FortiGate’in hangi sunuculara sorduğuna diagnose test application dnsproxy 3 ile baktım ve iç bir adı çözdürdüm. Satır başlarındaki saat, oturumda açık olan konsol zaman damgasından geliyor:

Unable to resolve hostname.
...
2026-10-01 12:31:31 203.0.113.53:53 vrf=0 tz=0 encrypt=none req=26 to=0 res=26 rt=448 ready=1 timer=0 probe=0 failure=0 last_failed=0
2026-10-01 12:31:31 192.168.1.10:53 vrf=0 tz=0 encrypt=none req=0 to=0 res=0 rt=0 ready=1 timer=0 probe=0 failure=0 last_failed=0
2026-10-01 12:31:31 8.8.8.8:53 vrf=0 tz=0 encrypt=none req=0 to=0 res=0 rt=0 ready=1 timer=0 probe=0 failure=0 last_failed=0

Yapılandırmada adı bile geçmeyen hat DNS’i listenin başına geçmişti ve bütün sorular ona gidiyordu; iç DNS’e sıfır istek. Hattın DNS’inin kaydında soru da cevap da görünüyordu:

Oct  1 09:31:29 dnsmasq[3085]: query[A] dc01.ad.sistemkusu.com from 203.0.113.148
Oct  1 09:31:29 dnsmasq[3085]: config dc01.ad.sistemkusu.com is NXDOMAIN

Servis sağlayıcı kurumun iç adlarını bilmediği için “böyle bir ad yok” dedi. Lab’daki taklit DNS bu cevabı veriyor; gerçek bir Public DNS’in (internetteki herkese açık DNS sunucusu) aynı soruya iç adı bambaşka bir adrese çözebildiğini DNS ayarı yazımızda ölçtük. Seçeneği kapatınca liste aynı anda iç DNS’e döndü ve ad çözüldü:

2026-10-01 12:31:55 192.168.1.10:53 vrf=0 tz=0 encrypt=none req=4 to=0 res=4 rt=5 ready=1 timer=0 probe=0 failure=0 last_failed=0
2026-10-01 12:31:55 8.8.8.8:53 vrf=0 tz=0 encrypt=none req=0 to=0 res=0 rt=0 ready=1 timer=0 probe=0 failure=0 last_failed=0
...
PING dc01.ad.sistemkusu.com (192.168.1.10): 56 data bytes
64 bytes from 192.168.1.10: icmp_seq=0 ttl=127 time=1.1 ms

Ölçümde bir tuzak daha çıktı. Kipi DHCP’ye çevirdikten iki dakika sonra listeye baktığımda hattın DNS’i orada yoktu; FortiGate iç DNS’e sormaya devam ediyordu. Hattın DNS’i ancak DNS servisini yeniden başlattığımda (diagnose test application dnsproxy 99) listenin başına geçti. Yani seçenek açıkken ayarı kaydedip hemen listeye bakarsanız her şeyi yolunda görebilirsiniz; sorun servis bir sonraki kez başladığında ortaya çıkar. Kapatmanın etkisi ise anında görüldü: düzeltmenin tuttuğunu kaydeder kaydetmez listeden doğrulayabilirsiniz.

Örnekteki sınır kapısında bu, ana yolun idaresinin kapıya kendi ülke atlasını gönderip duvardaki bölge haritasını kaldırmasıdır: büyük yollar bulunur, kapının yanındaki sokaklar kaybolur. Kurumda iç DNS varsa WAN arayüzünde Override internal DNS kapatılır; aynı seçenek PPPoE kipinde de vardır.

FortiGate’te PPPoE ile WAN Ayarı

Lab cihazımda WAN arayüzünün adresleme kipi listesinde PPPoE yoktu, yalnız Manual ve DHCP duruyordu. Kipi komut satırından verdim:

config system interface
    edit "port3"
        set mode pppoe
        set username "abonelik_kullanici_adiniz"
        set password <parola>
    next
end

username ve password, servis sağlayıcının hat için verdiği PPPoE kullanıcı adı ve parolasıdır. Modem kendisi bağlanıyorsa bu ikisi modemin ayarında durur. Modem köprü modundaysa oturumu FortiGate kurar ve ikisi FortiGate’e yazılır. Lab’da servis sağlayıcıyı taklit eden makinede (ntp01) bir PPPoE sunucusu çalışıyor ve kullanıcıyı o sunucuya ben tanımladım. Adını, sizin hattınızda bu alana neyin yazılacağını göstersin diye abonelik_kullanici_adiniz koydum. Parola blokta <parola> diye gizlendi.

Servis sağlayıcı tarafındaki paket kaydında FortiGate’in keşfi ve kimlik doğrulaması duruyordu. Keşfin dört paketi 1,4 milisaniyede bitti. İlk paketten (PADI) CHAP onayına kadar 3 saniye geçti:

03:47:53.211172 00:0c:29:d1:72:41 > ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 60: PPPoE PADI [AC-Name] [Host-Uniq "10165ac0"] [Service-Name]
...
03:47:53.212556 00:0c:29:a0:71:b8 > 00:0c:29:d1:72:41, ethertype PPPoE D (0x8863), length 44: PPPoE PADS [ses 0x1] [Service-Name "internet"] [Host-Uniq "10165ac0"]
...
03:47:56.221629 00:0c:29:d1:72:41 > 00:0c:29:a0:71:b8, ethertype PPPoE S (0x8864), length 68: PPPoE  [ses 0x1] CHAP (0xc223), length 48: CHAP, Response (0x02), id 200, Value af0e253c02e8f06e208e5f63ed38a37c, Name abonelik_kullanici_adiniz
03:47:56.222300 00:0c:29:a0:71:b8 > 00:0c:29:d1:72:41, ethertype PPPoE S (0x8864), length 40: PPPoE  [ses 0x1] CHAP (0xc223), length 20: CHAP, Success (0x03), id 200, Msg Access granted

Sondan ikinci satırda FortiGate kullanıcı adını açık gönderiyor, parolayı göndermiyor: Value alanı, parolayla sunucunun gönderdiği rastgele sayıdan hesaplanmış bir hash.

Kayıttaki saatler servis sağlayıcıyı taklit eden makinenin UTC saatidir. Keşif ve oturum paketlerinin ne olduğunu PPPoE nedir yazımızda paket paket anlattık. FortiGate yeni bir arayüz açmış ve rotayı oturumun karşı ucuna yazmıştı:

IP=100.64.10.30->100.64.0.1/255.255.255.255 index=20 devname=ppp1
if=ppp1 family=00 type=512 index=20 mtu=1492 link=5 master=0
...
S*      0.0.0.0/0 [5/0] via 100.64.0.1, ppp1, [1/0]

Adres ppp1 arayüzüne geldi, MTU kendiliğinden 1492 oldu ve varsayılan rota yine 5 mesafeyle yazıldı. İlk satırda iki adres var:

1. 100.64.10.30, servis sağlayıcının oturum kurulunca FortiGate’e verdiği adres. Hattın bizim ucu budur ve NAT’tan çıkan trafik internete bu adresle gider.
2. 100.64.0.1, oturumun öbür ucu: servis sağlayıcının PPPoE oturumlarını karşılayan yönlendiricisi. FortiGate varsayılan rotayı ona yazdı, aşağıdaki ekranda da Default gateway olarak görünüyor. Lab’da bu adres, ntp01’deki PPPoE sunucusunun kendi ucu.

İki adresin maskesi 255.255.255.255, yani ikisi aynı alt ağda değil. PPP iki uçlu bir bağlantıdır: hattın her ucunda tek bir adres durur ve karşı uç kendiliğinden ağ geçidi olur.

Kip PPPoE olunca arayüz de PPPoE seçeneğini göstermeye başladı:

Donanım modellerinde bu liste farklı olabilir; seçenek arayüzde yoksa yol komut satırıdır.

PPPoE’de MSS Düzeltmesi: 1460 Giriyor, 1452 Çıkıyor

PPPoE hattının MTU’su 1492’dir, iç ağınki 1500. PPPoE yazımızda bu farkın büyük paketleri yolda takılttığını ve çözümün MSS düzeltmesi olduğunu anlattık. FortiGate’in bunu kendiliğinden yapıp yapmadığını ölçtüm. İç ağdaki makineden (10.34.30.10) bir web isteği attım ve TCP bağlantısının ilk paketini iki yerde yakaladım: iç ağdan FortiGate’e girerken ve PPPoE hattının servis sağlayıcı ucunda:

10.34.30.10.57158 > 203.0.113.66.80: Flags [S], ... seq 2776555726, win 64240, options [mss 1460,sackOK,...
100.64.10.30.57158 > 203.0.113.66.80: Flags [S], ... seq 2776555726, win 64240, options [mss 1452,sackOK,...

İki satır aynı paket: sıra numarası (seq) ve kaynak portu aynı, yalnız kaynak adres NAT ile hattın adresine çevrilmiş. İç ağdaki bilgisayar, kendi 1500 baytlık MTU’suna göre 1460 ilan etti. Paket PPPoE hattına geçerken FortiGate’te 1452’ye düzeltildi.

Karşı taraf bu bağlantıda 1452 bayttan büyük parça göndermez ve paketler hatta sığar. Bu düzeltme için hiçbir ayar yazmadım; arayüzde tcp-mss 0, yani fabrika değeri duruyor.

Ölçümden sonra port3’ü statik kipe ve 203.0.113.1/24 adresine geri aldım. Aşağıdaki ölçümler bu düzende yapıldı.

FortiGate’te Sahte Kaynaklı Paketi Kapıda Durdurmak

Kaynak doğrulamasını sınamak için dış ağdaki makineden, kaynak adresine iç ağdaki 10.34.30.50’yi yazan bir bağlantı isteği gönderdim. Hedef 203.0.113.10: iç web sunucusunu (10.34.30.20) dışarıya açan sanal IP. Kural 3 bu sanal IP’ye dışarıdan HTTP’yi her kaynağa açıyor; sanal IP’nin ne olduğunu FortiGate kullanım rehberimizde anlattık. Komut, servis sağlayıcıyı taklit eden ad alanında çalıştı:

sudo ip netns exec dis nping --tcp -p 80 --flags syn -S 10.34.30.50 -c 2 203.0.113.10

Komutun parçaları:

1. ip netns exec dis: komutu lab’daki dış ağ makinesinin ad alanında çalıştırır.
2. --tcp -p 80 --flags syn: 80 numaralı porta bir TCP bağlantısının ilk paketini (SYN) gönderir.
3. -S 10.34.30.50: paketin kaynak adresine iç ağdaki bir adresi yazar. Bu adres iç ağda kullanılmıyor.
4. -c 2 203.0.113.10: sanal IP’ye iki paket gönderir.

FortiGate’te paketin yolunu diagnose debug flow filter saddr 10.34.30.50 ile süzüp diagnose debug flow trace start 20 ve diagnose debug enable ile izledim. Her denemeden önce dış ağdan gerçek kaynakla (203.0.113.80) aynı adrese bir istek attım; o istek her seferinde 200 aldı. Bu kontrol, sahte paket düştüğünde hattın çalıştığını ve paketi düşürenin ayar olduğunu gösteriyordu.

Fabrika Ayarında: Sahte Paket İç Sunucuya Ulaştı

FortiGate paketi dış hattan aldı, sanal IP’yi iç sunucuya çevirdi ve kural 3’ten geçirdi. Satırların başındaki tarih ve iz numarası kısaltıldı:

... func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 10.34.30.50:32430->203.0.113.10:80) tun_id=0.0.0.0 from port3. flag [S], seq 4002888471, ack 0, win 1480"
... func=init_ip_session_common line=6024 msg="allocate a new session-0003eec2, tun_id=0.0.0.0"
... func=get_new_addr line=1221 msg="find DNAT: IP-10.34.30.20, port-80"
... func=fw_pre_route_handler line=178 msg="VIP-10.34.30.20:80, outdev-port3"
... func=__ip_session_run_tuple line=3484 msg="DNAT 203.0.113.10:80->10.34.30.20:80"
... func=vf_ip_route_input_common line=2605 msg="find a route: flag=00000000 gw-10.34.30.20 via port2"
... func=fw_forward_handler line=881 msg="Allowed by Policy-3:"

İç ağdaki yakalamada paket sunucuya ulaşmıştı ve sunucu cevabı vermek için iç ağdaki 10.34.30.50’yi arıyordu:

09:20:17.057845 IP 10.34.30.50.32430 > 10.34.30.20.80: Flags [S], seq 4002888471, win 1480, length 0
09:20:17.057889 ARP, Request who-has 10.34.30.50 tell 10.34.30.20, length 28

Fabrika ayarındaki feasible path kipinde FortiGate, 10.34.30.50’ye port3 üzerinden giden herhangi bir rota var mı diye bakıyor. Varsayılan rota port3’te ve her adresi kapsıyor; bu yüzden cevap evet ve paket geçiyor. Yani WAN’da varsayılan rota olan her FortiGate’te, fabrika ayarındaki kaynak doğrulaması dış hattan gelen hiçbir kaynağı geri çevirmez.

Strict RPF: Kaynağa Giden En İyi Yol Sorulur

Strict RPF (sıkı kip), FortiGate’in kaynağa giden en iyi rotaya bakmasıdır. Ayarın lab cihazımın arayüzünde alanı yok; System → Settings ekranında karşılığını bulamadım. Komutla verilir:

config system settings
    set strict-src-check enable
end

Aynı sahte paket bu kez kapıda düştü:

... func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 10.34.30.50:42615->203.0.113.10:80) tun_id=0.0.0.0 from port3. flag [S], seq 131730326, ack 0, win 1480"
...
... func=__ip_session_run_tuple line=3484 msg="DNAT 203.0.113.10:80->10.34.30.20:80"
... func=ip_route_input_slow line=2274 msg="reverse path check fail(by strict-src-check),drop"

10.34.30.50’ye en iyi yol port2’den, iç ağdan geçiyor; paket ise port3’ten geldi. İç ağdaki yakalamada bu kez sahte paketten hiçbir iz yoktu ve gerçek istek yine 200 aldı. Strict RPF, gerçek trafiğe dokunmadan sahte paketi kapıda durdurdu.

Strict RPF’in iki sınırını da ölçtüm:

1. İç ağda kullanılmayan bir özel adresi geçirir. Kaynağı 172.16.5.5 olan sahte paket strict RPF’te de kural 3’ten geçti (Allowed by Policy-3). Bu adrese en iyi yol varsayılan rota, yani yine port3; FortiGate için bu adresin dış hattan gelmesinde tuhaf bir şey yok.
2. Yolu başka arayüzde olan gerçek bir adresi düşürür. Lab’da 8.8.8.8’e giden rota, DNS yazısındaki ölçüm için yönetim ağından (port1) geçiyor. Kaynağı 8.8.8.8 olan paket port3’ten geldiğinde strict RPF’te reverse path check fail(by strict-src-check),drop ile düştü; fabrika ayarında aynı paket kural 3’ten geçti. Bir adrese giden yolu internet hattından başka bir arayüze çeken her kurum, strict RPF’te bu adresten gelen gerçek trafiği kaybeder.

Bu yüzden strict RPF tek başına NIST’in kuralını karşılamıyor: iç ağda kullanılan adresleri korur, kullanılmayan özel aralıkları geçirir. Tek hatlı, yolları simetrik bir kurumda strict RPF açılır; iki hat, VPN ya da bir adrese özel yol varsa önce bu yolların her iki yönü kontrol edilir. Özel aralıkların tamamı için de ayrı bir ret kuralı yazılır.

İçeride Kullanılmayan Özel Adresler: Ret Kuralı ve match-vip

Ret kuralından önce iki şey hazır olmalı:

1. Özel adres grubu. RFC 1918’in üç aralığı ayrı adres nesnesi olarak açılıp ozel-adresler grubunda toplanır; nesnelerin nasıl açıldığını adres nesneleri yazımızda anlattık.
2. İç arayüzlerin listesi. Lab’da port2 (ic-ag), ic-bolumler bölgesi ve dmz.

Kural Policy & Objects → Firewall Policy → Create New yolunda açılır:

1. Name: kuralın işini söyleyen ad. Lab’da Internetten ozel kaynak.
2. Incoming Interface: WAN arayüzü, dis-ag (port3).
3. Outgoing Interface: iç arayüzlerin hepsi.
4. Source: ozel-adresler.
5. Destination: all, Schedule: always, Service: ALL.
6. Action: DENY. DENY seçilince form kısalıyor; NAT ve güvenlik profili alanları kalkıyor, yerine Log Violation Traffic geliyor. Açık kalır.

Kural listenin en üstüne alınır. Kaydın ve adres grubunun komut satırındaki karşılığı, cihazın kendi çıktısından:

config firewall address
    edit "ozel-10"
        set comment "RFC 1918"
        set subnet 10.0.0.0 255.0.0.0
    next
    edit "ozel-172"
        set comment "RFC 1918"
        set subnet 172.16.0.0 255.240.0.0
    next
    edit "ozel-192"
        set comment "RFC 1918"
        set subnet 192.168.0.0 255.255.0.0
    next
end
config firewall addrgrp
    edit "ozel-adresler"
        set member "ozel-10" "ozel-172" "ozel-192"
        set comment "Internetten kaynak adresi olarak gelemez (RFC 1918)"
    next
end
config firewall policy
    edit 9
        set name "Internetten ozel kaynak"
        set srcintf "port3"
        set dstintf "port2" "ic-bolumler" "dmz"
        set srcaddr "ozel-adresler"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set match-vip enable
        set comments "Dis hattan gelen, kaynagi ozel adres olan trafik (NIST SP 800-41r1 4.1.1)"
    next
end

Kuralı listenin en üstüne config firewall policy altında move 9 before 2 komutuyla aldım; lab’da en üstteki kural 2’ydi.

Bloktaki set match-vip enable satırının formda alanı yok ve bu kuralın asıl işini o yapıyor. Kuralı önce bu satır olmadan kurdum ve kaynağı 172.16.5.5 olan sahte paketi gönderdim. Kural listenin en üstünde olduğu hâlde paket ondan geçmedi, alttaki kural 3’ten geçti:

... func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 172.16.5.5:56390->203.0.113.10:80) tun_id=0.0.0.0 from port3. flag [S], seq 2916682987, ack 0, win 1480"
...
... func=fw_forward_handler line=881 msg="Allowed by Policy-3:"

FortiGate’te hedefi all olan bir ret kuralı, fabrika ayarında sanal IP’ye giden trafiğe bakmıyor. match-vip enable ile kural bu trafiği de görür. Satırı ekleyince iki sahte kaynak da reddedildi:

... func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 172.16.5.5:24962->203.0.113.10:80) tun_id=0.0.0.0 from port3. flag [S], seq 745858760, ack 0, win 1480"
...
... func=fw_forward_handler line=719 msg="Denied by forward policy check (policy 9)"
... func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 10.34.30.50:44476->203.0.113.10:80) tun_id=0.0.0.0 from port3. flag [S], seq 2303848761, ack 0, win 1480"
...
... func=fw_forward_handler line=719 msg="Denied by forward policy check (policy 9)"

Ret logda da göründü; satırları kısalttım:

2 logs found.
1: date=2026-10-01 time=12:27:29 ... srcip=10.34.30.50 srcport=44476 srcintf="port3" srcintfrole="wan" dstip=203.0.113.10 dstport=80 dstintf="port2" ... action="deny" policyid=9 ... policyname="Internetten ozel kaynak" ... trandisp="dnat" tranip=10.34.30.20 tranport=80 ...
2: date=2026-10-01 time=12:27:05 ... srcip=172.16.5.5 srcport=24962 srcintf="port3" ... action="deny" policyid=9 ...

Gerçek kaynaklı istek bu kuralla da 200 aldı. Lab’da strict RPF ve kural 9 birlikte açık kaldı: biri iç ağda kullanılan adresleri tabelaya bakarak, öteki özel aralıkların tamamını belgeye bakarak yakalıyor.

Strict RPF’in Attığı Paket Logda Görünmez

Ret kuralının reddettiği paket logda policyid=9 ile durdu. Strict RPF’in düşürdüğü paket ise hiçbir yerde görünmedi. Lab’da varsayılan ret logu açıktı (log ayarları yazımızda açtık); buna rağmen strict RPF’in düşürdüğü 8.8.8.8 kaynaklı paket için trafik logu aradığımda cevap şuydu:

0 logs found.

Yani strict RPF’i açtıktan sonra bir bağlantı sessizce kopuyorsa logda iz aramak sizi bir yere götürmez. Önce diagnose debug flow ile o kaynağı izleyin. reverse path check fail(by strict-src-check) satırını görüyorsanız sebep yönlendirmedir: o adrese giden en iyi yol, paketin geldiği arayüzden geçmiyor.

Doğrulama: FortiGate’in WAN Kapısı Doğru mu?

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

1. Yönetim portları dışarıya kapalı. Dış ağdan yapılan taramada HTTPS, HTTP, SSH ve yönetim portu filtered döner.
2. Varsayılan rota doğru ağ geçidinde. get router info routing-table all çıktısında 0.0.0.0/0 satırı hattın ağ geçidini gösterir; DHCP ve PPPoE’de mesafesi 5’tir.
3. Hattın DNS’i listede yok. show system interface port3 çıktısında dns-server-override disable görünür ve diagnose test application dnsproxy 3 listesinde yalnız iç DNS sunucuları durur.
4. Sahte kaynak kapıda düşüyor. İç adresli sahte paket diagnose debug flow çıktısında reverse path check fail ya da Denied by forward policy check (policy 9) ile biter; gerçek kaynaklı istek cevap alır.
5. Ret kuralı sanal IP’yi de görüyor. show firewall policy 9 çıktısında set match-vip enable satırı vardır.
6. PPPoE ise paket boyutu doğru. ppp1 arayüzünün MTU’su 1492’dir ve iç ağdan çıkan SYN paketinin MSS değeri hatta 1452’ye iner.

Sonuç: FortiGate’in WAN Kapısı Belgeye de Bakmalı

FortiGate’in WAN arayüzü üç kiple çalışır ve her kip hattan farklı şeyler öğrenir. Statik IP hiçbir şey öğrenmez; DHCP ve PPPoE adresi, varsayılan rotayı ve DNS’i hattan alır. Doğru düzende WAN’da yönetim kutuları boştur, hattın DNS’i iç DNS’in yerine geçmez ve dış hattan gelip özel bir kaynak adresi taşıyan paket kapıda düşer. Lab’da beş şey beklenenden farklı çıktı:

1. Fabrika ayarındaki kaynak doğrulaması sahte paketi geçirdi. WAN’daki varsayılan rota her adresi kapsadığı için iç adresli paket sanal IP üzerinden iç sunucuya ulaştı.
2. Strict RPF iki yönden şaşırttı. İç ağda kullanılmayan 172.16.5.5’i geçirdi, yolu yönetim ağından geçen gerçek 8.8.8.8’i düşürdü; düşürdüğü paket logda hiç görünmedi.
3. En üstteki ret kuralı sanal IP’ye giden trafiği görmedi. Yalnız formda alanı olmayan match-vip enable ile gördü.
4. Hattın DNS’i geç devreye girdi. Kip DHCP’ye geçtiğinde değil, DNS servisi yeniden başladığında listenin başına geçti; seçeneği kapatmak ise anında etki etti.
5. PPPoE kipi arayüzde yoktu. Lab cihazında kip komut satırından verildi; FortiGate MTU’yu 1492’ye ve MSS’i 1452’ye kendisi indirdi.

Örnekteki sınır kapısında dış bariyerin memuru yalnız tabelalara bakarsa “Geri kalan her yön: dış bariyer” tabelası her sahte belgeyi haklı çıkarır. Memur belgedeki çıkış yerini de okumalı ve içerideki bir şehirden çıktığını söyleyen aracı ana yoldan içeri almamalıdır. 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