VPN kullanıcılarına alt ağa değil, tek bir hizmete erişim verin

Bir yüklenicinin ihtiyacı tek bir dahili web uygulamasıdır, başka bir şey değil, ve kolay cevap ona sunucu alt ağına bir tünel vermektir. Bu, onu taradığı güne kadar çalışır. Daha dar tasarım daha fazla düşünme gerektirir, çünkü erişilebilirlik, yönlendirme ve uygulama izni uyuşması gereken üç ayrı kontroldür.

Gereksinimi alt ağ olarak değil, hizmet olarak yazın

Hedef ana bilgisayar, protokol ve bağlantı noktasıyla başlayın, ardından oraya ulaşması gereken kullanıcı veya cihaz grubunu ekleyin. Özel DNS bölgesini yalnızca uygulama bir adı çözümlüyorsa ekleyin, kimlik sağlayıcıyı yalnızca oturum açma akışı buna ihtiyaç duyuyorsa ekleyin. Geri kalan her şey henüz gerekçelendirmediğiniz bir bağımlılıktır.

Alt ağ, ağ ekibinin uygulama ayrıntısıdır; hizmet ise işin istediği şey ve gözden geçirilip kullanımdan kaldırılabilecek birimdir.

Bağımlılık listesi üç öğeyi aşarsa, uygulamanın muhtemelen kendi tasarım konuşmasına ihtiyacı vardır.

Dar yönlendirin, ama yaptırımı başka yerde uygulayın

Dar bir rota veya seçici, tünele hangi paketleri taşıyacağını söyler; bu bir yetkilendirme politikası değildir. Ağ geçidi filtresi, hedef ana bilgisayarın güvenlik duvarı ve uygulamanın kendi izin modeli erişimin kararlaştırıldığı yerlerdir. Tek bir adresi kapsayan rota iyi bir başlangıçtır ve kararlı bir kullanıcıyı durduran kontrol değildir. Bu ayrım, tüneli yeniden tasarlamadan filtreyi değiştirmenizi sağlar.

Tersine, sıkı filtreli geniş bir rota meşru olabilir, ancak yalnızca ilgili herkes hangisinin yaptırımı uyguladığını biliyorsa.

Yaptırım noktasını açıkça belgeleyin, yoksa bir sonraki değişiklik onu yanlışlıkla taşır.

Hizmetin gerçekte gördüğü kaynağı kontrol edin

Hedef, çevirip çevirmediğinize bağlı olarak istemci havuzunun adresini veya ağ geçidinin adresini görür. Ana bilgisayarın güvenlik duvarı kuralları ve günlükleri gerçek kaynakla eşleşmelidir. Birden çok kullanıcı çevrilmiş bir kaynağı paylaşıyorsa, o ana bilgisayardaki hiçbir kullanıcı başına kural onları ayırt edemez ve bu bir tasarım kısıtıdır, hata değil.

Çeviriyi bilinçli seçin: yönlendirmeyi basitleştirir ve kaynak kimliğini yok eder, bu da denetim ve kullanıcı başına kurallar için önemlidir.

İkisinden hangisini seçtiğinizi, ona bağlı olan kuralın yanına yazın.

Uygulama yetkilendirmesi isteğe bağlı değildir

Bir bağlantı noktasına ulaşmak rol vermez. Uygulamanın hâlâ kendi oturum açmasına ve kendi izinlerine ihtiyacı vardır, çünkü ağ katmanı kullanıcının hangi kayıtları düzenleyebileceğini ifade edemez. Dahili alt ağdan gelen her isteğe güvenen bir hizmet, dar bir tüneli ele geçirilmiş tek bir kimlik bilgisi için tam erişime dönüştürür. Tünel soketi kimin açabileceğine, uygulama ise onunla ne yapılabileceğine karar verir.

Burada dar tasarım iki kez karşılığını verir, çünkü daha az erişilebilir ana bilgisayar, uygulama düzeyindeki bir hatanın kötüye kullanılabileceği daha az yer demektir.

Ağ kuralını ve uygulama rolünü ayrı sistemlerde tutun ve onları ayrı ayrı kullanımdan kaldırın.

Hem izin verilen hem de reddedilen yolu kanıtlayın

Yetkili kullanıcı olarak bağlanın ve zararsız bir temsili işlem yapın, ardından ulaşılamaz olması gereken bir hedefi deneyin. Yalnızca ilk yarıyı test eden bir tasarım test edilmemiştir ve tasarımı kanıtlayan reddetme testidir. Her kural değişikliğinden sonra yeni bir oturum test edin ve istekler gelip yanıtlar gelmiyorsa dönüş yoluna bakın.

Kabul testini geçirmek için iletim filtrelerini devre dışı bırakmayın, çünkü bu test edilen şeyi değiştirir.

Kullanıcı artık hizmete ihtiyaç duymadığında, uzak kimliği ve uygulama rolünü ilgili sistemlerinde kullanımdan kaldırın ve ikisini de kaydedin. strongSwan iletim kılavuzu yolun ağ geçidi tarafını kapsar.