Yalnızca VPN için NGINX sitesi: dinleyici, güvenlik duvarı ve HTTP izin listesi

Özel bir NGINX sitesi bağlı bir VPN soketi, sınırlandırılmış ana makine giriş kuralı ve eksiksiz bir HTTP erişim listesi gerektirir. Yalnızca bir sunucu bloğunu değil, üçünü de test edin.

Özel bir site ile internet arasında üç bağımsız karar vardır: hangi soketin bağlantıyı kabul ettiği, hangi yolun onu teslim edebileceği ve seçilen sunucunun hangi HTTP istemcilerine yanıt verdiği. Sunucu bloğu yalnızca ilk kararı verir. Diğer ikisini ayrı kontroller olarak ele alın, yoksa eski bir giriş açık kalırken site özel görünür. Yalnızca VPN için tasarlanmış NGINX arızalarının çoğu yalnızca ilk katmanı test etmekten kaynaklanır.

Örnek, tun0 üzerinde 10.90.0.1 adresindeki Linux OpenVPN ağ geçidini, 10.90.0.0/24 içindeki istemcileri, korunan kaynakları ve bu giriş için ayrılmış TCP 8443'ü kullanır. Değerleri uyarlayın, katmanları koruyun.

Ana makine adıyla değil, soketle başlayın

HTTPS dinleyicisini tünel adresine ve ayrı bir bağlantı noktasına bağlayın. Belirli bir adresi düşünmek, joker soket artı ad denetiminden daha kolaydır, çünkü çekirdek bağlantı noktasını başka bir yerel adrese vermez.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

Sertifika, istemcilerin yazdığı hizmet ana makine adını içermeli ve özel DNS görünümü bu ana makineyi bağlı adrese çözmelidir. server_name yalnızca bir sanal ana makine seçer; kimseyi kimlik doğrulamaz. Eksik bir DNS kaydı, TLS arızası gibi görünen bir sertifika hatası üretir. Sertifikayı değiştirmeden önce adı denetleyin.

Dosyayı eklemeden önce etkin yapılandırmayı okuyun. Ekleme ve joker dinleyiciler aynı kökü başka bir yerde sunabilir ve varsayılan sunucu, yeni bloğun hiç görmediği isteklere yanıt verebilir.

O içerik için diğer her dinleyiciyi kapatın

listen yönergelerini listeleyin ve sundukları kökleri karşılaştırın. Başka bir uygulama için eklenen blok aynı upstream'e vekillik edebilir ve eski varsayılan sunucu yenisi yerine oturduktan sonra da yanıt vermeye devam edebilir. Bu çıktı gerçek envanterdir, az önce düzenlediğiniz dosya değil. Aynı içeriği sunan her kökü karşılaştırın.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

Her iki adres ailesini denetleyin. IPv4 bağlama bir IPv6 soketini dokunulmadan bırakır ve yeni A kaydı hâlâ genel bir yolu gösteren eski AAAA yanıtını geri çekmez.

Eski sanal ana makineyi ayrı bir değişiklik olarak kullanımdan kaldırın. Yeni bloğun genel ikizini kaldırmak genellikle girişi gerçekten kapatan adımdır; özel dinleyici yalnızca amaçlananı ekler.

Gelen yolu ana makinede sınırlandırın

Dinleme adresi soketi sınırlar, giriş arabirimini değil. Başka bir yerden o adrese yönlendirilen paket yine de yerel girdi olarak gelir, bu nedenle ana makinenin güvenlik duvarının bağlantının nereden gelebileceğine dair kendi beyanı gerekir. Bu yüzden yalnızca bağlama bir denetimi nadiren karşılar.

Varsayılan reddetme gelen politikası ve bu hizmet için daha geniş bir izin olmadığında, sınırlandırılmış bir kural tüneli, kaynak aralığını, hedefi ve bağlantı noktasını birlikte adlandırır:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

Uygulamadan önce güvenlik duvarının etkin sırasını okuyun. Daha önceki geniş bir kabul kısıtlamayı geçersiz kılabilir ve daha önceki bir terminal düşürme bu izne hiç ulaşılamamasına yol açabilir. Örneğin uyması için ilgisiz kuralları temizlemeyin ve güvenlik duvarını kapatmayın.

Bu kural ana makine girişidir, başka bir LAN makinesine giden yol değildir ve ağ geçidinin dış OpenVPN dinleyicisi ayrı bir hizmet olarak kalır. Site daha önce genel idiyse, eski girişin nasıl kullanımdan kaldırılacağını ve mevcut oturumların nasıl ele alınacağını planlayın.

Konumlar değişirken HTTP listesini eksiksiz tutun

NGINX, allow ve deny girdilerini sırayla değerlendirir ve yukarıdaki sunucu düzeyi liste, son deny'den önce bildirilen grubu kabul eder. Erişim modülü ayrıca herhangi bir erişim girdisi tanımlayan konumun üst liste yerine kendi listesini kullandığını kaydeder. Sıra, girdilerin kendisi kadar önemlidir.

Bu sıfırlama olağan gerilemedir. Bir girdi ekleyen yeni yükleme, API veya sağlık konumu, sunucu düzeyi kısıtlamayı sessizce değiştirir ve site en son eklenen yolda daha geniş olur.

Her konumu, diğer adı ve alternatif bloğu aynı politikanın parçası olarak gözden geçirin. IP denetimleri NGINX kimlik doğrulamasıyla birleştirilmişse satisfy ayarını anlayın: any ayarı bir istemciyi bir mekanizmayla geçirebilirken diğeri henüz geçmemiş olabilir. Erişim listesini konum inceleme kontrol listesine koyun.

Bir HTTP reddi, TCP bağlantısı NGINX'e ulaştıktan sonra gerçekleşir. Ağ kısıtlamasını tamamlar ve uygulamanın kendi yetkilendirmesi her kullanıcı için geçerli olmaya devam eder.

Canlı yolu ve hata durumunu doğrulayın

Yapılandırma ayrıştırıcısını çalıştırın, dinleyen soketleri inceleyin, ardından amaçlanan istemciden yeni adlandırılmış bir istek yapın. Sertifikanın doğrulandığını, DNS adının bağlı adrese çözüldüğünü ve yanıtın beklenen kökten geldiğini doğrulayın.

Ardından hariç tutulan bir kaynağı ve alternatif bir girişi test edin. Çalışan izinli bir istek, kapatmak istediğiniz yollar hakkında hiçbir şey söylemez ve kalan bir dinleyici ya da geniş bir güvenlik duvarı kabulü tam da hariç tutulan testte ortaya çıkar.

Önyükleme veya VPN kurtarma durumunu yineleyin. NGINX tünel adresi var olmadan başlarsa, kusursuz bir dosyayla bile bağlama başarısız olabilir. Adres hazırlığını koordine edin ve paylaşılan bir web sunucusunu değiştirmeden önce yerel bir kurtarma yolu bulundurun.

Geçen soketi, bağlantı noktasını, kaynak aralığını ve HTTP listesini kaydedin. Sonraki VPN veya DNS değişikliği bunlardan herhangi birini kaydırabilir ve dört adlandırılmış değeri karşılaştırmak çalışan bir tarayıcı sekmesinden daha kolaydır.

İlgili makaleler