Squid üzerinden tek bir VPN uç noktası: dar bir CONNECT istisnası

Onaylanmış tek bir kaynağın Squid üzerinden 1194 numaralı bağlantı noktasındaki tek bir VPN ağ geçidine ulaşmasına izin verin, genel bağlantı noktası korumalarını koruyun ve başka hiçbir şeyin açılmadığını kanıtlayın.

Squid, bir CONNECT isteğini eşleşen ilk http_access satırıyla yanıtlar ve bu satır bir ret olabilir. Bu tek gerçek, bir VPN uç noktası istisnasının neden genellikle ilk denemede başarısız olduğunu açıklar, çünkü istek en altta birinin eklediği izne asla ulaşmaz. Dar bir düzeltme mevcut bağlantı noktası korumalarını korur ve onlara incelenmiş tek bir kaynak, hedef ve bağlantı noktası öğretir. Proxy üzerindeki diğer her şey tam olarak eskisi gibi davranır.

Squid bir CONNECT isteğine nasıl karar verir

Bir CONNECT isteği bir ana bilgisayar ve bağlantı noktası belirtir; Squid, http_access satırlarını sırayla dolaşır ve biri eşleşene kadar devam eder. Eşleşen bir ret değerlendirmeyi hemen bitirir ve istemci proxy'den 403 alır. Bu yüzden bir kuralın konumu, ifadesinden daha önemlidir. Aynı satırı bir adım yukarı taşımak sonucu tamamen değiştirebilir.

Geleneksel korumalar Safe_ports dışındaki her şeyi reddeder ve SSL_ports dışındaki CONNECT'i reddeder. Bu adlar kendi yapılandırmanızda tanımlı ACL'lerdir; dolayısıyla içerikleri protokole değil size aittir. Bir dağıtım geniş bir bağlantı noktası aralığına Safe_ports olarak izin verirken CONNECT'i ayrıca sınırlayabilir. Bir bağlantı noktasının tasarım gereği kapalı olduğunu varsaymadan önce canlı değerleri okuyun.

İsteği reddeden bileşenin proxy olduğunu doğrulayın. Squid'in ürettiği 403, VPN sunucusundan gelen bir TLS uyarısına hiç benzemez ve ikisini tek bir sorunda birleştirmek ilk saati alır. İsteğin erişim günlüğü satırını kontrol edin, çünkü hem eylemi hem de onu üreten kuralı kaydeder.

Üç ayrı ACL yerine tek bir birleşik eşleşme kurun

İstisnayı üç olgudan kurun: onaylanmış kaynak aralığı, onaylanmış tek bir hedef adres ve uç noktanın dinlediği tek bağlantı noktası. İki ayrı ACL ve tek bir birleşik eşleşme çok farklı bir politika üretir, çünkü değerlendirilen şey birleşimdir. Birleşik ACL'yi izin verdiği şeye göre adlandırın, taşıdığı yönteme göre değil.

Aşağıdaki biçim, incelenmiş değerlerle değiştirilmesi gereken belge aralıkları kullanır. Squid bu adlardan hiçbirini kendine ayırmaz, dolayısıyla onları seçmek ve tutarlı tutmak size kalmıştır. Bu tarif, belgelenmiş yapılandırması all-of grubunu destekleyen Squid 6 ve 7 ile sınırlıdır. Güncel başvuru bu yönergeleri Squid 8'de kullanılamaz olarak işaretler, bu yüzden bunu bir geçiş yolu değil sürüme bağlı bir tarif olarak görün ve uygulamadan önce yönergeyi kendi sürümünüzün başvurusunda kontrol edin.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

all-of grubu yalnızca her üye eşleştiğinde eşleşir; yani kaynak, hedef ve bağlantı noktası tek satırda denetlenir. Grup tek başına hiçbir şey vermez ve üç olgudan yalnızca ikisiyle eşleşen bir istek onu karşılayamaz. Bu özellik, biri sonradan ikinci bir ağ geçidi eklediğinde istisnayı dar tutar. Ya yeni hedef bilinçli olarak eklenir ya da istek özgün korumalara geri döner.

Bağlantı noktası korumalarını kaldırmadan onları bükün

Mevcut konumlarında iki geleneksel koruma satırı böyle görünür. Genellikle kimlik doğrulamadan sonra ve her şeye izin veren politika satırlarından önce dururlar.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Her birine olumsuzlanmış birleşik eşleşmeyi ekleyin, böylece eşleşen istisna aksi hâlde onu reddedecek bir korumadan sağ çıkar. Yalnızca koruma satırları değişir ve her biri yalnızca bir ek terim alır.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

Tek erişim satırındaki terimler birleştirilir, bu yüzden satır artık yalnızca hem özgün denetimde hem istisnada başarısız olan istekleri reddeder. Onaylanmış uç noktaya giden istek geçer ve diğer her istek eski bağlantı noktası davranışını korur. Bu, bağlantı noktasını genel bir SSL_ports listesine eklemekten daha dardır, çünkü o yöntem bu bağlantı noktasını her hedefe izin verirdi. Bağlantı noktası o listede zaten varsa bu ACL hiçbir şeyi daraltmaz ve daha eski, daha geniş izin diğer hedefler için geçerli olmaya devam eder, bu yüzden istisnanın bağlantı noktasını açtığını iddia etmeden önce canlı listeyi okuyun. Ayrıca geri alınabilir, çünkü iki satır önceki biçimine döner. Erişim denetimi başvurusu bu değişikliğin dayandığı sırayı ve geleneksel korumaları belgeler.

İstisnanın konulmaması gereken yer

Cazibe, korumaların üstüne bir izin koyup işi bitirmektir. Bu yerleştirme aynı zamanda çalışan bir yapılandırmanın tepesine yakın duran kimlik doğrulama ve yerel hedef korumalarını da atlar. Sonuç dar bir istisna değil, üstünde yorum olan bir deliktir. Her yeni izni istemci politikasının geri kalanıyla aynı incelenmiş aşamada tutun.

Bağlantı noktası korumalarından sonra isteğin hâlâ neye ihtiyacı olduğunu kontrol edin. Kimliği doğrulanmış hesap, izin verilen istemci adresi ve hedef politikası hâlâ geçerlidir ve istisna bunlardan hiçbirini değiştirmez. Proxy'niz onaylanmış hesabın keyfi hedeflere ulaşmasına zaten izin veriyorsa, bağlantı noktası koruması hiçbir zaman gerçek denetim olmadı.

Uç noktanın aslında TCP olup olmadığını düşünün. CONNECT istisnası TCP akışları taşır ve UDP kullanan OpenVPN profili bunun üzerinden erişilebilir olmayacaktır. Profili TCP'ye yalnızca sunucu böyle dinliyorsa ve operatör davranış farkını kabul ediyorsa geçirin.

Sınırı ayrıştırıcı ve gerçek bir istekle kontrol edin

Yeniden yüklemeden önce yapılandırmayı ayrıştırın ve bunu yaparken ikinci bir oturumu açık tutun. Yeniden yükleme sırasındaki bir sözdizimi hatası proxy'yi eski yapılandırmada bırakabilir veya yenisini tümüyle reddedebilir. Ayrıştırıcı reddedilen satırı bildirir, bu da istemci hatasının size söyleyeceğinden fazladır.

Ardından yeniden yükleyin ve onaylanmış bir kaynaktan proxy üzerinden gerçek bir CONNECT gönderin. Ayrıştırıcı çalıştırması önce gelir, çünkü yazım hatası olan bir yeniden yükleme size politika hakkında hiçbir şey öğretmez.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

Üç durumu test edin: onaylanmış kaynak ve hesap, onaylanmamış kaynak ve aynı bağlantı noktasında farklı bir hedef. İstisnanın dar olduğunu kanıtlayan üçüncü durumdur, çünkü bağlantı noktasını hedef eşleşmesi olmadan kullanır. İstemci iletisine güvenmek yerine üçü için de erişim günlüğünü okuyun. Başarılı bir CONNECT yalnızca bir TCP akışı kurar ve fazlasını değil, bu yüzden VPN el sıkışması ayrı bir test olarak kalır.

İlgili makaleler