Site-to-Site VPN Nasıl Kurulur? FortiGate IPsec Rehberi
İki sabit ofis ağı arasında site-to-site VPN kurarken yalnızca tünelin “up” görünmesi yeterli değildir. Bu rehber; ağ bilgilerini hazırlama, FortiGate IPsec parametrelerini eşleştirme, rota ve güvenlik politikalarını tamamlama, trafiği uçtan uca test etme ve yaygın arızaları katman katman ayıklama adımlarını açıklar.
Kısa cevap: Tünel, rota ve güvenlik politikası birlikte çalışmalı
Site-to-site VPN, sabit konumlardaki iki yerel ağı internet üzerinden şifreli bir bağlantıyla birbirine eriştirir. FortiGate tarafında bu bağlantı çoğunlukla IPsec tüneliyle kurulur. Tünel arayüzünün etkin görünmesi tek başına kullanıcıların uygulamaya erişeceğini göstermez: doğru Phase 1 ve Phase 2 müzakeresine ek olarak uzak ağa rota, iki yönde izin veren firewall policy, doğru NAT davranışı ve geri dönüş rotası gerekir. Fortinet’in güncel yönetim kılavuzu site-to-site senaryolarını FortiGate-to-FortiGate ve üçüncü taraf uçlar olarak ayrı ele alır; diğer üreticiyle bağlantıda iki uçta ortak desteklenen parametreler kullanılmalıdır.
Bu sayfa genel bir proje ve kontrol rehberidir; arayüz adları FortiOS sürümüne göre değişebilir. Canlı cihazda değişiklik yapmadan önce üreticinin cihaz sürümünüze ait dokümanını ve mevcut yapılandırmayı doğrulayın. FortiGate ürün ailesi ile satış, kurulum ve destek kapsamını FortiGate modelleri ve FortiGate teknik destek sayfalarında inceleyebilirsiniz.
Kurulumdan önce iki uçtan toplanacak bilgiler
Önce her iki lokasyonun ağ ve internet bilgilerini aynı tabloda toplayın. Bilgilerden biri eksikse kurulum sırasında yapılan tahmin, en sık görülen rota çakışması ve yanlış ağ seçimi nedenlerinden birine dönüşür.
| Bilgi | Merkez | Şube | Neden gerekli? |
|---|---|---|---|
| İnternet çıkış arayüzü ve genel IP | Yerel uç | Uzak uç | IKE/IPsec eşinin doğru adrese ulaşması |
| Yerel ağ ve VLAN CIDR’ları | Örn. 10.10.10.0/24 | Örn. 10.20.20.0/24 | Phase 2 seçicileri, rota ve erişim kapsamı |
| Uygulama hedefleri ve portları | Sunucu/IP, servis | İstemci/ağ | En az ayrıcalıklı erişim politikası |
| IKE kimlik doğrulama yöntemi | Ön paylaşımlı anahtar veya sertifika | İki uçta aynı ve güvenli kimlik doğrulama | |
| IKE sürümü ve Phase 1/2 proposal’ları | Her iki üreticinin ortak desteklediği değerler | Müzakere uyumsuzluklarını önlemek | |
| Yedek hat ve kesinti hedefi | Öncelik/SLA | Öncelik/SLA | Failover ve geri dönüş testini planlamak |
Önemli: Yerel ağ aralıkları iki tarafta çakışıyorsa basit bir tünel tasarımı yeterli olmayabilir. Adres planını yeniden düzenlemek veya kontrollü NAT gibi ayrı bir tasarım gerekir. Fortinet, çakışan subnet’ler için ayrı bir site-to-site senaryosu yayımlar; bu durumda ağ ve NAT kararını dokümana göre verin, üretim trafiğinde doğrudan deneme yapmayın.
1. IKE ve Phase 1: Uçların güvenli biçimde anlaşması
Phase 1, eşlerin birbirini bulduğu ve tünel için güvenli bir yönetim kanalı oluşturduğu müzakere bölümüdür. Uzak ağ geçidi IP’si veya FQDN’si, dış arayüz, IKE sürümü, kimlik doğrulama türü ve şifreleme/doğrulama teklifleri iki uç arasında uyumlu olmalıdır. Dinamik IP, NAT arkasındaki uç, birden çok eş veya sertifikalı kimlik doğrulama varsa başlangıç tasarımı buna göre seçilmelidir.
- FortiGate-to-FortiGate kurulumunda üreticinin VPN sihirbazı veya özel IPsec tüneli seçeneği kullanılabilir; sihirbazın oluşturduğu rota ve policy’leri ayrıca inceleyin.
- Üçüncü taraf cihazda karşı tarafın desteklediği IKE sürümü, kimlikleri ve proposal değerlerini üretici dokümanından alın. “Varsayılanlar her yerde aynıdır” varsayımını yapmayın.
- Ön paylaşımlı anahtar kullanılıyorsa uzun, rastgele ve yalnızca bu tünele özgü olsun; iki tarafa da güvenli kanaldan girin. Mümkün ve uygun olduğunda sertifika tabanlı kimlik doğrulamayı değerlendirin.
- İki uçta DPD/keepalive, yeniden anahtarlama ve zamanlayıcı değerlerinin nasıl çalıştığını kontrol edin. Bu değerleri sadece tünel daha hızlı açılsın diye gelişigüzel düşürmeyin.
Phase 1 kurulamıyorsa önce internet erişimini ve peer adresini, ardından IKE sürümünü, kimlik doğrulamayı, PSK/sertifika durumunu ve proposal eşleşmesini kontrol edin. Yönetim arayüzündeki IPsec olay günlüğü ve her iki cihazın aynı zaman dilimindeki logları, tahmin yürütmekten daha hızlı sonuç verir.
2. Phase 2: Hangi ağ trafiğinin tünele gireceği
Phase 2, korunacak veri trafiğinin ağ kapsamını ve ilgili IPsec proposal’larını tanımlar. Yerel ve uzak subnet’ler ters yönde doğru yazılmalı, maske/prefix’ler iki tarafta aynı kapsamı ifade etmeli ve yalnızca ihtiyaç duyulan ağlar eklenmelidir. Çoklu subnet varsa her birinin tasarımda, rota tablosunda ve policy’lerde karşılığı olduğundan emin olun.
Bir uçta örneğin 10.10.10.0/24 yerel ve 10.20.20.0/24 uzak ağ ise karşı tarafta yerel/uzak roller tersine döner. Bu basit örnek gerçek adres planınız değildir; üretim yapılandırmasına kopyalamayın. FortiGate’in temel site-to-site örneğinde de Phase 2 seçicileri, yalnızca tanımlı yerel subnet trafiğinin tünelden geçeceği biçimde yapılandırılır.
Phase 1 kuruluyor fakat Phase 2 kurulmuyorsa öncelikle iki uçtaki subnet seçicilerini, Phase 2 şifreleme/doğrulama proposal’larını, PFS/DH grubu gibi iki tarafça eşleşmesi gereken seçenekleri ve SA ömrü/anahtar yenileme durumunu karşılaştırın. Üretici ve sürüme özgü seçenekleri resmî kılavuzdan teyit edin.
3. Rota, firewall policy ve NAT: Tünelden gerçek trafik geçsin
Tünel kurulduktan sonra FortiGate’in uzak ağ için doğru yolu seçmesi gerekir. Tasarıma göre statik rota, dinamik yönlendirme veya SD-WAN kuralı kullanılır. Uzak subnet’in hangi tünel arayüzünden erişileceğini doğrulayın; yedek tünel varsa aktif/pasif veya yük paylaşım davranışını ayrıca tanımlayın.
Sonra kaynak ağdan hedef ağa giden ve dönüş trafiğini kapsayan güvenlik politikalarını oluşturun. Kaynak/hedef nesneleri ve servisleri ihtiyaca göre daraltın; test için geniş “any-to-any” kuralı bırakmayın. Tünel içindeki site-to-site trafiğinde çoğu senaryoda kaynak NAT istenmez; ancak iki taraftaki adresler çakışıyorsa veya özel bir tasarım gerektiriyorsa NAT davranışı bilinçli seçilmelidir. NAT kapalı/açık kararını her policy için kontrol edin.
Sunucudaki işletim sistemi güvenlik duvarı, uygulama ACL’si, DNS, varsayılan ağ geçidi ve geri dönüş rotası da erişimi etkiler. FortiGate üzerinde giden paket doğru görünse bile sunucu yanıtı başka ağ geçidinden çıkıyorsa bağlantı tamamlanmaz. Yalnızca ping’e bakmayın; gerçek uygulama portu ve kullanıcı akışını test edin.
4. Devreye alma ve kabul testi
Değişiklik penceresi, geri dönüş planı ve sorumlu kişiler önceden belirlenmeli; başlangıç yapılandırması güvenli biçimde yedeklenmelidir. Testleri tek bir yönetim istasyonundan, kaynağı ve hedefi kayda alarak yürütün:
- IKE Phase 1 ve Phase 2 SA durumunu iki uçta doğrulayın; yalnızca bir cihazın “up” göstergesiyle yetinmeyin.
- İzin verilen her kaynak subnet’ten, izin verilen gerçek hedef IP ve uygulama portuna bağlantıyı test edin.
- Firewall loglarında doğru policy’nin eşleştiğini, beklenmeyen NAT veya deny olmadığını kontrol edin.
- DNS adı kullanılıyorsa isim çözümlemesini; dosya paylaşımı, ERP veya uzak yönetim gibi gerçek uygulama akışını test edin.
- İkinci internet hattı veya yedek tünel varsa kontrollü kesinti senaryosu uygulayın: geçiş süresini, paket kaybını ve geri dönüş davranışını kaydedin.
- MTU/MSS veya parçalanma problemi olabileceği için küçük paket testi başarılı diye büyük aktarımın da başarılı olduğunu varsaymayın; uygulamanın gerçek veri akışını deneyin.
- Son durumu, test kanıtlarını, değişen nesne/policy’leri ve geri alma adımlarını teslim dokümanına yazın.
Site-to-site VPN çalışmıyorsa kontrol sırası
| Belirti | İlk bakılacak yer | Kontrol |
|---|---|---|
| Phase 1 hiç oluşmuyor | WAN ve IKE | Peer IP/FQDN, internet erişimi, UDP 500/4500 geçişi, IKE sürümü, kimlik ve PSK/sertifika, Phase 1 teklifleri |
| Phase 1 var, Phase 2 yok | Subnet seçicileri | Yerel/uzak ağların tersliği, prefix, Phase 2 proposal, PFS/DH ve her iki uçtaki log |
| Tünel kurulu, erişim yok | Rota ve policy | Uzak rota/tünel arayüzü, iki yönlü policy, doğru kaynak/hedef nesnesi, servis, NAT ve sunucunun dönüş rotası |
| Bazı subnet veya uygulamalar çalışmıyor | Kapsam ve uç cihaz | Eksik Phase 2/rota/policy, yerel OS firewall, DNS, ACL ve dönüş yolu |
| Küçük paket geçiyor, büyük aktarım takılıyor | MTU/MSS ve yol | PMTU/fragmentation, ara NAT/ISP davranışı, gerçek uygulama testi ve log |
| Yedek hatta geçiş başarısız | Failover tasarımı | İzleme hedefi, rota önceliği, tünelin yeni WAN’dan kurulması, policy ve geri dönüş |
Fortinet dokümanlarında ayrıca Phase 1/Phase 2 uyumsuzluğu, rota ve NAT gibi başlıklara göre ayrılmış örnekler bulunur. Arıza kaydı açarken PSK, yönetici parolası veya özel anahtar göndermeyin. Gerekli logları paylaşmadan önce hassas IP ve kullanıcı bilgilerini kurum politikanıza göre maskeleyin.
Güvenlik ve işletim için unutulmaması gerekenler
- Tüneli yalnızca gerekli ağ ve servislerle sınırlandırın; kullanıcı, sunucu, kamera ve misafir ağlarını gereksiz yere birbirine açmayın.
- Kimlik doğrulama anahtarlarını güvenli saklayın ve paylaşımını kayıt altına alın. Anahtar sızması şüphesinde iki uçta planlı yenileme yapın.
- Yapılandırma yedeği, değişiklik kaydı, olay logları, saat eşitlemesi ve sorumlu ekip bilgisi bulunmalı.
- FortiOS sürümünü ve üretici güvenlik duyurularını kurumsal güncelleme sürecinde izleyin; VPN değişikliğini firmware yükseltmesiyle aynı kontrolsüz pencereye yığmayın.
- Şube veya internet hattı değişince peer IP/FQDN, rota, erişim listesi ve failover testini yeniden doğrulayın.
Sık sorulan sorular
Site-to-site VPN ne işe yarar?
Merkez ve şube gibi sabit lokasyonların yerel ağları arasında, internet üzerinden şifreli bağlantı kurarak seçilen sistemlere erişim sağlar. Erişim kapsamını rota ve güvenlik politikaları belirler.
Phase 1 ve Phase 2 arasındaki fark nedir?
Phase 1 eşler arasında IKE güvenli müzakeresini ve kimlik doğrulamayı kurar. Phase 2 ise korunacak ağ trafiğinin seçicilerini ve veri trafiği için IPsec parametrelerini belirler. Her iki aşama da iki uçta uyumlu olmalıdır.
Tünel “up” ama erişim yoksa ne kontrol edilmeli?
Önce uzak ağ rotasını, iki yönlü firewall policy’yi, NAT kararını ve sunucunun dönüş rotasını kontrol edin. Ardından hedef portu, DNS’i, uç cihaz güvenlik duvarını ve eşleşen policy logunu gerçek kullanıcı akışıyla test edin.
Farklı marka firewall’lar arasında site-to-site VPN kurulur mu?
Üreticilerin ortak desteklediği IKE sürümü, kimlik doğrulama biçimi, proposal ve trafik seçicileri eşleştirilebildiğinde kurulabilir. Kesin uyumluluğu her iki cihazın model ve yazılım dokümanından teyit edin.
İki lokasyonun IP aralıkları çakışıyorsa ne yapılır?
Rota seçiminde belirsizlik oluşabilir. Tercih edilen çözüm adres planını çakışmayacak biçimde düzenlemektir; bu mümkün değilse Fortinet’in overlapping-subnet örneği gibi üretici dokümanına dayalı kontrollü NAT tasarımı gerekir.
Kurulum teklifi için hangi bilgiler yeterlidir?
İlk değerlendirme için iki lokasyonun subnet’leri, cihaz modeli/yazılım sürümü, internet hattı ve sabit/dinamik IP bilgisi, erişmesi gereken uygulama/portlar, yedek hat ihtiyacı ve planlanan bakım penceresi yeterlidir. Parola veya PSK paylaşmayın.
Özet
Sağlam bir site-to-site IPsec VPN; eşleşen IKE/Phase 1 ve Phase 2 ayarları, çakışmayan ağ planı, doğru rota, dar kapsamlı firewall policy, bilinçli NAT ve iki yönde kabul testiyle tamamlanır. “Tünel açık” durumunu son kullanıcı erişiminin kanıtı saymayın. Üretim değişikliğini kayıt altına alın, yedek ve geri dönüş planını hazırlayın, gerçek uygulamayı ve varsa failover’ı test edin.
FortiGate ile şube bağlantısı tasarlıyor veya çalışan VPN’de erişim/kararlılık sorunu yaşıyorsanız FortiGate teknik destek ve kurulum kapsamını inceleyin. Yeni cihaz, mevcut cihaz ve lisans ihtiyaçlarını birbirinden ayırmak için FortiGate satış ve kurulum sayfasından devam edebilirsiniz.
DKAVİS Teknik Ekibi
Bilgi ve kapsam zamanla değişebilir. Kritik teknik kararlardan önce mevcut sistem koşullarını ve ilgili üretici veya kurumun güncel dokümanlarını ayrıca doğrulayın.
Yayın ve güncelleme ilkelerimizi inceleyin →