VPN ile bağlanan iki ofis arasındaki erişim nasıl sınırlandırılır

Siteden siteye tünel tek bir soruyu yanıtlar, iki ofis paket alışverişi yapabilir mi, ve önemli olanı açık bırakır: hangi şube cihazı hangi merkezi hizmete erişebilir. Tüneli karşılıklı güven olarak görmek, konuk dizüstü bilgisayarın finans sunucusuyla aynı yola çıkmasının yoludur. Çözüm daha iyi bir tünel değil, şifre çözüldükten sonra uygulanan açık bir izin listesidir. Bu kılavuz o listeyi tanımdan kanıtlanmış bir redde taşır.

Bu sırayla çalışın ve aşağıdaki politika adımları geçmeden tünel rotasını genişletmeyin.

Ağ geçidine dokunmadan önce matrisi yazın

İşe yarar bir satır üç şeyi adlandırır: kaynak grubu, hedef ana bilgisayar veya hizmet ağı, ve uygulamanın gerçekten kullandığı protokol ile bağlantı noktası. Şube ve veri merkezi giriş değildir. Özel DNS ve kimlik doğrulama hizmetleri kendi satırlarını yalnızca uygulama onlar olmadan çalışamadığında kazanır.

Kaynakları alt ağ kolaylığına göre değil role göre gruplayın: personel, konuklar, yönetim. Üçü de tek bir düz LAN paylaştığında ağ geçidi onları ağ katmanında ayıramaz, bu yüzden kimlik denetimleri veya segmentasyon önce gelmelidir. Ardından matrisi her satırda bir sahip ve bir gözden geçirme tarihiyle yazılı hale getirin.

Paketlerin şifresinin çözüldüğü yerde uygulayın

IKE ve ESP'ye izin veren kurallar yalnızca dış tüneli kurar. İç trafik tünel arayüzüne açık olarak gelir ve izin listesinin yeri tam orasıdır: şifreyi çözen cihazda yönlendirme zinciri, varsayılan bırakma, matrisin her satırı için bir kural. Linux ağ geçitlerinde bu, yönlendirmenin açık olduğu ve filtre kurallarının fiziksel bağlantıda değil tünel cihazında bulunduğu anlamına gelir, strongSwan yönlendirme kılavuzunun açıkladığı gibi.

Trafik seçicileri bir yönlendirme kararıdır, yetkilendirme kararı değil. İki alt ağı da kapsayan geniş bir seçici yönlendirme için doğru olabilirken güvenlik duvarı hâlâ yalnızca bir ana bilgisayara TCP 443'e izin verir. Seçici tünel için müzakere edilir ve içine neyin girebileceğini tanımlar, belirli bir cihazın neyi kullanabileceğini değil. Seçici geniş diye güvenlik duvarı kuralını asla genişletmeyin.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT ve çakışan alt ağlar kuralları değiştirir

Şube ağ geçidi tünelden önce her ana bilgisayarı tek bir adrese çevirdiğinde, kaynağa dayalı her satır o tek adreste çöker. Ya tünel trafiğini çevirmeyi bırakın, ya da kuralların başka bir şeye, örneğin çeviriden önce kaydedilen özgün kaynak adresine dayanması gerektiğini kabul edin. Uzak uçta da aynı sorun var, çünkü hedef ana bilgisayar özgün adresi değil NAT sonrası adresi görür.

Çakışan aralıklar diğer tuzaktır. İkisi de 192.168.1.0/24 kullanan iki ofis, bir tarafı eşlemeden tek bir politika tablosunda tanımlanamaz ve eşleme çakışmayan adreslemenin yerini tutmaz. Sonra çözmeniz gereken kuralları yazmadan önce planı düzeltin.

Reddi kanıtlayın, yalnızca başarıyı değil

Yalnızca izin verilen uygulamayı test etmek çok az şey kanıtlar, çünkü yukarıda bir yerde gevşek bir kural aynı sonucu verir.

Sıradan bir şube cihazından amaçlanan hizmete ulaşın ve tüm oturumun çalıştığını doğrulayın. Sonra kapalı kalması gereken bir hedefi deneyin, örneğin şubenin hiçbir işi olmayan bir sunucudaki yönetici bağlantı noktasını, ve onu düşüren sayacı veya günlük kaydını okuyun. Kural kümesini çalışıp çalışmadığını görmek için kapatmak testi geçersiz kılar ve siz bakarken ağ geçidini açık bırakır.

Listeyi canlı tutun

Uygulamalar taşınır ve kendi uygulamasından daha uzun yaşayan bir kural, kimsenin sahip olmadığı bir deliğe dönüşür. Gözden geçirme tarihini satıra bağlayın ve bir hizmet adres değiştirdiğinde seçicinin kapsamını ve güvenlik duvarı kuralını aynı bakım adımında değiştirin.

Ana bilgisayar düzeyindeki kısıtlamalar tünelin arkasında da önemlidir: sunucunun kendi güvenlik duvarı şube aralığını yalnızca yayımladığı hizmet için kabul etmelidir. Birbirini tutan iki katman, tamamen güvenilen tek katmandan daha kolay denetlenir.