Scout Cloud Gateway ile Uzaktan eLux Yönetimi: Mimari, Bağlantı Akışı ve Sahadan Dersler

Thin client dünyasında uzun süredir çözülmeye çalışılan bir problem var: İnternette, ofis dışında, sürekli değişen ağlarda bulunan cihazları nasıl merkezi olarak yönetiriz? Evden çalışan bir kullanıcının eLux cihazı, otelde bağlanan bir mobil endpoint, şubedeki bir thin client... Bunların hepsini tek bir merkezden yönetmek, klasik VPN backend'leri kurmadan mümkün mü?

Unicon'un Scout Cloud Gateway (SCG) çözümü tam da bu soruya yanıt veriyor. Bu yazıda SCG'nin mimarisini, bir cihazın dışarıdan içeriye nasıl bağlandığını adım adım inceleyeceğiz ve saha kurulumlarında en sık karşılaşılan sorunları çözümleriyle paylaşacağım.

Scout Cloud Gateway Nedir?

Scout Cloud Gateway, DMZ'de konumlanan ve internet üzerindeki eLux cihazlarını iç ağdaki Scout Server'a güvenli bir şekilde bağlayan bir VPN gateway çözümüdür. En büyük avantajı, ayrı bir VPN altyapısı kurmaya gerek bırakmadan, kendi içinde gelen OpenVPN tabanlı bir tünel altyapısıyla gelmesidir.

Çalışma mantığı özetle şöyledir: Bir eLux cihazı ilk kez bağlandığında kullanıcı kimlik doğrulaması yapar. Doğrulama başarılı olursa SCG, cihaza VPN yapılandırmasını ve Scout Server adresini iletir. Bu noktadan sonra cihaz, sanki iç ağdaymış gibi yönetilebilir hale gelir.

Mimari: Üç Katmanlı Yapı

SCG kurulumunu anlamak için ortamı üç katmana ayırmak faydalı:

1. Dış Katman (Internet / WAN) Cihaz burada public bir IP ile başlar. 4G hotspot, ev interneti, otel Wi-Fi — neresi olursa olsun, cihaz SCG'ye internet üzerinden bir FQDN ile ulaşır.

2. DMZ Katmanı (SCG) SCG çift bacaklı (dual-homed) bir yapıdadır. Bir bacağı DMZ'ye (dış dünyaya) bakar, diğeri iç ağa. Bu sayede internet ile iç ağ arasında kontrollü bir köprü görevi görür.

3. İç Katman (Trust) Scout Server, Active Directory, varsa Citrix bileşenleri burada bulunur. Cihaz, VPN tüneli kurulduktan sonra bu katmana erişir.

Bağlantı Akışı: Bir Cihaz Dışarıdan İçeriye Nasıl Bağlanır?

Bu kısım, kurulumların en çok kafa karıştıran bölümü. Adım adım gidelim:

Adım 1 — Kimlik Doğrulama (Authentication) Cihaz, SCG'nin public FQDN'ine HTTPS (TCP 443) üzerinden bağlanır. Kullanıcı, UPN formatında (örn. kullanici@domain.local) kimlik bilgilerini girer. SCG bu bilgiyi iç ağdaki Active Directory'ye sorar.

Adım 2 — Yetkilendirme (Authorization) Kimlik doğrulama başarılıysa SCG, kullanıcının yetkili olup olmadığını kontrol eder. Burada kritik bir mekanizma devreye girer: SCG, kullanıcının üye olduğu gruplar arasında belirli bir formatta (SCG_Group_<OU_ID>) bir grup arar. Bu grup adındaki sayı, cihazın hangi organizasyon birimine (OU) yerleştirileceğini belirler.

Adım 3 — VPN Tüneli Kurulumu Yetkilendirme tamamlanınca SCG, cihaza VPN yapılandırmasını iletir ve cihaz OpenVPN tüneli kurar (varsayılan TCP 1194). Tünel kurulduğunda cihaza, SCG'nin yönettiği özel bir IP havuzundan (VPN Range) bir adres atanır.

Adım 4 — İç Ağa Erişim İşte sihirli kısım burası. Cihaz artık iç ağa, VPN Range'den aldığı IP ile görünür. Yani dışarıdaki public IP'siyle değil, tünel içinde aldığı sanal IP ile. İç sistemler (Scout Server, AD) cihazı sanki yerel bir LAN istemcisiymiş gibi görür.

Adım 5 — Scout'a Kayıt (Enrollment) Cihaz, VPN tüneli üzerinden Scout Server'a bağlanır, yapılandırmasını çeker ve Scout Board'da "Online" olarak görünür.

VPN Range Kavramı: En Çok Karıştırılan Nokta

Saha kurulumlarında en sık gelen soru: "VPN Range, DHCP'den dağıttığımız IP'ler mi?"

Hayır. VPN Range, SCG'nin kendi içinde yönettiği özel bir IP havuzudur. DHCP sunucusundan tamamen bağımsızdır. SCG, tünel kuran her cihaza bu havuzdan bir IP atar — adeta küçük bir DHCP sunucusu gibi davranır.

Kritik nokta: Bu aralık, kurumun mevcut subnet'leriyle çakışmamalıdır. Eğer kurumda 10.x blokları kullanılıyorsa, VPN Range için kullanılmayan farklı bir blok seçmek gerekir.

Routing: Geri Dönüş Yolunu Unutmayın

VPN tüneli kurulduğunda cihaz iç ağa paket gönderebilir, ama bir sorun vardır: İç sunucu, cevabı nasıl geri gönderecek?

Diyelim cihaz VPN_Range.2 IP'sini aldı ve Scout Server'a bir paket gönderdi. Scout Server cevabı dönmek istediğinde "Bu VPN Range subnet'i nereye gidiyor?" diye sorar. Eğer routing tablosunda bu subnet yoksa, paketi varsayılan ağ geçidine atar ve cevap kaybolur.

Çözüm, iç sunucularda (veya merkezi router'da) bir statik route tanımlamaktır:

VPN_Range/24 → SCG'nin iç bacak IP'si

Bu route, "VPN Range'e giden cevapları SCG'ye ver, o halleder" der. SCG paketi alır ve tünel üzerinden cihaza ulaştırır.

İpucu: Bu route'u her sunucuya tek tek eklemek yerine, kurumsal core router/L3 switch'te tek bir satırla tanımlamak çok daha temiz bir yaklaşımdır.

Sahadan 6 Yaygın Hata ve Çözümleri

Gerçek kurulumlarda en çok zaman kaybettiren noktaları, çözümleriyle birlikte derledim.

1. Asimetrik Routing (Çift Default Gateway)

Belirti: İç ağa erişim kesik kesik çalışıyor, DNS sorguları bazen başarısız.

Sebep: Çift bacaklı SCG'de iki interface için de default gateway tanımlanmış. Linux'ta iki default gateway olunca dönüş paketleri yanlış interface'ten gider.

Çözüm: Yalnızca dış (DMZ) bacakta default gateway bırakın. İç ağdaki diğer subnet'ler için statik route kullanın.

2. Port Çakışması

Belirti: OpenVPN servisi sürekli yeniden başlıyor, log'da "Address already in use" hatası.

Sebep: VPN için yapılandırılan port, başka bir servisle (örn. yönetim arayüzünün kullandığı port) çakışıyor.

Çözüm: VPN tüneli için ayrı, çakışmayan bir port kullanın (yaygın tercih: 1194). Yapılandırma değişikliğinden sonra servis restart'ı yeterli olmayabilir — appliance'ı tamamen yeniden başlatmak en garantili yöntem.

3. MTU Uyumsuzluğu

Belirti: Log'da "Bad encapsulated packet length" hatası, özellikle mobil ağlarda.

Sebep: Mobil operatörlerin MTU değerleri kurumsal ağlardan farklı. OpenVPN, fragment edilmiş paketleri reddediyor.

Çözüm: Özel yapılandırma dosyasına tun-mtu ve mssfix parametreleri eklenebilir. Ancak bu değerlerle oynamadan önce, sorunun gerçekten MTU mu yoksa başka bir katmanda mı olduğunu doğrulamak gerekir — yoksa yanlış sorunu çözmeye çalışırsınız.

4. AD Grup / OU ID Eşleşmesi

Belirti: Kimlik doğrulama başarılı ama cihaz "User not authorized" alıyor.

Sebep: SCG'nin aradığı SCG_Group_<OU_ID> formatındaki grup AD'de yok ya da OU ID'si yanlış. Log'da NO_OBJECT veya "User not authorized" mesajı görünür.

Çözüm: Hedef OU'nun ID'sini Scout Board'dan öğrenin, AD'de tam o numara ile Global Security grubu oluşturun ve kullanıcıyı ekleyin. Grup scope'unun Global olması önemli — Domain Local bazı LDAP sorgularında görünmeyebilir.

5. Scout Server'da Eksik Route

Belirti: VPN tüneli kuruluyor, cihaz IP alıyor, ama "Server not available" hatası.

Sebep: Yukarıda anlattığımız geri dönüş yolu sorunu. Scout Server, VPN Range'e cevap dönecek route'a sahip değil.

Çözüm: Scout Server'da kalıcı statik route ekleyin. -p parametresini unutmayın, yoksa reboot sonrası kaybolur.

6. Versiyon Uyumsuzluğu

Belirti: Cihaz kayıt oluyor, yapılandırmayı çekiyor, restart sonrası siyah ekranda kalıyor. Ama text console (Ctrl+Alt+F1) çalışıyor.

Sebep: Yönetilen eLux image'ı, Scout Server'dan daha yeni bir sürümde. Eski Scout, yeni image'ın yapılandırma şemasını tam tanımıyor ve ekran ayarını hatalı uyguluyor.

Çözüm: Genel kural — Scout Server, yönettiği eLux image'ından eşit veya daha yeni olmalı. Uyumluluk için Unicon'un resmi Compatibility Matrix'ini kontrol edin. En hızlı doğrulama: Scout'unuzla aynı sürümdeki bir image ile test edin.

Teşhis İçin Olmazsa Olmaz Komutlar

Saha çalışmasında en çok işe yarayan komutlar:

SCG tarafında (Linux):

# Servis durumu
sudo systemctl status scg-openvpn --no-pager

# Hangi portlar dinleniyor
sudo ss -tulnp | grep -E "443|1194"

# Canlı VPN log
sudo tail -f /opt/unicon/scg/logs/openvpn.log

# Auth log
sudo journalctl -u scg-controller -f

# Gelen paketleri izle
sudo tcpdump -i any port 1194 -n -v

# Routing tablosu
ip route show

Scout Server tarafında (Windows):

# Route kontrolü
route print | findstr <VPN_Range>

Bu komutlar, sorunun hangi katmanda olduğunu hızlıca daraltmanızı sağlar. Genel strateji: paketin nereye kadar ulaştığını takip edin. Auth log'da iz var mı? VPN log'da bağlantı görünüyor mu? tcpdump'ta paket geliyor mu? Her katmanı tek tek doğrulayarak ilerlemek, rastgele ayar değiştirmekten çok daha hızlı sonuç verir.

Özet: Doğru Sırayla İlerlemek

SCG kurulumunun başarısı, doğru sırayla ilerlemekten geçiyor:

1. Network ve routing — tek default gateway, doğru statik route'lar

2. Firewall — dışarıdan 443 ve VPN portu, içeriden AD ve Scout erişimi

3. Kimlik doğrulama — AD bağlantısı, doğru grup ve OU ID eşleşmesi

4. VPN tüneli — port çakışması yok, gerekirse MTU ayarı

5. Scout kaydı — geri dönüş route'u, versiyon uyumu

Her katman bir öncekinin üstüne kuruluyor. Bir alt katman çalışmadan üst katmanı debug etmek, vakit kaybından başka bir şey değil. Bağlantı akışını zihninizde net tutarsanız, hangi aşamada takıldığınızı görmek ve doğru yere müdahale etmek çok daha kolay oluyor.

Thin client altyapıları, doğru kurulduğunda son derece kararlı ve yönetimi kolay sistemler. Scout Cloud Gateway de uzaktan erişim ihtiyacını, ayrı bir VPN altyapısına gerek bırakmadan zarif bir şekilde çözüyor. Yeter ki mimariyi ve bağlantı akışını doğru anlayalım.

"Bu yazı, gerçek bir saha kurulum deneyiminden damıtılmıştır. Ortama özel değerler genel örneklerle değiştirilmiştir."