Ofis ve VPN için tek URL? İzin listesi miti neden çöker

Tüneli bağlayın, aynı yer imini açın ve izinli site ofisten yanıt verdiği gibi tam olarak yanıt verir. Bu, uzaktan erişim planlarının çoğunun sessizce dayandığı varsayımdır ve yalnızca üç ayrı şey aynı anda doğru kaldığı sürece geçerlidir. Hiçbiri VPN istemcisinin bir özelliği değildir ve hiçbir DNS kaydı bunlardan birini sağlayamaz. Yer imi evde başarısız olduğunda, tarayıcı size tek bir genel hata verir; nedeni eksik bir rota, onaylanmamış bir çıkış adresi ya da bildirdiği kaynağı değiştiren bir proxy olsun fark etmez. Bu üçünü tek bir sorun olarak ele almak, küçük bir ilke düzeltmesinin izin listelerini genişletmeye ayrılan bir haftaya dönüşmesinin yoludur.

Gerçek bir ofis ağıyla temas ettiğinde ayakta kalan tasarım, varsayımdan daha dardır: üç satırlık açık bir karar tablosu, atlanamayan tek bir uygulama noktası ve bir şeyi kanıtlayan bir ret testi. Varsayımı çözmek önce gelir, çünkü sonrasındaki her şey kaynağı hangi katmanın yanlış temsil ettiğini bilmeye bağlıdır.

Mit: bağlanmak yönlendirme değildir

Bir tünel kurulur ve istemci belirli bir önek kümesi için rotalar yükler. Bağlanmanın yaptığı tek şey budur. İlgisiz bir HTTPS isteğinin tünelden geçip geçmeyeceği ve vardığında hangi genel adresten geliyor göründüğü, sonradan başka bileşenlerin verdiği kararlardır: yönlendirme tablosu yolu seçer, çıkış ise kaynağı seçer.

Bu yüzden aynı dizüstü bilgisayar, aynı tarayıcı profili ve aynı yer imiyle ofis ile mutfak masası ayrışır. Ofiste istek, site işletmecisinin kabul ettiği bakımlı bir genel adresten çıkar. Tam tünel üzerinden VPN çıkışından çıkabilir; bu başka bir adrestir ve biri ekleyene kadar onaylanmamıştır. Bölünmüş tünel üzerinden tünele hiç girmeyebilir. O üç yolun yalnızca ikisi site sahibiyle yapılan anlaşmanın parçasıydı ve üçüncüsü ekstra bir allow satırıyla yamanacak bir kusur değildir.

Üç istek durumu, iki onaylı çıkış

Güvenlik duvarına dokunmadan önce matrisi yazın, çünkü tablo tasarımdır ve kural onun yalnızca bir uygulamasıdır. Aşağıdaki adresler belgeleme aralıklarıdır; bunları kendi bakımlı değerlerinizle değiştirin ve site sahibinin denetleyebileceği bir yerde saklayın.

Bu planların çoğu tam orta satırda kırılır. Önemli olan, uygulama aygıtının gördüğü adrestir; dizüstü bilgisayarın tünel içinde tuttuğu özel adres değil, LAN adresi de değil. 10.8.0.6 gibi bir değer genel bir site için hiçbir şey ifade etmez, 192.168.1.44 de etmez. Tünel adresi tünelin adresleme ayrıntısıdır, sitenin doğrulayabileceği bir kimlik bilgisi değildir.

VPN'iniz istikrarlı ve belgelenmiş bir çıkış sağlayamıyorsa matrisin geçerli bir orta satırı yoktur ve hiçbir miktarda izin listesi bir tane uydurmaz. O noktadaki dürüst seçenekler, açık özel rotalarla erişilen özel bir site ya da uygulamanın önünde kimlik farkındalıklı bir erişim geçididir. İkisinin de genel bir izin listesinden farklı bir sözleşmesi vardır ve ikisini de bir denetçiye anlatmak, tesadüfen çalışana kadar büyümüş bir listeden daha kolaydır.

Kaynağı kararın verildiği yerde okuyun

Kısıtlamayı isteği sonlandıran aygıta koyun ve hiçbir alternatif kaynak yolunun onu atlamadığını doğrulayın. Nginx erişim modülü allow ve deny yönergelerini sırayla değerlendirir, ilk eşleşme kazanır ve çevreleyen bloktan devralınan kurallar location içinde hâlâ geçerlidir. Aynı yerde dar bir allow'un yanında geniş bir allow olması genellikle geniş olanın karar verdiği anlamına gelir. O location için tüm geçerli yapılandırmayı, tek bir satırını bile düzenlemeden önce okuyun.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Bir yük dengeleyicinin veya ters proxy'nin arkasında, o kural aksini söylemediğiniz sürece proxy'yi görür. Arayanın adresini yalnızca desteklenen güvenilen proxy mekanizmasıyla, açık bir proxy adresi listesiyle geri yükleyin. Onaylanmış bir adres iddia eden istek başlığı, arayanın ona sahip olduğunun kanıtı değildir ve genel bir dinleyicide doğrulanmamış iletilmiş başlık izin listesini süslemeye çevirir.

Sonra diğer adres ailesini denetleyin. Yalnızca IPv4'ü kapsayan bir kural kümesi, AAAA üzerinde de yanıt veren bir ana makine adı için eksik bir karardır ve çalışan IPv6'ya sahip bir istemci aynı uygulamaya hiç incelemediğiniz bir yoldan ulaşır.

Bölünmüş tünel: asla içeri girmeyen istek

Bölünmüş tünel yalnızca listesindeki önekleri taşır. Ofisin iç alt ağları genellikle o listede yer alır; genel bir web sitesi almaz. Tarayıcı adı çözer, seçilen adresi yönlendirme tablosuyla karşılaştırır ve yine de önünde yerel varsayılan geçidi bulur.

Böylece istek kullanıcının ev bağlantısından gelir, reddedilir ve rapor VPN'in bozuk olduğunu söyler; oysa tünel tam olarak yapılandırıldığı işi yapmaktadır. İki düzeltme meşrudur: o hedefi tünelden geçirin ve onaylı çıkışın onu taşımasına izin verin ya da sitenin doğrudan erişildiğini kabul edip uzak kullanıcılara erişim geçidi gibi başka bir onaylı yol verin. Sitenin genel izin listesini bir ev adresi tesadüfen içeri girene kadar genişletmek ikisi de değildir ve tasarımın uygulaması gereken sınırı ortadan kaldırır. İlk ikisi matrisi dürüst tutar; üçüncüsü ondan sessizce bir satır siler.

Reddi kanıtlayın, sonra kurtarmayı

Tablonun her satırında duran bir istemciden gerçek kararı uygulayan bir istekle test edin. İlgisiz bir adres gösteren sayfaya karşı yapılan erişilebilirlik denetimi hiçbir şeyi kanıtlamaz, çünkü o hedef uygulamadan farklı bir yol izleyebilir.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Sınırdaki erişim kaydını tablonun öngördüğüyle karşılaştırın. Sonra tüneli indirin ve reddedilmesi gereken yeni bir istek yapın; zaten yüklenmiş bir sayfa veya zaten açık bir bağlantı hiçbir şeyi test etmez. Hiç ret görünmüyorsa uygulama noktası sandığınız yerde değildir.

Ağa kabulden sonra uygulama kimlik doğrulamasını koruyun, çünkü ofis çıkışı ve VPN çıkışı her biri birçok insanı temsil eder ve hiçbiri bir bireyi tanımlamaz. Kullanıcılar için talimat kısa kalır: onaylı tüneli kaldırın, sonra yeniden deneyin. Bir URL'yi kullanışlı tutan ve kaynak kuralını tahmin değil karar olarak koruyan şey budur.