د VPN لپاره یوازې NGINX سایټ: اورېدونکی، فایر وال او د HTTP اجازې لیست

د شخصي سایټ او انټرنېټ ترمنځ درې خپلواکې پرېکړې ولاړې دي: کوم ساکټ اړیکه مني، کومه لار یې رسولی شي، او انتخاب شوی سرور کومو HTTP کلاینټونو ته ځواب وایي. د سرور بلاک یوازې لومړنۍ پرېکړه کوي. نورې دوه جلا کنټرولونه وګڼئ، که نه سایټ شخصي ښکاري خو زوړ ننوتل پرانیستې پاتې کیږي. د یوازې VPN لپاره د NGINX ډېری ناکامۍ د یوازې لومړنۍ طبقې ازموینې څخه راځي.

بېلګه په tun0 کې په 10.90.0.1 کې Linux OpenVPN دروازه، په 10.90.0.0/24 کې کلاینټونه، ساتل شوي سرچینې او د دې ننوتلو لپاره ځانګړی TCP 8443 کاروي. ارزښتونه سم کړئ، طبقې وساتئ.

له ساکټ څخه پیل وکړئ، نه د کوربه نوم څخه

HTTPS اورېدونکی د تونل پتې او ځانګړي پورټ سره وتړئ. ځانګړې پته د وحشي ساکټ او نوم څېړنې په پرتله اسانه ده، ځکه کرنل پورټ بلې سیمه ییزې پتې ته نه ورکوي.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

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

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

سند باید د هغه خدمت کوربه نوم ولري چې کلاینټونه یې لیکي، او شخصي DNS لید باید هغه کوربه تړل شوې پتې ته حل کړي. server_name یوازې مجازي کوربه ټاکي؛ دا هیچا تصدیق نه کوي. د DNS ننوتلو نشتوالی د TLS خرابۍ په څېر ښکاره شوی د سند تېروتنه رامنځته کوي. د سند بدلولو دمخه نوم وګورئ.

د فایل اضافه کولو دمخه اغېزمنه ترتیبه ولولئ. شاملول او وحشي اورېدونکي کولی شي هماغه ریښه بل ځای کې وړاندې کړي، او ډیفالټ سرور کولی شي داسې غوښتنو ته ځواب ووايي چې نوی بلاک یې هېڅکله نه ویني.

د هغې منځپانګې لپاره هر بل اورېدونکی بند کړئ

د listen لارښوونې ولیکئ او هغه ریښې پرتله کړئ چې خدمت یې کوي. د بل اپلیکیشن لپاره اضافه شوی بلاک کولی شي هماغه upstream ته پراکسي وکړي، او زوړ ډیفالټ سرور د نوي نصب وروسته هم ځواب ویلی شي. هغه پایله ریښتینی لیست دی، نه هغه فایل چې همدا اوس سم کړی. هره هغه ریښه پرتله کړئ چې هماغه منځپانګه وړاندې کوي.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

دواړه پتې کورنۍ وګورئ. IPv4 تړل IPv6 ساکټ نه لمس کوي، او نوی A ریکارډ زوړ AAAA ځواب نه بیرته اخلي چې لا هم عامه لار ته اشاره کوي.

زوړ مجازي کوربه د جلا بدلون په توګه لرې کړئ. د نوي بلاک عامه دوه ګوني لرې کول معمولاً هغه ګام دی چې ننوتل واقعاً بندوي؛ شخصي اورېدونکی یوازې غوښتل شوی زیاتوي.

په کوربه کې د راتلونکې لارې حد وټاکئ

د اورېدو پته ساکټ محدودوي، نه د ننوتلو انټرفیس. له بل ځایه هغې پتې ته لېږل شوی پاکټ بیا هم د سیمه ییز ننوتلو په توګه راځي، نو د کوربه فایر وال خپله اعلامیه غواړي چې اړیکه له کومه راتلای شي. له همدې امله یوازې تړل کېدل په ندرت سره پوښتنلیک پوره کوي.

د ډیفالټ ردولو راتلونکې پالیسۍ او دې خدمت لپاره د پراخې اجازې پرته، محدوده قاعده تونل، د سرچینې حد، منزل او پورټ یوځای نوموي:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

د پلي کولو دمخه د فایر وال اغېزمن ترتیب ولولئ. پخوانی پراخه منل محدودیت له منځه وړلی شي، او پخوانی وروستی غورځول کولی شي دې اجازې ته رسېدل مخه ونیسي. د بېلګې د سمون لپاره ناتړلي قواعد مه پاکوئ او فایر وال مه بندوئ.

هغه قاعده د کوربه ننوتل دي، نه بل LAN ماشین ته لار، او د دروازې بهرنی OpenVPN اورېدونکی جلا خدمت پاتې کیږي. که سایټ دمخه عامه و، پلان وکړئ چې زوړ ننوتل څنګه لرې شي او شته غونډې څنګه اداره شي.

د ځایونو بدلېدو سره د HTTP لیست بشپړ وساتئ

NGINX د allow او deny ننوتنې په ترتیب ارزوي، او پورتنۍ د سرور کچې لیست د وروستي deny دمخه اعلان شوې ډله مني. د لاسرسي ماډل دا هم ثبتوي چې هر د لاسرسي ننوتنه تعریف کوونکی ځای د مورني لیست پر ځای خپل لیست کاروي. ترتیب د ننوتنو په څېر مهم دی.

هماغه بیا تنظیمول معمول بیرته تګ دی. یوه ننوتنه زیاتوونکی نوی اپلوډ، API یا روغتیا ځای په چوپتیا د سرور کچې محدودیت بدلوي، او سایټ په ترټولو نوي زیات شوي لار کې پراخیږي.

هر ځای، مستعار نوم او بدیل بلاک د همدې پالیسۍ برخې په توګه وګورئ. که د IP څېړنې د NGINX تصدیق سره یوځای شي، satisfy وپېژنئ: any ترتیب کولی شي کلاینټ د یوې وسیلې له لارې تېر کړي پداسې حال کې چې بله لا نه ده تېره شوې. د لاسرسي لیست د ځایونو د بیاکتنې چک لیست کې واچوئ.

د HTTP انکار د TCP اړیکې NGINX ته رسېدو وروسته پېښیږي. دا د شبکې محدودیت بشپړوي، او د اپلیکیشن خپل اجازه هر کارونکي ته لا هم تطبیقیږي.

ژوندې لاره او د ناکامۍ حالت تصدیق کړئ

د ترتیب شنونکی چل کړئ، اورېدونکي ساکټونه وګورئ، بیا له ټاکل شوي کلاینټ څخه نوی نومول شوی غوښتنه وکړئ. تصدیق کړئ چې سند معتبر دی، DNS نوم تړل شوې پتې ته حل کیږي او ځواب له تمه شوې ریښې راځي.

بیا یوه ایستل شوې سرچینه او بدیله ننوتل وازموئ. کار کوونکې اجازه شوې غوښتنه د هغو لارو په اړه څه نه وایي چې تړل یې غوښتل، او په ایستل شوې ازموینه کې پاتې اورېدونکی یا پراخه فایر وال مننه ښکاري.

د بوټ یا VPN بیا رغولو حالت تکرار کړئ. که NGINX د تونل پتې له شتون دمخه پیل شي، تړل کېدل حتی د بشپړ فایل سره ناکام کېدای شي. د پتې چمتووالی همغږي کړئ او د شریک ویب سرور بدلولو دمخه سیمه ییزه بیا رغونه لاره وساتئ.

هغه ساکټ، پورټ، د سرچینې حد او HTTP لیست ثبت کړئ چې بریالي شول. بل VPN یا DNS بدلون کولی شي هر یو له دوی څخه وخوځوي، او څلور نومول شوي ارزښتونه د کار کوونکي براوزر ټب په پرتله اسانه پرتله کیږي.