IPsec Lab Phase-1
Günümüz kurumsal ağ altyapılarında merkez ofis (HQ) ile şube (Branch) lokasyonlarının güvenli, stabil ve yönetilebilir bir şekilde birbirine bağlanması temel gereksinimlerden biridir. Bu ihtiyacı karşılamanın en yaygın ve güvenilir yollarından biri IPsec VPN teknolojisidir. Ancak teknoloji burada durmamış; IPsec’in üzerine inşa edilen SD-WAN mimarisi, hat yönetimini ve trafik optimizasyonunu bambaşka bir seviyeye taşımıştır.
Bu blog serisi, PNetLab üzerinde kurulan gerçekçi bir laboratuvar ortamında üç FortiGate cihazından oluşan bir topoloji üzerinde ilerleyecektir. Topolojimiz; bir merkez ofis (HQ), bir şube (Branch) ve aralarındaki bağlantıyı temsil eden bir ISP FortiGate’inden meydana gelmektedir. Yedeklilik ihtiyacı ise ayrı bir fiziksel hat yerine ISP firewall’u üzerinden farklı subnet’ler aracılığıyla sağlanacaktır.
Seri boyunca önce IPsec tüneli kurulacak, tünelin üzerinden lokasyonlar haberleştirilecek, ardından yedeklilik mekanizması devreye alınacak ve son olarak SD-WAN teknolojisine geçilerek trafik yönetimi modern bir çerçeveye oturtulacaktır. Her ders bir öncekinin üzerine katman katman inşa edileceğinden, seriyi baştan sona takip etmeniz tavsiye edilir.
PNetLab Topoloji Kurulumu ve Temel FortiGate Konfigürasyonu
Bu derste PNetLab üzerinde üç FortiGate cihazından oluşan temel topolojimizi kuracak ve her bir cihaz için ilk konfigürasyonları gerçekleştireceğiz. Sonraki derslerde IPsec ve SD-WAN yapılandırmalarına geçmeden önce sağlam bir temel oluşturmak bu adımın temel amacıdır.
Topoloji
Yapımız üç FortiGate cihazından oluşmaktadır.
HQ ve Branch birbirinden farklı subnet’lerde çalışan iki ayrı lokasyonu temsil etmektedir. ISP FortiGate’i ise bu iki lokasyon arasında konumlandırılarak aralarındaki bağlantıyı sağlayacaktır. İlerleyen derslerde bu üç cihaz arasında IPsec tüneli kurulacak ve ardından SD-WAN mimarisine geçilecektir.
Adım 1 — Yönetim IP Ataması (CLI)
PNetLab üzerinde cihazları ayağa kaldırdıktan sonra her bir FortiGate’e konsol üzerinden bağlanarak port1 arayüzüne statik yönetim IP’si atanır.
config system interfaces
edit port1
set mode static
set ip 192.168 .1 .( 205 (HQ) -206 (ISP) -207 (BRANCH)) / 24
endGUI arayüzüne erişebilmek için her bir FortiGate’in port1 arayüzü üzerinden Management Cloud’a bağlanması gerekmektedir. PNetLab içinde Management Cloud nodu eklenerek üç FortiGate’in port1'i bu node’a bağlanır.
Bağlantı tamamlandıktan sonra tarayıcı üzerinden ilgili yönetim IP’lerine HTTP ile erişilir:
Not: FortiOS 7.0.x sürümlerinde lisans olmaksızın HTTPS erişimi kısıtlanabilmektedir biz bu yapımızda 7.0.12 kullanacağız. Bu nedenle lab ortamında HTTP üzerinden bağlantı tercih edilmelidir.
GUI’ye erişildikten sonra her cihaz için sırasıyla aşağıdaki temel ayarlar yapılır:
System → Settings menüsünden:
- Hostname alanına cihazın rolüne uygun isim verilir:
HQ,ISP,BRANCH - Timezone olarak
(GMT+3:00) Istanbulseçilir
Saat bilgisinin doğru ayarlanması; loglama, troubleshooting ve IPsec gibi zamana duyarlı protokollerin sağlıklı çalışması açısından kritik önem taşımaktadır.
Ayarlar kaydedildikten sonra sayfa yenilenir ve sol üst köşede hostname’in güncellendiği doğrulanır.
Yapımızın mevcut durumu bu şekilde olmalıdır;
Şimdi ise interface IP atamalarını gerçekleştirelim.
HQ > Network > Interfaces > port2 > IP/Netmask: 30.30.30.1/30 > PING > Alias: ISP_interfaces > OK
ISP > Network > Interfaces > port2 > IP/Netmask: 30.30.30.2/30 > PING > Alias: HQ_interfaces > OK
ISP > Network > Interfaces > port3 > IP/Netmask: 40.40.40.1/30 > PING > Alias: BRANCH_interfaces > OK
BRANCH > Network > Interfaces > port3 > IP/Netmask: 40.40.40.2/30 > PING > Alias: ISP_interfaces > OK
HQ–ISP ve BRANCH–ISP arasında artık karşılıklı ping atılabilir durumdadır. Ancak bu aşamada HQ’dan BRANCH ağına ping atılamayacaktır. Bu kısmı yapılandırmak için debug komutlarıyla ilerliyoruz.
İlk olarak HQ tarafına ISP’ye yönelik bir statik rota yazmamız gerekiyor.
HQ>Network > Static Routes > Destination: 0.0.0.0/0.0.0.0 > Gateway Address: 30.30.30.2 > Interface: ISP_interfaces > OK
Bu adımın özeti şudur: HQ’ya, tanımadığı bir ağ ile karşılaştığında trafiği ISP_interfaces portuna göndermesini ve gateway olarak 30.30.30.2'yi kullanmasını söylüyoruz.
Şimdi ise debug komutuyla kontrol sağlayalım bakalım ki 30.30.30.1 den 40.40.40.2 ye ping atabiliyor muyum?
Get İhsan Ahmet Köseoğlu’s stories in your inbox
Join Medium for free to get updates from this writer.
HQ > CLI
execute ping-options source 30.30.30.1
execute ping-options repeat-count 500
execute ping 40.40.40.2
Normalde statik rota tanımlandığında paket zaten 30.30.30.1 üzerinden çıkacaktır ancak kaynağı garanti altına almak için source adresini açıkça belirttik. Uzun süreli izleme yapabilmek adına ping sayısını 500 olarak ayarladık. Ping atıldığında trafiğin gitmediği gözlemleniyor. ISP cihazımızı kontrol edelim.
ISP>CLI ;
diagnose debug flow filter saddr 30.30.30.1
diagnose debug flow filter daddr 40.40.40.2
diagnose debug flow trace start 1000
diagnose debug enable 
Debug çıktısında karşılaştığımız hata: “denied by forward policy check (policy 0)”
Peki bu hata ne anlama geliyor? Firewall’lar temel davranışları gereği trafiğe izin vermek için bir kurala ihtiyaç duyarlar. ISP firewall’umuzda bu kural henüz tanımlanmadığından trafik engellenmektedir. Bu nedenle Policy & Objects > Firewall Policy bölümüne giderek gerekli kuralı oluşturmamız gerekiyor.
Kuralı HQ_interfaces’ten BRANCH_interfaces’e doğru yazacağız. Bu noktada bir sıkılaştırma da uygulanabilir; örneğin kaynak olarak 30.30.30.1, hedef olarak 40.40.40.2 belirtilerek servis kısmına IPsec için kullanılan UDP 4500 ve protokol 50 portları eklenebilir. Bu segmentasyon yapılandırmasını ilerleyen derslerde detaylı olarak ele alacağız. Şimdilik NAT’ı kapatarak all/all şeklinde bir kural oluşturup trafiğe izin veriyoruz.
Artık paket isteklerinin geçtiğini gözlemleyebiliriz. Ancak HQ firewall’unda reply paketleri hâlâ görünmüyor. Peki neden? Bu da bir debug sorusudur. ISP üzerinden geçtiğini doğruladığımıza göre sorunun BRANCH firewall’umuzda olduğu anlaşılıyor.
BRANCH > CLI
diagnose debug flow filter saddr 30.30.30.1
diagnose debug flow filter daddr 40.40.40.2
diagnose debug flow trace start 1000
diagnose debug enable
Karşılaştığımız hata: “reverse path check fail, drop”
Bu hatayı araştırdığımızda görülen şey şudur: pakete ait bir dönüş rotasının tanımlanmamış olmasıdır. Bunu Routing Monitor üzerinden de doğrulayabiliriz.
Dashboard > + > Routing > Add Widget > Route Lookup > Destination: 30.30.30.1
Arama sonucunda BRANCH firewall’unun bu hedefe ait herhangi bir rota bilgisi barındırmadığı görülecektir. HQ’da yaptığımız gibi BRANCH tarafına da bir statik rota tanımlamamız gerekiyor. Rotayı 40.40.40.1'e, yani BRANCH ağının ISP_interfaces’ine doğru yazıyoruz.
Artık HQ BRANCH’in 40.40.40.2'sine erişiyor ancak IPsec mantığında BRANCH’inde HQ’nun 30.30.30.1 ine erişmesi gerekiyor bu nedenle ISP üzerinde reverse policy yazıyoruz.
Son olarak LAN bacaklarını yapılandırarak topolojimizi tamamlıyoruz.
HQ > Network > Interfaces > port3 > IP/Netmask: 60.60.60.1/24 > Alias: LAN > PING: Enable > DHCP: Enable > OK
BRANCH > Network > Interfaces > port4 > IP/Netmask: 70.70.70.1/24 > Alias: LAN > PING: Enable > DHCP: Enable > OK
Yapılandırma tamamlandıktan sonra PC’leri ilgili firewall portlarına bağlıyoruz. PC’yi açarak aşağıdaki komutu çalıştırıyoruz:
ip dhcpPC’nin DHCP üzerinden otomatik olarak IP aldığını gözlemliyoruz. Böylece hem HQ hem de BRANCH tarafındaki LAN ağları hazır hale gelmiş oldu.
Yapımızın son hali aşağıdaki gibidir ;
Bir sonraki yazıda IPsec yapılandırmasını gerçekleştiricez.
TEŞEKKÜRLER….
