Povolit průchozí TLS spojení v kontextu stream v NGINX

NGINX může odmítnout TCP TLS relay, aniž by ukončil TLS. Pravidlo povolení patří do stream, ne do HTTP location, a ověřte, která adresa protějšku přichází.

Předávání šifrovaných bajtů, aniž by se kdy držel certifikát, je to, co dělá relay s průchodem TLS, a to uspořádání je pohodlné a zároveň trochu matoucí. Protože se nic nedešifruje, neexistuje nic v podobě HTTP, podle čeho filtrovat, takže obvyklý blok location a jeho přístupová pravidla zde nemají žádný užitek. Rozhodnutí, které NGINX má, se týká samotného spojení: který síťový protějšek zaklepal a zda má být vůbec propuštěn.

Rozhodnutí patří do stream, ne do HTTP

V kontextu stream pracuje NGINX s TCP relacemi. Vidí adresu protějšku spojení a může na ni použít seřazená pravidla allow a deny dřív, než se jakýkoli bajt dostane do backendu. To je úplné rozhodnutí o přijetí a nevyžaduje soukromý klíč, certifikát ani HTTP parsování.

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

Tyto tři řádky se nikdy nezastupují. Kopírování HTTP direktivy přístupu do souboru, který zmiňuje port 443, nic nezmění, protože server stream nikdy nečte kontext http.

Přijměte spojení dřív, než ho propustíte

Předpokládejte existující instalaci s dostupnými moduly stream a stream-access, VPN klienty, kteří drží zdrojové adresy v 10.90.0.0/24, a backend na 192.168.50.20:443, který už poskytuje zamýšlenou identitu HTTPS.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Čtěte to jako fragment nového listeneru, ne jako přímou náhradu fungující konfigurace. Nejprve projděte existující listenery a include, protože druhý listener na už obsazeném portu selže při reloadu, ne v době požadavku.

Všimněte si, co chybí: žádný listen ... ssl, žádná direktiva certifikátu. NGINX předává šifrovaný proud a backend ukončuje TLS a předkládá certifikát, který klient ověřuje. Klient, který neprojde allowlistem, dostane odmítnutou TCP relaci, ne stránku HTTP 403, a každý nástroj, který očekává stavový kód, ohlásí něco neužitečného.

Co allowlist pokrývá a co ne

Pokud relay už vybírá backendy podle jména serveru, ssl_preread a map mohou tuto práci dělat dál, pokud je modul k dispozici. Jméno stále dodává klient a nic na předložení jména nedokazuje, že se klient připojil k VPN.

Příkladové pravidlo pokrývá celý listener stream. To ho činí nevhodným pro jeden vstupní bod, který obsluhuje směs veřejných a pouze VPN stránek, kde by byla potřeba výjimka pro každé jméno; samostatné listenery jsou obvykle jasnější než politika závislá na jménu, kterou nikdo nedokáže přečíst.

Stojí za to pojmenovat dvě další mezery. Shoda prefixu nic neříká o tom, kterým rozhraním paket přišel, a HTTP pravidlo jinde tento listener omezit nemůže. Obojí jsou důvody držet politiku vstupu na úrovni hostitele v obraze, místo aby se jeden řádek allow považoval za celou hranici. Zapište hranici jako dvě kontroly, které musí souhlasit, aby každá změna kterékoli z nich prošla revizí.

Čí adresu NGINX skutečně vidí?

Nástroj pro vyvažování zátěže, jiný proxy nebo source NAT mohou před NGINX postavit prostředníka, takže protějšek, který vidí, není vnitřní adresa VPN klienta. Před volbou prefixu prozkoumejte skutečnou cestu, protože allowlist napsaný pro špatnou adresu buď pustí všechny za překladačem, nebo nikoho.

Protokol PROXY a zpracování skutečné IP jsou legitimní odpovědi a musí se konfigurovat jen pro kompatibilní, výslovně důvěryhodné odesílatele. Oba mechanismy věří tomu, co odesílatel říká, a právě proto musí být seznam odesílatelů krátký. Důvěra v hlavičku identity od jakéhokoli internetového klienta nečiní zdrojové informace znovu důvěryhodnými; mění správné odmítnutí na padělané přijetí.

Otestujte oba výsledky před reloadem

Ověřte konfiguraci, proveďte reload a pak testujte dvakrát: novou povolenou relaci, která musí fungovat, a odmítnutou, která nesmí. V povoleném testu ponechte běžné ověření certifikátu backendu, protože relay, který se připojí, ale nedokáže backend ověřit, vyřešil jeden problém a vytvořil jiný.

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

Zkontrolujte také trasu k backendu a odpověď zvlášť. Projití allowlistem dokazuje jen to, že NGINX relaci přijal; nemůže přimět nedostupný backend odpovědět a nemůže opravit zpáteční cestu, která chyběla, než jste začali.

Související články