Sadece beş çalışanı olan küçük bir lojistik ofisine ticari bir ZTNA (Zero Trust Network Access) lisansı için yıllık 4.000 dolar fatura çıkarıldığında, güvenlik bütçelerinin ne kadar mantıksız şişebildiğini bir kez daha anladım. Self-hosted VPN ve ticari çözümler arasındaki temel fark, ilk kurulum maliyetinden ziyade uzun vadeli operasyonel efor ve güvenlik sorumluluğunun kimde olduğudur. Kendi VPN sunucumuzu kurup yönetmek sunucu maliyeti açısından neredeyse bedavayken, ticari çözümler bize sorumluluğu delege etme ve kolay ölçeklenme vaat eder. Bu yazıda, her iki yaklaşımın gerçek maliyet anatomisini, teknik sınırlarını ve hangisini ne zaman seçmeniz gerektiğini masaya yatırıyorum.
Açık kaynaklı araçlarla kendi altyapımızı kurduğumuzda cebimizden çıkan para azalır ancak zamanımızdan giden pay ciddi oranda artar. Ticari bir SaaS ürünü aldığımızda ise faturayı doğrudan öderiz ama geceleri sunucu çöktü mü endişesi taşımayız. Bu iki kutup arasında sıkışıp kalmamak için mimariyi, gizli operasyonel maliyetleri ve teknik detayları iyi analiz etmek gerekiyor.
Self-Hosted VPN nedir ve hangi gizli maliyetleri barındırır?
Self-hosted VPN, kontrolü tamamen sizde olan bir sunucu (VPS veya bare-metal) üzerinde WireGuard, OpenVPN veya IPsec gibi açık kaynaklı protokolleri çalıştırarak kendi özel erişim ağ geçidiniz oluşturma yöntemidir. Bu mimaride donanım, IP adresi ve işletim sistemi seviyesindeki tüm bileşenler doğrudan sizin yönetiminizde olur. İlk bakışta aylık 5-10 dolarlık bir sanal sunucu kirasıyla yüzlerce kullanıcıya hizmet verebileceğinizi düşünmek cazip gelse de madalyonun diğer yüzü oldukça farklıdır.
Gizli maliyetlerin başında operasyonel bakım eforu gelir. Sunucunun işletim sistemi güncellemeleri, kernel yamaları, VPN yazılımının güvenlik açıkları (CVE) takibi ve log yönetimi tamamen sizin zamanınızdan çalar. Örneğin, WireGuard kullanan bir sunucuda IP routing tablolarının bozulması veya bir sistem güncellemesi sonrası tünel arayüzünün ayağa kalkmaması gibi sorunları çözmek için harcayacağınız mühendislik saati, ticari bir servise ödeyeceğiniz lisanstan daha pahalıya patlayabilir.
Ayrıca yedeklilik ve yüksek erişilebilirlik (High Availability) kurmak da ayrı bir derttir. Tek bir VPN sunucusu çöktüğünde tüm ekibin işi duruyorsa, coğrafi olarak yedekli bir yapı kurmanız gerekir. Bu da birden fazla lokasyonda sunucu kiralamak, dinamik yönlendirme (BGP veya DNS tabanlı failover) yapılandırmak ve veritabanı senkronizasyonunu yönetmek demektir. Kısacası, self-hosted VPN’de faturayı para olarak değil, doğrudan kendi zamanınız ve stresinizle ödersiniz.
Ticari VPN ve ZTNA çözümleri neden bu kadar pahalı?
Ticari VPN ve modern Zero Trust Network Access (ZTNA) çözümleri, kullanıcı başına aylık lisanslama modeliyle çalışır ve bu fiyatlar işletme büyüdükçe katlanarak artar. Bu çözümlerin pahalı olmasının temel sebebi, sadece güvenli bir tünel değil; kimlik sağlayıcı (IdP) entegrasyonu, cihaz sağlığı kontrolü (device posture), anomali tespiti ve küresel bir ağ altyapısı sunmalarıdır. Siz bir lisans aldığınızda, arka planda dünyanın farklı noktalarındaki yüzlerce sunucunun bakımından ve performansından kurtulmuş olursunuz.
Örneğin, Active Directory, Okta veya Google Workspace entegrasyonunu kendi kurduğunuz bir OpenVPN sunucusunda LDAP ile yapmaya çalışmak tam bir işkencedir. Ticari çözümlerde ise bu entegrasyon genellikle birkaç tıklamayla tamamlanır ve çok faktörlü doğrulama (MFA) süreçleri kutudan çıktığı gibi çalışır. Kullanıcı işten ayrıldığında merkezi kimlik yönetiminden silindiği an VPN erişimi de otomatik olarak kesilir.
Buna ek olarak, ticari sistemler kullanıcıların cihaz güvenliğini de denetler. Bilgisayarda antivirüs aktif mi, işletim sistemi güncel mi gibi kontrolleri yapıp, şartları sağlamayan cihazları ağa almazlar. Kendi kuracağınız bir altyapıda bu seviyede bir Zero Trust politikası uygulamak için aylarca geliştirme yapmanız veya üçüncü parti ajan yazılımlarıyla uğraşmanız gerekir.
Ticari çözümlerin gizli kilitlenme (Vendor Lock-in) riski nedir?
Ticari bir güvenlik ekosistemine tamamen bağlandığınızda, ilerleyen yıllarda fiyat artışlarına karşı tamamen savunmasız kalırsınız. Tescilli (proprietary) istemci yazılımları ve kapalı devre protokoller kullandıkları için, sistemden başka bir sağlayıcıya geçmek tüm kullanıcıların bilgisayarlarındaki yazılımları değiştirmeyi gerektirir. Bu durum, özellikle yüzlerce çalışanı olan yapılarda ciddi bir operasyonel direnç ve göç maliyeti yaratır.
Ayrıca, ticari sağlayıcının kendi altyapısında yaşayacağı küresel bir kesinti, sizin hiçbir müdahale şansınız olmadan tüm ekibinizin saatlerce çalışamaz hale gelmesine yol açabilir. Kendi barındırdığınız sistemde kontrol sizdedir; yedek sunucuyu ayağa kaldırmak veya trafiği yönlendirmek sizin elinizdedir. Ancak SaaS dünyasında sadece durum sayfasını (status page) yenilemekle yetinirsiniz.
WireGuard ve OpenVPN karşılaştırmasında kaynak tüketimi nasıl değişir?
Eğer self-hosted yolundan gitmeye karar verdiyseniz, seçeceğiniz protokol sunucu kaynak tüketimini ve dolayısıyla donanım maliyetinizi doğrudan etkiler. OpenVPN, uzun yıllardır endüstri standardı olsa da kullanıcı alanı (user space) seviyesinde çalışır ve her paket geçişinde bağlam değişimi (context switch) yaparak CPU’yu ciddi şekilde yorar. WireGuard ise Linux kernel modülü olarak (kernel space) çalıştığı için inanılmaz derecede hafiftir ve kaynak tüketimi neredeyse yok denecek kadar azdır.
Geçmişte bir üretim ERP’sinin saha terminallerini merkeze bağlarken her iki protokolü de farklı dönemlerde deneyimledim. OpenVPN tünelleri, özellikle zayıf donanımlı el terminallerinde ve eski sunucularda yüksek şifreleme yükü sebebiyle gecikmelere (latency) ve bağlantı kopmalarına yol açıyordu. Aynı yapıyı WireGuard protokolüne geçirdiğimizde, sunucu CPU kullanımının belirgin şekilde düştüğünü ve bağlantı kurma sürelerinin milisaniyeler mertebesine indiğini gördük.
Aşağıdaki basit SystemD servis yapılandırması, WireGuard’ın Linux üzerinde ne kadar yalın ve bağımlılıksız çalışabildiğinin bir kanıtıdır:
# /etc/systemd/system/[email protected]/override.conf
[Service]
# WireGuard'ın sistem kaynaklarını sömürmemesi için cgroup limitleri koyuyoruz
CPUAccounting=true
MemoryAccounting=true
MemoryHigh=256M
MemoryMax=512M
AllowedCPUs=0,1Bu basit cgroup limitleri sayesinde, beklenmedik bir trafik patlamasında bile VPN servisinin tüm sunucu belleğini tüketip diğer kritik servisleri (örneğin veritabanı veya yerel log mekanizmalarını) çökertmesini engellemiş oluyoruz. OpenVPN’de benzer bir stabiliteyi yakalamak için çok daha karmaşık çoklu iş parçacığı (multi-threading) ve buffer ayarlarıyla oynamak gerekir.
Güvenlik ve segmentasyon gereksinimlerini kendi altyapımızda nasıl çözeriz?
Kendi VPN sunucunuzu kurduğunuzda en büyük tehlike, tünele giren her kullanıcının tüm iç ağa (LAN) sınırsız erişim hakkı kazanmasıdır. Ticari ZTNA çözümleri bunu uygulama seviyesinde mikro-segmentasyon ile çözerken, self-hosted dünyada bu işi Linux çekirdeğinin iptables veya nftables kurallarıyla kendimiz çözmek zorundayız. Güvenli bir segmentasyon mimarisinde, VPN sunucusu sadece bir geçit olmalı ve her kullanıcı grubu sadece yetkili olduğu IP bloklarına erişebilmelidir.
Aşağıdaki ağ akış şemasında, kendi barındırdığımız bir WireGuard sunucusu üzerinde kullanıcı gruplarını iptables kurallarıyla nasıl izole ettiğimizi görebilirsiniz:
graph TD; "Dış İstemciler (Ev/Mobil)" --> "WireGuard Ağ Geçidi (wg0)" "WireGuard Ağ Geçidi (wg0)" --> "iptables Filtreleme Duvarı" "iptables Filtreleme Duvarı" -->|Yazılımcı Yetkisi| "Geliştirme Sunucuları (VLAN 10)" "iptables Filtreleme Duvarı" -->|Operatör Yetkisi| "Üretim ERP Veritabanı (VLAN 20)" "iptables Filtreleme Duvarı" -->|Yönetici Yetkisi| "Tüm Ağ Segmentleri (VLAN 10/20/30)" "iptables Filtreleme Duvarı" --x|Engellenen Trafik| "Finans / İK Sunucuları (VLAN 30)"
Bu yapıyı kurmak için WireGuard konfigürasyon dosyasına (/etc/wireguard/wg0.conf) her istemci bazında özel kurallar eklememiz gerekir. Örneğin, sadece belirli bir istemcinin sadece ERP sunucusuna erişmesine izin verip, diğer tüm iç ağ trafiğini engellemek için şu tarz bir PostUp kuralı yazarız:
[Interface]
PrivateKey = SUNUCU_OZEL_ANAHTARI_BURAYA
Address = 10.8.0.1/24
ListenPort = 51820
# Varsayılan yönlendirmeleri temizle ve sıkı kurallar uygula
PostUp = iptables -A FORWARD -i wg0 -s 10.8.0.5 -d 192.168.20.10 -j ACCEPT; iptables -A FORWARD -i wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT; iptables -A FORWARD -i wg0 -j DROP
PostDown = iptables -D FORWARD -i wg0 -s 10.8.0.5 -d 192.168.20.10 -j ACCEPT; iptables -D FORWARD -i wg0 -j DROPBu yaklaşım teoride mükemmel çalışsa da pratik zorlukları vardır. Şirkete yeni bir çalışan girdiğinde veya bir sunucunun IP adresi değiştiğinde, bu konfigürasyon dosyalarını manuel olarak güncellemek, hata yapmaya inanılmaz derecede açık bir süreçtir. Tek bir noktalı virgül hatası veya yanlış subnet tanımı, tüm şirketin erişimini kesebilir veya tam tersine yetkisiz bir kullanıcının finans sunucularına sızmasına yol açabilir.
Hangi senaryoda hangi VPN modelini seçmeliyiz?
Seçim yaparken duygusal veya ideolojik değil, tamamen finansal ve operasyonel gerçeklere göre hareket etmeliyiz. Eğer 10-15 kişilik çekirdek bir ekibiniz varsa, ağ topolojiniz çok karmaşık değilse ve ekibinizde Linux sistem yönetiminden anlayan en az bir kişi varsa, self-hosted VPN sizin için biçilmiş kaftandır. Boş yere ticari lisanslara binlerce dolar akıtmak yerine, bu bütçeyi daha güçlü sunucu donanımlarına veya geliştirme süreçlerine aktarabilirsiniz.
Ancak kullanıcı sayınız 50’yi aşıyorsa, çalışan sirkülasyonunuz hızlıysa ve sıkı regülasyonlara (KVKK, ISO 27001, SOC2 vb.) tabiyseniz, hiç düşünmeden ticari bir ZTNA veya kurumsal VPN çözümüne geçmelisiniz. Bu regülasyonlar sizden “kimin, ne zaman, hangi cihazla, nereye eriştiğinin” detaylı logunu ve bu logların değiştirilemez şekilde saklanmasını ister. Bunu self-hosted bir yapıda denetlenebilir şekilde kurmak ve sürdürmek, ticari lisans bedelinden çok daha pahalıya mal olan bir uyumluluk (compliance) yükü getirir.
Karar vermenizi kolaylaştırmak için hazırladığım şu karşılaştırma tablosu, iki dünya arasındaki trade-off’ları net şekilde özetliyor:
| Kriter | Self-Hosted VPN (WireGuard/OpenVPN) | Ticari Çözümler (SaaS / ZTNA) |
|---|---|---|
| Doğrudan Maliyet | Çok Düşük (Sadece Sunucu/IP Ücreti) | Yüksek (Kullanıcı Başına Lisanslama) |
| Operasyonel Yük | Çok Yüksek (Güncelleme, CVE, Yedeklilik) | Neredeyse Sıfır (Sağlayıcı Tarafından Yönetilir) |
| Kimlik Entegrasyonu | Zor (LDAP, Manuel Sertifika Yönetimi) | Çok Kolay (OIDC, SAML, Okta, Google) |
| Erişim Denetimi | Zor (IP/Port Seviyesinde Firewall) | Kolay (Uygulama/Kullanıcı Bazlı Zero Trust) |
| Cihaz Güvenliği Kontrolü | Yok (Ekstra Araçlar Gerekir) | Yerleşik (Device Posture / Compliance) |
| Ölçeklenebilirlik | Limitli (Sunucu Kaynağı ve Bant Genişliği) | Sınırsız (Küresel Edge Network Altyapısı) |
Bakım, güncelleme ve CVE takibi operasyonu nasıl yönetilir?
Self-hosted VPN altyapısını seçtiyseniz, kendinizi bir “güvenlik yöneticisi” olarak konumlandırmanız gerekir. VPN sunucusu, dış dünyaya açık ve doğrudan şirketinizin kalbine tünel açan en kritik kapıdır. Bu kapının arkasında çalışan işletim sisteminin her gün güncellenmesi ve kritik güvenlik açıklarının anında kapatılması gerekir. CVE (Common Vulnerabilities and Exposures) bültenlerini yakından takip etmek ve sisteminizi yamamak artık günlük rutininizin bir parçası olmalıdır.
Ben kendi yönettiğim Linux sunucularda kritik işletim sistemi güncellemelerini otomatikleştirmek için unattended-upgrades paketini kullanıyorum. Ancak sadece bu yetkili değildir; VPN servisinin kendisinde çıkabilecek sıfırıncı gün açıklarına karşı acil durum planınız olmalıdır. Örneğin, tünel protokolünde tespit edilen kritik bir zafiyet anında sunucuyu izole edebilecek ve trafiği yedek bir protokole (örneğin WireGuard’dan OpenVPN fallback yapısına) kaydırabilecek esnekliği önceden tasarlamalısınız.
Ayrıca log analizi ve saldırı engelleme için fail2ban gibi araçları doğru yapılandırmak hayati önem taşır. WireGuard UDP kullandığı için port taramalarına doğrudan yanıt vermez ve bu yönüyle sessizdir; ancak OpenVPN TCP/UDP portları sürekli taramalara maruz kalır. Sunucu üzerindeki başarısız bağlantı denemelerini izleyip saldırgan IP adreslerini kernel seviyesinde engellemek, sunucunuzun kaynaklarının tükenmesini (DoS/DDoS) önlemek için ilk savunma hattınızdır.
Son Söz
Güvenlikte “en iyi” çözüm yoktur, “sürdürebileceğiniz” çözüm vardır. Kendi VPN sunucunuzu kurmak teknik olarak harika bir öğrenme süreci ve küçük ekipler için muazzam bir maliyet tasarrufu sağlasa da, büyüyen bir organizasyonda bu yükü taşımak mantıklı değildir. Operasyonel odak noktanızı kendi ana işinizde tutmak, güvenlik altyapısının sorumluluğunu bu işi profesyonel olarak yapan ticari sağlayıcılara devretmek çoğu zaman en rasyonel ticari karardır. Kendi faturanızı kendiniz kesmek istiyorsanız sisteminizi iyi segmentte edin, istemci cihazlarınızı sıkı denetleyin ve güncellemeleri asla aksatmayın.