આગળ Nginx, VPN પાછળ ખાનગી બેકએન્ડ

ટ્રેનમાં બેઠેલા ફોનથી એક વિનંતીને એવા બેકએન્ડ સુધી ટ્રેક કરો જે ફક્ત ખાનગી નેટવર્કની અંદર જ અસ્તિત્વમાં છે. ફોન જાહેર નામ ઉકેલે છે, પોર્ટ 443 પર જાહેર સરનામા સાથે જોડાય છે અને સામાન્ય TLS હેન્ડશેક પૂરો કરે છે. Nginx તે કનેક્શન સ્વીકારે છે અને પછી બીજું, સંપૂર્ણ અલગ કનેક્શન એવા સરનામા તરફ ખોલે છે જ્યાં તે ફક્ત VPN ઇન્ટરફેસ દ્વારા પહોંચે છે. ફોનમાં કંઈ બદલાતું નથી, અને ફોનને ક્યારેય ખબર પડતી નથી કે ટનલ સામેલ હતી.

એક વિનંતીને બે કનેક્શનમાંથી પસાર થતી જોવી

આવતો ભાગ જાહેર HTTP વ્યવહાર છે. તેનું જાહેર નામ, જાહેર પ્રમાણપત્ર અને પ્રતિસાદ માર્ગ છે જે તે ક્ષણે મુલાકાતી પાસે હોય તેવા કોઈપણ સરનામા માટે કામ કરવો જોઈએ. તે માર્ગને બગાડતો કોઈપણ ફેરફાર એકસાથે બધા મુલાકાતીઓને તોડી નાખે છે. તેથી જાહેર ભાગ એ છે જેના પર તમે સૌથી ઓછું પ્રયોગ કરવા માંગો છો.

બહાર જતો ભાગ ખાનગી છે. Nginx ક્લાયન્ટ બને છે, આંતરિક નામ ઉકેલે છે અથવા સ્થિર સરનામું વાપરે છે, અને એવી સેવા સુધી પહોંચે છે જે ઇન્ટરનેટથી આવતું કનેક્શન નકારી કાઢે.

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

આને મનમાં અલગ રાખો અને રૂપરેખાંકન સ્વયંસ્પષ્ટ બને છે. આને ભેગા કરો તો અંતે તમે જાહેર ક્લાયન્ટને ટનલમાં સામેલ કરવાનો પ્રયાસ કરશો, અને આ ડિઝાઇનની મોટા ભાગની ગૂંચવણ ત્યાંથી જ આવે છે. ખાનગી ભાગ નાજુક હોઈ શકે. જાહેર નહીં.

આમાંથી કંઈ પણ બનાવતા પહેલાં ખાતરી કરો કે એપ્લિકેશન પ્રકાશિત કરવી ઇરાદાપૂર્વક છે. ચાલતો પ્રોક્સી પણ ચાલતું જાહેરીકરણ છે, અને પ્રમાણીકરણ મોડેલ નિર્ણય હોવો જોઈએ, આડઅસર નહીં.

ગેટવેનું નામ ટનલમાંથી બચવું જોઈએ

નામ ઉકેલવામાં એક સૂક્ષ્મ જાળ છે. જો ખાનગી DNS તે જ નામ બદલી નાખે જે VPN પ્રોફાઇલ પોતાના ગેટવે માટે વાપરે છે, તો ફરી જોડાવું અંતે તે જ ટનલ દ્વારા તે ગેટવે સુધી પહોંચવાનો પ્રયાસ કરી શકે જે તેણે પોતે બનાવવી હોય. ક્લાયન્ટને આ નામ ટનલ અસ્તિત્વમાં આવે તે પહેલાં ઉકેલાયેલું જોઈએ. એક વાર તે ટનલની અંદર ઉકેલાયા પછી કનેક્શન ક્યારેય બની શકતું નથી.

ગેટવે અને બેકએન્ડ માટે અલગ મંજૂર નામો વાપરો, અને ઉકેલનારની નીતિ એ રીતે મર્યાદિત કરો કે દરેક નામ તેના વપરાશકર્તાને જરૂરી હોય તે સરનામા પર ઉકેલાય. કોઈ એપ્લિકેશનનું Host હેડર બદલવાથી અહીં કંઈ થતું નથી, કારણ કે શોધ VPN ક્લાયન્ટ કરે છે.

પછી વ્યાપ વિશે વિચારો. ફ્રન્ટએન્ડને બેકએન્ડના સરનામા સુધી માર્ગ જોઈએ છે અને તેણે જાહેર ક્લાયન્ટોને જવાબ આપવાનું ચાલુ રાખવું પણ જોઈએ. તે હોસ્ટ પર સંપૂર્ણ ટનલ પહેલી શરત પૂરી કરી શકે છે અને બીજી તોડી શકે છે.

જ્યાં નીતિ પરવાનગી આપે ત્યાં ચોક્કસ ગંતવ્યની ટનલ વધુ સ્વચ્છ ડિઝાઇન છે. જ્યાં નીતિ સંપૂર્ણ ટનલ ફરજિયાત કરે છે ત્યાં ફ્રન્ટએન્ડ અલગ નેટવર્ક સંદર્ભમાં રહે છે, ઓળખીતા મુલાકાતીઓ માટે તાત્કાલિક માર્ગો ઉમેરીને સમાધાન કરવામાં આવતું નથી.

સર્વર બ્લોક એ રીતે લખો કે બંને ભાગ ચકાસે

ધારો કે બેકએન્ડ આ નામ માટે પ્રમાણપત્ર રજૂ કરે છે: backend.corp.example અને ખાનગી સરનામા પર જવાબ આપે છે. નામ ચકાસતી વખતે સરનામા સાથે જોડાવું એ જ કારણે છે જેના માટે પ્રોક્સી મોડ્યુલના SNI અને નામ વિકલ્પો છે.

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

ઉપરનો દરેક માર્ગ અને સરનામું પ્લેસહોલ્ડર છે. મહત્વના તે ભાગો છે જે ચકાસણી ચાલુ રાખે છે: ચકાસવાનું નામ, તેની સામે ચકાસવાનું ટ્રસ્ટ બંડલ, અને મંજૂર સાંકળ સાથે મેળ ખાતી ઊંડાઈ.

proxy_set_header Host app.example.com જાણી જોઈને છે. બેકએન્ડને આ જાહેર ઉદ્ગમ સ્વીકારવા માટે ગોઠવવું જોઈએ, અને તેણે ફોરવર્ડ કરેલા હેડરો પર ફક્ત આ ફ્રન્ટએન્ડથી જ ભરોસો રાખવો જોઈએ. ઉપર લખવું X-Forwarded-For ક્લાયન્ટ સરનામા સાથે એક પ્રોક્સી માટે સાચું છે અને સાંકળ માટે ખોટું, તેથી બહુ-પ્રોક્સી તૈનાતીને પોતાની વિશ્વસનીય સરનામા ગોઠવણ જોઈએ.

જાહેર ઉદ્ગમને જાહેર ઉદ્ગમ જેવું વર્તન કરાવો

એપ્લિકેશને જાહેર ઉદ્ગમ માટે સંપૂર્ણ URL, રીડાયરેક્ટ અને કૂકીઝ બહાર પાડવી જોઈએ. જો તે મુલાકાતીને અહીં મોકલે છે: backend.corp.example, તો તે મુલાકાતી એવા નામ પર મોકલાય છે જે તે ઉકેલી શકતો નથી.

આને એપ્લિકેશનની સમર્થિત બાહ્ય URL સેટિંગ અને સમીક્ષિત રીડાયરેક્ટ નીતિથી સુધારો, પ્રતિસાદ મુખ્ય ભાગોમાં હોસ્ટ નામ ફરી લખીને નહીં. મનસ્વી સામગ્રીમાં સ્ટ્રિંગ બદલવી સહી કરેલા પેલોડ તોડે છે અને શોધવા મુશ્કેલ બગ બનાવે છે.

કૂકીઝ પણ એટલી જ કાળજીને લાયક છે. ખાનગી નામ સુધી મર્યાદિત કૂકી ફક્ત જાહેર નામ જાણતું બ્રાઉઝર ક્યારેય મોકલશે નહીં.

એ પણ ખાતરી કરો કે Nginx ખરેખર જાહેર સોકેટનું માલિક બની શકે. 443 પરની હાલની વેબ સેવા ખસવી પડશે અથવા ફ્રન્ટએન્ડને બીજે રહેવું પડશે, કારણ કે બે પ્રક્રિયાઓ એક જ સરનામું અને પોર્ટ બાંધી શકતી નથી.

દરેક ભાગને જ્યાં તે ખરેખર ચાલે છે ત્યાં જ ચકાસો

કોઈપણ ફરી લોડ કરતાં પહેલાં રૂપરેખાંકનને સ્થાપિત પાર્સરથી માન્ય કરો, જેથી ટાઇપિંગની ભૂલ હમણાં સેવા આપતા શ્રોતાને પાડી ન નાખે.

પછી બેકએન્ડનો ભાગ ફ્રન્ટએન્ડ હોસ્ટ પરથી જ, Nginx વાપરે છે તે જ નેટવર્ક સંદર્ભમાં ચકાસો. ટનલ દ્વારા ping પહોંચ સાબિત કરે છે અને TLS, અધિકૃતિ કે એપ્લિકેશન વિશે કંઈ નહીં.

અંતે સાચા હોસ્ટ નામ પર સામાન્ય પ્રમાણપત્ર ચકાસણી સાથે તાજી જાહેર વિનંતી કરો, અને ફક્ત પ્રતિસાદ મુખ્ય ભાગ નહીં પ્રતિસાદ માર્ગ જુઓ.

બંને અવલોકનો તૈનાત રૂપરેખાંકન સાથે રાખો અને નોંધો કે ટનલ ઉપલબ્ધ ન હોય ત્યારે શું થાય છે. ફ્રન્ટએન્ડે નિયંત્રિત upstream ભૂલ પરત કરવી જોઈએ, નહીં કે કોઈએ દસ્તાવેજ ન કરેલા બીજા બેકએન્ડ પર ચૂપચાપ પડી જવું જોઈએ. સ્પષ્ટ લોગ લાઇન સાથે 502 સારું પરિણામ છે. અણધાર્યા ઉદ્ગમથી કેશ કરેલું પૃષ્ઠ એવું નથી.