Witryna NGINX tylko dla VPN: listener, firewall i lista dozwolonych HTTP

Prywatna witryna NGINX wymaga powiązanego gniazda VPN, ograniczonej reguły wejścia hosta i nienaruszonej listy dostępu HTTP. Przetestuj wszystkie trzy, nie jeden blok serwera.

Trzy niezależne decyzje stoją między prywatną witryną a internetem: które gniazdo przyjmuje połączenie, która ścieżka może je dostarczyć i którym klientom HTTP odpowiada wybrany serwer. Blok serwera podejmuje tylko pierwszą decyzję. Traktuj pozostałe dwie jako osobne mechanizmy kontroli, inaczej witryna będzie wyglądać na prywatną, a stare wejście pozostanie otwarte. Większość awarii NGINX przeznaczonego tylko dla VPN wynika z testowania wyłącznie pierwszej warstwy.

Przykład używa bramy Linux OpenVPN pod 10.90.0.1 na tun0, klientów w 10.90.0.0/24, zachowanych źródeł i TCP 8443 zarezerwowanego dla tego wejścia. Dostosuj wartości, zachowaj warstwy.

Zacznij od gniazda, nie od nazwy hosta

Powiąż listener HTTPS z adresem tunelu i dedykowanym portem. Konkretny adres łatwiej przemyśleć niż gniazdo wieloznaczne plus sprawdzanie nazwy, ponieważ jądro nie przekaże portu innemu adresowi lokalnemu.

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;
    }
}

Certyfikat musi zawierać nazwę hosta usługi, którą wpisują klienci, a prywatny widok DNS musi rozwiązywać ten host na powiązany adres. server_name tylko wybiera host wirtualny; nikogo nie uwierzytelnia. Brak wpisu DNS powoduje błąd certyfikatu wyglądający jak awaria TLS. Sprawdź nazwę, zanim wymienisz certyfikat.

Przeczytaj obowiązującą konfigurację przed dodaniem pliku. Dołączenia i listenery wieloznaczne mogą obsługiwać ten sam katalog główny gdzie indziej, a serwer domyślny może odpowiadać na żądania, których nowy blok nigdy nie widzi.

Zamknij każdy inny listener dla tej treści

Wypisz dyrektywy listen i porównaj obsługiwane przez nie katalogi główne. Blok dodany dla innej aplikacji może przekazywać do tego samego upstreamu, a stary serwer domyślny może nadal odpowiadać po umieszczeniu nowego. Ten wynik to prawdziwy inwentarz, nie plik, który właśnie edytowałeś. Porównaj każdy katalog główny obsługujący tę samą treść.

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

Sprawdź obie rodziny adresów. Powiązanie IPv4 pozostawia gniazdo IPv6 nietknięte, a nowy rekord A nie wycofuje starej odpowiedzi AAAA wskazującej nadal na publiczną ścieżkę.

Wycofaj stary host wirtualny jako osobną zmianę. Usunięcie publicznego bliźniaka nowego bloku to zwykle krok, który naprawdę zamyka wejście; prywatny listener tylko dodaje zamierzony.

Ogranicz ścieżkę wejściową na hoście

Adres nasłuchu ogranicza gniazdo, a nie interfejs wejściowy. Pakiet trasowany do tego adresu z innego miejsca nadal przychodzi jako wejście lokalne, dlatego firewall hosta potrzebuje własnego oświadczenia o tym, skąd połączenie może przychodzić. Dlatego samo powiązanie rzadko spełnia wymogi audytu.

Przy domyślnej polityce odrzucania ruchu przychodzącego i bez szerszego zezwolenia dla tej usługi ograniczona reguła nazywa razem tunel, zakres źródłowy, cel i port:

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

Przeczytaj obowiązującą kolejność firewalla przed jej zastosowaniem. Wcześniejsza szeroka akceptacja może zniweczyć ograniczenie, a wcześniejsze odrzucenie końcowe może uniemożliwić osiągnięcie tego zezwolenia. Nie czyść niepowiązanych reguł i nie wyłączaj firewalla, aby przykład pasował.

Ta reguła to wejście hosta, a nie trasa do innej maszyny LAN, a zewnętrzny listener OpenVPN bramy pozostaje osobną usługą. Jeśli witryna była wcześniej publiczna, zaplanuj, jak wycofywane jest stare wejście i jak obsługiwane są istniejące sesje.

Utrzymaj listę HTTP nienaruszoną, gdy zmieniają się lokalizacje

NGINX ocenia wpisy allow i deny po kolei, a lista na poziomie serwera powyżej wpuszcza zadeklarowaną pulę przed końcowym deny. Moduł dostępu rejestruje też, że lokalizacja definiująca dowolny wpis dostępu używa własnej listy zamiast listy nadrzędnej. Kolejność ma znaczenie tak samo jak same wpisy.

Ten reset to typowa regresja. Nowa lokalizacja przesyłania, API lub stanu zdrowia, która dodaje jeden wpis, po cichu zastępuje ograniczenie na poziomie serwera, a witryna staje się szersza na ostatnio dodanej ścieżce.

Przejrzyj każdą lokalizację, alias i blok alternatywny jako część tej samej polityki. Jeśli kontrole IP łączą się z uwierzytelnianiem NGINX, zrozum satisfy: ustawienie any może wpuścić klienta jednym mechanizmem, gdy drugi nie przeszedł. Umieść listę dostępu w liście kontrolnej przeglądu lokalizacji.

Odmowa HTTP następuje po dotarciu połączenia TCP do NGINX. Uzupełnia ograniczenie sieciowe, a własna autoryzacja aplikacji nadal dotyczy każdego użytkownika.

Zweryfikuj działającą ścieżkę i przypadek awarii

Uruchom parser konfiguracji, sprawdź nasłuchujące gniazda, a następnie wykonaj nowe nazwane żądanie z zamierzonego klienta. Potwierdź, że certyfikat jest ważny, nazwa DNS rozwiązuje się na powiązany adres, a odpowiedź pochodzi z oczekiwanego katalogu głównego.

Następnie przetestuj wykluczone źródło i alternatywne wejście. Działające dozwolone żądanie nic nie mówi o ścieżkach, które chciałeś zamknąć, a to właśnie w teście wykluczonym ujawnia się pozostały listener lub szeroka akceptacja firewalla.

Powtórz przypadek rozruchu lub odzyskiwania VPN. Jeśli NGINX startuje, zanim istnieje adres tunelu, powiązanie może się nie udać nawet z doskonałym plikiem. Skoryguj gotowość adresu i zachowaj lokalną ścieżkę odzyskiwania przed zmianą współdzielonego serwera WWW.

Zapisz gniazdo, port, zakres źródłowy i listę HTTP, które przeszły. Następna zmiana VPN lub DNS może przesunąć każdy z nich, a cztery nazwane wartości łatwiej porównać niż działającą kartę przeglądarki.

Powiązane artykuły