صرف 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 تبدیلی ان میں سے کوئی بھی ہلا سکتی ہے، اور چار نامزد اقدار کا موازنہ کام کرنے والے براؤزر ٹیب سے آسان ہے۔