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 کاروي، وآزموئ۔ د تونل له لارې پنګ رسېدنه ثابتوي او د TLS، اجازې یا اپلیکیشن په اړه هېڅ نه۔

په پای کې اصلي کوربه نوم ته د عادي سند تایید سره تازه عامه غوښتنه واستوئ، او یوازې ځوابي بدن نه بلکې ځوابي لار وګورئ۔

دواړه کتنې د ځای پرځای شوو ترتیباتو سره وساتئ او ولیکئ چې کله تونل نه وي شته څه پېږي۔ فرنټ انډ باید کنټرول شوې upstream تېروتنه بیرته راوګرځوي، نه دا چې په خاموشۍ بل بیک انډ ته لاړ شي چې چا مستند نه دی کړی۔ د روښانه لاګ کرښې سره 502 ښه پایله ده۔ له ناغوښتل شوي اصله زیرمه شوې پاڼه داسې نه ده۔