Nginx foar, privee backend efter de VPN

De browser praat mei Nginx, en Nginx iepenet in twadde ferbining de tunnel yn. Rûte beide, ferifiearje beide sertifikaten en hâld iepenbiere trochstjoeringen iepenbier.

Folgje ien fersyk fan in telefoan yn 'e trein oant in backend dy't allinnich binnen in privee netwurk bestiet. De telefoan lost in iepenbiere namme op, ferbynt mei in iepenbier adres op poarte 443 en foltôget in normale TLS-hânskieding. Nginx akseptearret dy ferbining en iepenet dan in twadde, folslein aparte, nei in adres dat it allinnich fia in VPN-ynterface berikt. Neat oan 'e telefoan feroaret, en de telefoan wit nea dat der in tunnel by belutsen wie.

Ien fersyk troch twa ferbiningen folgje

It ynkommende skonk is in iepenbiere HTTP-transaksje. It hat in iepenbiere namme, in iepenbier sertifikaat en in antwurdrûte dy't wurkje moat foar elk adres dat de besiker op dat stuit hat. Eltse feroaring dy't dy rûte fersteurt, brekt alle besikers tagelyk. Dêrom is it iepenbiere skonk it skonk dêr't je it minst op eksperimintearje wolle.

It útgeande skonk is privee. Nginx wurdt kliïnt, lost in ynterne namme op of brûkt in fêst adres, en berikt in tsjinst dy't in ferbining fan it ynternet wegerje soe.

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

Hâld se apart yn 't holle en de konfiguraasje wurdt fanselssprekkend. Mingje se, en je einigje mei besykjen in iepenbiere kliïnt oan in tunnel dielnimme te litten, en dêrwei komt it measte fan 'e betizing yn dit ûntwerp. It privee skonk mei ûndjin wêze. It iepenbiere skonk net.

Foardat je hokker dan ek hjirfan bouwe, befêstigje dat it publisearjen fan 'e applikaasje opsetlik is. In wurkjende proxy is ek in wurkjende bleatstelling, en it autentikaasjemodel moat in beslút wêze, net in by-effekt.

De poartnamme moat de tunnel oerlibje

Der sit in subtyl falstrik yn namme-oplossing. As privee DNS deselde namme oerskriuwt dy't it VPN-profyl foar syn eigen poarte brûkt, kin in werferbining úteinlik besykje dy poarte fia de tunnel te berikken dy't it sels bouwe moat. De kliïnt hat dy namme nedich foardat de tunnel bestiet. Sadree't it binnen de tunnel oplost wurdt, kin de ferbining hielendal net boud wurde.

Brûk aparte goedkarde nammen foar de poarte en de backend, en behein it belied fan 'e oplosser sa dat elke namme oplost nei it adres dat syn brûker nedich hat. It feroarjen fan 'e Host-kop fan in applikaasje helpt hjir neat, om't de VPN-kliïnt de syktocht docht.

Tink dan oan it berik. De frontend hat in rûte nei it adres fan 'e backend nedich, en moat ek trochgean mei it beäntwurdzjen fan iepenbiere kliïnten. In folsleine tunnel op dy host kin oan 'e earste eask foldwaan en de twadde brekke.

Dêr't it belied it tastiet, is in tunnel nei in bepaald bestimming it skjinere ûntwerp. Dêr't it belied in folsleine tunnel easket, heart de frontend yn in aparte netwurkkontekst ynstee fan oanpast te wurden mei ad hoc-rûtes foar bekende besikers.

Skriuw it tsjinnerblok sa dat beide skonken ferifiearje

Stel dat de backend in sertifikaat presintearret foar dizze namme: backend.corp.example en antwurdet op in privee adres. Ferbinen mei in adres wylst in namme ferifiearre wurdt, is krekt it doel fan 'e SNI- en namme-opsjes fan 'e proxy-module.

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

Elk paad en adres hjirboppe is in plakhâlder. De wichtige dielen binne dy't ferifikaasje oan hâlde: in namme om te kontrolearjen, in fertrouwensbondel om it tsjin te kontrolearjen, en in djipte dy't by de goedkarde keten past.

proxy_set_header Host app.example.com is opsetlik. De backend moat konfigurearre wurde om dat iepenbiere oarsprong te akseptearjen, en moat allinnich fertrouwe op trochstjoerde koppen fan dizze frontend. It oerskriuwen fan X-Forwarded-For mei it kliïntadres is goed foar ien proxy en ferkeard foar in keten, dus in ymplemintaasje mei meardere proxy's hat syn eigen regeling foar fertroude adressen nedich.

Meitsje dat it iepenbiere oarsprong him as in iepenbier oarsprong gedraacht

De applikaasje moat absolute URL's, trochstjoeringen en cookies foar it iepenbiere oarsprong útjaan. As it in besiker trochstjoert nei backend.corp.example, wurdt dy besiker nei in namme stjoerd dy't er net oplosse kin.

Reparearje dat fia de stipe ynstelling foar eksterne URL fan 'e applikaasje en in neisjoen trochstjoerbelied, net troch hostnammen yn antwurdslicms te wer skriuwen. Stripeferfanging oer willekeurige ynhâld brekt ûndertekene ladingen en makket flaters dy't min te efterfolgjen binne.

Cookies fertsjinje deselde soarch. In cookie dy't beheind is ta de privee namme sil nea troch in browser stjoerd wurde dy't allinnich de iepenbiere ken.

Befêstigje ek dat Nginx de iepenbiere socket echt besitte kin. In besteande websjinst op 443 moat ferhúzje of de frontend moat earne oars wenje, om't twa prosessen net deselde adres en poarte bine kinne.

Kontrolearje elk skonk dêr't it echt rint

Falidatearje de konfiguraasje mei de ynstallearre parser foar elke werladen, sadat in typflater de lústerder dy't no tsjinnet net delhellet.

Test dan it backend-skonk fan 'e frontend-host sels, yn deselde netwurkkontekst dy't Nginx brûkt. In ping troch de tunnel bewissiget berikberens en neat oer TLS, autorisaasje of de applikaasje.

Meitsje úteinlik in nij iepenbier fersyk nei de echte hostnamme mei normale sertifikaatferifikaasje, en observearje it antwurdpaad ynstee fan allinnich it antwurdlichem.

Bewarje beide observaasjes by de útrôle konfiguraasje, en registrearje wat der bart as de tunnel net beskikber is. De frontend heart in kontrolearre upstream-flater werom te jaan, net stilwei nei in oare backend te fallen dy't nimmen dokumintearre hat. In 502 mei in dúdlike logrigel is in goed resultaat. In cachet side fan in ûnbedoeld oarsprong is gjin goed resultaat.

Relatearre artikelen