ඉදිරියේ Nginx, VPN පිටුපස පෞද්ගලික බැක්එන්ඩ්

බ්‍රවුසරය Nginx සමඟ කතා කරයි, Nginx උමඟ තුළ දෙවන සම්බන්ධතාවයක් විවෘත කරයි. දෙකම මාර්ගගත කරන්න, සහතික දෙකම තහවුරු කරන්න සහ පොදු යළි-යොමු පොදුවේ තබන්න.

දුම්රියේ ඇති දුරකථනයකින් එන එක් ඉල්ලීමක් පෞද්ගලික ජාලය තුළ පමණක් පවතින බැක්එන්ඩ් එකක් දක්වා ලුහුබඳින්න. දුරකථනය පොදු නාමයක් විසඳයි, 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 හොඳ ප්‍රතිඵලයකි. අනුදුද්දේශිත මූලයකින් ගබඩා කළ පිටුව එය එසේ නොවේ.

අදාළ ලිපි