NGINX stream bağlamında TLS passthrough bağlantısına izin verme

NGINX, TLS-i sonlandırmadan bir TCP TLS aktarımını reddedebilir. İzin kuralını HTTP location-da değil stream-de tutun ve hangi peer adresinin geldiğini kontrol edin.

Şifrelenmiş baytları sertifikayı hiç tutmadan iletmek TLS passthrough aktarımının yaptığı iştir ve bu düzenleme hem kullanışlı hem de biraz kafa karıştırıcıdır. Hiçbir şey çözülmediği için filtrelenecek HTTP biçiminde bir şey yoktur, bu yüzden olağan location bloğu ve erişim kuralları burada işe yaramaz. NGINX-in sahip olduğu karar bağlantının kendisiyle ilgilidir: hangi ağ peer-ı kapıyı çaldı ve o peer hiç iletilecek mi.

Karar HTTP-de değil, stream-de

stream bağlamında NGINX TCP oturumlarıyla çalışır. Bağlantının peer adresini görür ve herhangi bir bayt backend-e ulaşmadan önce ona sıralı allow ve deny kuralları uygulayabilir. Bu tam bir kabul kararıdır ve özel anahtar, sertifika veya HTTP ayrıştırması gerektirmez.

MechanismWhat it decidesWhere it lives
stream allow/denyWhether this TCP peer is relayedstream server block
ssl_preread mapWhich backend a named connection goes tostream, with the preread module
HTTP location ruleWhether an HTTP request is servedhttp server block

Bu üç satır asla birbirinin yerini almaz. HTTP erişim yönergesini 443 portundan söz eden herhangi bir dosyaya kopyalamak hiçbir şeyi değiştirmez, çünkü stream sunucusu http bağlamını asla okumaz.

Bağlantıyı iletmeden önce kabul edin

stream ve stream-access modüllerinin bulunduğu mevcut bir kurulum, kaynak adreslerini 10.90.0.0/24 içinde tutan VPN istemcileri ve 192.168.50.20:443 adresinde amaçlanan HTTPS kimliğini zaten sunan bir backend varsayın.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Bunu çalışan bir yapılandırmanın doğrudan yerine geçen değil, yeni bir listener-ın parçası olarak okuyun. Önce mevcut listener-ları ve include-ları gözden geçirin, çünkü zaten bağlı bir porttaki ikinci listener istek anında değil reload sırasında başarısız olur.

Neyin eksik olduğuna dikkat edin: listen ... ssl yok, sertifika yönergesi yok. NGINX şifrelenmiş akışı iletir ve backend TLS-i sonlandırıp istemcinin doğruladığı sertifikayı sunar. allowlist-i geçemeyen istemcinin TCP oturumu reddedilir, HTTP 403 sayfası değil, ve durum kodu bekleyen her araç işe yaramaz bir şey bildirir.

allowlist neyi kapsar, neyi kapsamaz

Aktarım backend-leri zaten sunucu adına göre seçiyorsa, modül mevcutsa ssl_preread ve map bu işi sürdürebilir. Adı hâlâ istemci sağlar ve bir ad sunmak istemcinin VPN-e katıldığını kanıtlamaz.

Örnek kural tüm stream listener-ını kapsar. Bu, onu genel ve yalnızca VPN sitelerinin karışımını sunan tek bir giriş noktası için uygunsuz kılar, orada her ad için istisna gerekirdi; ayrı listener-lar genellikle kimsenin okuyamadığı ada bağlı bir politikadan daha açıktır.

İki boşluğu daha anmak gerekir. Önek eşleşmesi paketin hangi arayüzden geldiğini söylemez ve başka bir yerdeki HTTP kuralı bu listener-ı kısıtlayamaz. İkisi de tek bir allow satırını tüm sınır saymak yerine ana bilgisayar düzeyindeki ingress politikasını resimde tutmanın nedenleridir. Sınırı, herhangi birindeki değişikliğin gözden geçirilmesi için uyuşması gereken iki denetim olarak yazın.

NGINX gerçekte kimin adresini görür?

Bir yük dengeleyici, başka bir proxy veya source NAT NGINX-in önüne bir aracı koyabilir, bu yüzden görülen peer VPN istemcisinin iç adresi değildir. Önek seçmeden önce gerçek yolu inceleyin, çünkü yanlış adres için yazılmış bir allowlist ya çevirici arkasındaki herkesi kabul eder ya da kimseyi.

PROXY protokolü ve gerçek IP işleme meşru yanıtlardır ve yalnızca uyumlu, açıkça güvenilen göndericiler için yapılandırılmalıdır. Her iki mekanizma da göndericinin söylediğine inanır ve gönderici listesinin kısa olmasının nedeni tam olarak budur. Herhangi bir internet istemcisinden gelen kimlik başlığına güvenmek kaynak bilgisini yeniden güvenilir kılmaz; doğru bir reddi sahte bir kabule dönüştürür.

reload öncesinde iki sonucu da test edin

Yapılandırmayı doğrulayın, reload yapın, ardından iki kez test edin: çalışması gereken yeni izinli bir oturum ve çalışmaması gereken reddedilmiş bir oturum. İzinli testte normal backend sertifika doğrulamasını koruyun, çünkü bağlanan ama backend-i doğrulayamayan bir aktarım bir sorunu çözmüş ve başka bir sorun yaratmıştır.

nginx -t
ss -tnp | grep ':443'

backend-e giden yolu ve yanıtı ayrı ayrı da kontrol edin. allowlist-i geçmek yalnızca NGINX-in oturumu kabul ettiğini kanıtlar; erişilemeyen bir backend-i yanıt vermeye zorlayamaz ve başlamadan önce eksik olan bir dönüş yolunu onaramaz.

İlgili makaleler