Permite o conexiune TLS passthrough în contextul stream al NGINX

Trimiterea mai departe a octeților criptați fără a deține vreodată certificatul este ceea ce face un relay TLS passthrough, iar aranjamentul este comod și totodată puțin confuz. Deoarece nimic nu este decriptat, nu există nimic în formă de HTTP pe care să filtrezi, așa că blocul location obișnuit și regulile sale de acces nu folosesc la nimic aici. Decizia de care dispune NGINX privește conexiunea în sine: ce peer de rețea a bătut și dacă acel peer trebuie trimis mai departe.

Decizia aparține lui stream, nu lui HTTP

În contextul stream NGINX lucrează cu sesiuni TCP. Vede adresa de peer a conexiunii și poate aplica asupra ei reguli allow și deny ordonate înainte ca vreun octet să ajungă la backend. Este o decizie completă de admitere și nu necesită cheie privată, certificat sau analiză HTTP.

Acele trei linii nu se înlocuiesc niciodată una pe alta. Copierea unei directive de acces HTTP în fișierul care menționează portul 443 nu schimbă nimic, pentru că serverul stream nu citește niciodată contextul http.

Admite conexiunea înainte de a o trimite mai departe

Presupune o instalare existentă cu modulele stream și stream-access disponibile, clienți VPN care păstrează adrese de sursă în 10.90.0.0/24, și un backend la 192.168.50.20:443 care servește deja identitatea HTTPS dorită.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Citește asta ca un fragment de listener nou, nu ca o înlocuire directă a unei configurații funcționale. Verifică mai întâi listenerele și include-urile existente, pentru că un al doilea listener pe un port deja ocupat eșuează la reload, nu la momentul cererii.

Observă ce lipsește: niciun listen ... ssl, nicio directivă de certificat. NGINX trimite mai departe fluxul criptat, iar backendul termină TLS și prezintă certificatul pe care clientul îl validează. Un client care nu trece de allowlist primește sesiunea TCP respinsă, nu o pagină HTTP 403, iar orice instrument care așteaptă un cod de stare va raporta ceva inutil.

Ce acoperă allowlist-ul și ce nu

Dacă relay-ul alege deja backenduri după numele serverului, ssl_preread și un map pot continua acea muncă, cu condiția ca modulul să fie disponibil. Numele este încă furnizat de client, iar nimic din prezentarea unui nume nu dovedește că clientul s-a alăturat VPN-ului.

Regula din exemplu acoperă întregul listener stream. Asta o face nepotrivită pentru un singur punct de intrare care servește un amestec de site-uri publice și site-uri doar pentru VPN, unde ar fi nevoie de o excepție pe nume; listenerele separate sunt de obicei mai clare decât o politică dependentă de nume pe care nimeni nu o poate citi.

Merită numite încă două lacune. O potrivire de prefix nu spune nimic despre interfața pe care a sosit pachetul, iar o regulă HTTP în altă parte nu poate restricționa acest listener. Ambele sunt motive să păstrezi politica de intrare la nivel de host în imagine în loc să tratezi o singură linie allow ca întreaga frontieră. Scrie frontiera ca două controale care trebuie să fie de acord, astfel încât orice modificare la oricare dintre ele să fie revizuită.

A cui adresă vede NGINX de fapt?

Un balansator de încărcare, un alt proxy sau un source NAT pot pune un intermediar în fața NGINX, așa că peer-ul observat nu este adresa internă a clientului VPN. Inspectează calea reală înainte de a alege un prefix, pentru că un allowlist scris pentru adresa greșită fie admite pe toată lumea din spatele traducătorului, fie pe nimeni.

Protocolul PROXY și tratarea IP-ului real sunt răspunsuri legitime și trebuie configurate doar pentru expeditori compatibili și în mod explicit de încredere. Ambele mecanisme cred ce spune expeditorul, și exact de aceea lista expeditorilor trebuie să fie scurtă. Încrederea într-un antet de identitate de la orice client de internet nu face din nou informațiile de sursă de încredere; transformă un refuz corect într-o acceptare falsificată.

Testează ambele rezultate înainte de reload

Validează configurația, fă reload, apoi testează de două ori: o sesiune nouă permisă care trebuie să funcționeze și una respinsă care nu trebuie. Păstrează verificarea normală a certificatului backend în testul permis, pentru că un relay care se conectează dar nu poate valida backendul a rezolvat o problemă și a creat alta.

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

Verifică separat și ruta către backend și răspunsul. Trecerea de allowlist dovedește doar că NGINX a acceptat sesiunea; nu poate face un backend inaccesibil să răspundă și nu poate repara o cale de întoarcere care lipsea înainte de a începe.