Nginx framan við, einkabakendi bak við VPN-ið

Fylgdu einni beiðni frá síma í lest að bakenda sem er aðeins til inni í einkaneti. Síminn leysir opinbert nafn, tengist opinberu vistfangi á gátt 443 og klárar venjulega TLS-handstöðu. Nginx tekur við þeirri tengingu og opnar síðan aðra, algjörlega aðskilda, að vistfangi sem það nær aðeins í gegnum VPN-viðmót. Ekkert við símann breytist, og síminn kemst aldrei að því að göng voru í spillunum.

Fylgja einni beiðni í gegnum tvær tengingar

Inngangsleggurinn er opinber HTTP-færsla. Hann hefur opinbert nafn, opinbert skírteini og svarleið sem verður að virka fyrir hvaða vistfang sem gesturinn kann að hafa á hverri stundu. Sérhver breyting sem truflar þá leið brýtur alla gesti í einu. Þess vegna er opinberi leggurinn sá sem þú vilt síst gera tilraunir á.

Útgangsleggurinn er einkalegur. Nginx verður biðlari, leysir innra nafn eða notar fast vistfang, og nær í þjónustu sem myndi hafna tengingu frá internetinu.

Public client  -> frontend public address:443   (TLS, public name)
Frontend       -> VPN private backend 10.40.0.20:8443  (TLS, private name)

Haltu þeim aðskildum í höfðinu og stillingarnar verða augljósar. Blandaðu þeim saman og þú endar á að reyna að láta opinberan biðlara taka þátt í göngum, og þaðan kemur stærsti hluti ruglingsins í þessari hönnun. Einkaleggi leggurinn má vera viðkvæmur. Opinberi leggurinn ekki.

Áður en þú byggir nokkuð af þessu skaltu staðfesta að birtin sé viljandi. Vinnandi milliþjónn er líka vinnandi berskjöldun, og auðkenningarlíkanið verður að vera ákvörðun en ekki aukaverkun.

Nafn gáttarinnar verður að lifa göngin af

Lúmsk gildra liggur í nafnaupplausn. Ef einkadns yfirskrifar sama nafn og VPN-sniðið notar fyrir sína eigin gátt, getur endurtenging endað með að reyna að ná í þá gátt gegnum göngin sem hún á að koma á. Biðlarinn þarf að fá nafnið leyst áður en göngin eru til. Þegar það hefur verið leyst inni í göngunum er aldrei hægt að byggja tenginguna.

Notaðu aðskilin samþykkt nöfn fyrir gáttina og bakendann, og afmarkaðu stefnu leysisins þannig að hvert nafn leysist í það vistfang sem notandi þess þarf. Að breyta Host-haus forrits gerir ekkert fyrir þetta vandamál, því VPN-biðlarinn er sá sem framkvæmir uppflettinguna.

Hugsaðu síðan um umfang. Framendinn þarf leið að vistfangi bakendans, og hann þarf líka að halda áfram að svara opinberum biðlurum. Full göng á þeim hýsli geta uppfyllt fyrstu kröfuna og brotið þá seinni.

Þar sem stefnan leyfir er göng að tilteknum áfangastað hreinna hönnunin. Þar sem stefnan krefst fullra ganga á framendinn heima í aðskildum netheimi í stað þess að vera bættur með lausaskotnum leiðum fyrir þekkta gesti.

Skrifaðu netþjónsblokkina þannig að báðir leggir sannprófi

Gerðu ráð fyrir að bakendinn sýni skírteini fyrir backend.corp.example og svari á einkavistfangi. Að tengja við vistfang á meðan nafn er sannprófað er einmitt tilgangur SNI- og nafnvalkostanna í milliþjóns-einingunni.

upstream private_app {
    server 10.40.0.20:8443;
}

server {
    listen 443 ssl;
    server_name app.example.com;

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

    location / {
        proxy_pass https://private_app;
        proxy_ssl_server_name on;
        proxy_ssl_name backend.corp.example;
        proxy_ssl_trusted_certificate /etc/nginx/trust/backend-ca.pem;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 3;

        proxy_set_header Host app.example.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

Sérhver slóð og vistfang hér að ofan er staðgengill. Mikilvægu hlutarnir eru þeir sem halda sannprófuninni kveiktri: nafn til að athuga, traustbúnt til að athuga það gegn og dýpt sem passar við samþykktu keðjuna.

proxy_set_header Host app.example.com er viljandi. Bakendinn ætti að vera stilltur til að samþykkja þennan opinbera uppruna, og hann ætti aðeins að treysta áframmiðluðum hausum frá þessum framenda. Að yfirskrifa X-Forwarded-For með biðlaravistfanginu er rétt fyrir einn milliþjón og rangt fyrir keðju, svo uppsetning með mörgum milliþjónum þarf sína eigin ráðstöfun traustra vistfanga.

Láta opinbera upprunann hegða sér sem slíkan

Forritið ætti að senda algera slóð, endurbeiningar og vafrakökur fyrir opinbera upprunann. Ef það endurbeinir gesti til backend.corp.example, er þeim gesti sent á nafn sem þeir geta ekki leyst.

Lagaðu það með studdu stillingu forritsins fyrir ytri slóð og endurskoðaðri endurbeiningarstefnu, ekki með því að endurskrifa hýsilnöfn í svarlíkömum. Strengjaskipti yfir handahófskennt efni brýtur undirrituð hleðslur og skapar villur sem erfitt er að rekja.

Vafrakökur eiga skilið sömu umhyggju. Vafrakaka bundin einkanafninu verður aldrei send af vafra sem þekkir aðeins það opinbera.

Staðfestu líka að Nginx geti raunverulega átt opinbera tengið. Núverandi vefþjónusta á 443 verður að flytja eða framendinn verður að búa annars staðar, því tvö ferli geta ekki bundið sama vistfang og sömu gátt.

Athugaðu hvern legg þar sem hann keyrir í raun

Sannprófaðu stillingarnar með uppsettu þáttaranum fyrir hverja endurhleðslu, svo innsláttarvilla felli ekki hlustandann sem þjónar núna.

Prófaðu síðan bakendalegginn frá framenda-hýslinum sjálfum, í sama netheimi og Nginx notar. Ping gegnum göngin sannar náanleika og ekkert um TLS, heimild eða forritið.

Að lokum skaltu gera nýja opinbera beiðni á raunverulega hýsilnafnið með venjulegri skírteinissannprófun, og fylgjast með svarleiðinni frekar en bara svarhleðslunni.

Geymdu báðar athuganir með uppsettu stillingunum og skráðu hvað gerist þegar göngin eru ekki tiltæk. Framendinn ætti að skila stýrðri uppstraumsvillu, ekki falla hljóðlega til baka á annan bakenda sem enginn hefur skrifað upp. 502 með skýrri lóglínu er góð niðurstaða. Skyggd síða frá óviljandi uppruna er það ekki.