NGINX کے stream سیاق و سباق میں TLS passthrough کنکشن کی اجازت دیں
NGINX TLS ختم کیے بغیر TCP TLS ریلے کو مسترد کر سکتا ہے۔ اجازت کا قاعدہ HTTP location میں نہیں، stream میں رکھیں، اور دیکھیں کہ کون سا peer پتہ آتا ہے۔
خفیہ کردہ بائٹس کو کبھی سرٹیفکیٹ تھامے بغیر آگے بھیجنا وہی ہے جو TLS passthrough ریلے کرتا ہے، اور یہ ترتیب سہولت بخش اور قدرے الجھانے والی بھی ہے۔ چونکہ کچھ بھی ڈکرپٹ نہیں ہوتا، فلٹر کرنے کے لیے HTTP کی شکل کی کوئی چیز نہیں، اس لیے معمول کا location بلاک اور اس کے رسائی قواعد یہاں کوئی کام نہیں آتے۔ NGINX کے پاس جو فیصلہ ہے وہ خود کنکشن سے متعلق ہے: کس نیٹ ورک peer نے دستک دی، اور کیا اُس peer کو بالکل آگے بھیجنا چاہیے۔
فیصلہ HTTP میں نہیں، stream میں ہے
stream سیاق و سباق میں NGINX TCP سیشنز کے ساتھ کام کرتا ہے۔ یہ کنکشن کا peer پتہ دیکھتا ہے اور کسی بھی بائٹ کے backend تک پہنچنے سے پہلے اُس پر ترتیب وار allow اور deny قواعد لاگو کر سکتا ہے۔ یہ مکمل داخلہ فیصلہ ہے اور اسے نجی کلید، سرٹیفکیٹ یا HTTP تجزیے کی ضرورت نہیں۔
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
وہ تین سطریں کبھی ایک دوسرے کی جگہ نہیں لیتیں۔ 443 پورٹ کا ذکر کرنے والی کسی بھی فائل میں HTTP رسائی کی ہدایت کاپی کرنے سے کچھ نہیں بدلتا، کیونکہ stream سرور کبھی http سیاق نہیں پڑھتا۔
آگے بھیجنے سے پہلے کنکشن قبول کریں
فرض کریں کہ stream اور stream-access ماڈیول دستیاب ہوں، VPN کلائنٹ ماخذ پتے 10.90.0.0/24 میں رکھتے ہوں، اور 192.168.50.20:443 پر backend پہلے ہی مطلوبہ HTTPS شناخت پیش کر رہا ہو۔
stream {
server {
listen 443;
allow 10.90.0.0/24;
deny all;
proxy_pass 192.168.50.20:443;
}
}اسے چلتی ہوئی ترتیب کا براہ راست متبادل نہیں، بلکہ نئے listener کا ٹکڑا سمجھ کر پڑھیں۔ پہلے موجودہ listener اور include کا جائزہ لیں، کیونکہ پہلے سے قابض پورٹ پر دوسرا listener درخواست کے وقت نہیں، reload پر ناکام ہوتا ہے۔
غور کریں کہ کیا غائب ہے: کوئی listen ... ssl نہیں، سرٹیفکیٹ کی ہدایت نہیں۔ NGINX خفیہ کردہ بہاؤ آگے بھیجتا ہے، اور backend TLS ختم کر کے وہ سرٹیفکیٹ پیش کرتا ہے جس کی کلائنٹ تصدیق کرتا ہے۔ allowlist میں ناکام ہونے والے کلائنٹ کا TCP سیشن مسترد ہوتا ہے، HTTP 403 صفحہ نہیں، اور حیثیت کے کوڈ کی توقع کرنے والا کوئی بھی آلہ کوئی بیکار چیز رپورٹ کرے گا۔
allowlist کیا ڈھکتی ہے اور کیا نہیں
اگر ریلے پہلے ہی سرور نام کے مطابق backend منتخب کرتا ہے، تو ماڈیول دستیاب ہونے پر ssl_preread اور map وہ کام جاری رکھ سکتے ہیں۔ نام اب بھی کلائنٹ دیتا ہے، اور نام پیش کرنا یہ ثابت نہیں کرتا کہ کلائنٹ VPN میں شامل ہوا ہے۔
مثال کا قاعدہ پورے stream listener کو ڈھکتا ہے۔ اس سے یہ ایک ایسے واحد داخلہ نقطے کے لیے نامناسب ہو جاتا ہے جو عوامی اور صرف-VPN سائٹس کا مرکب پیش کرتا ہے، جہاں ہر نام کے لیے استثنا درکار ہوگا؛ الگ listener عام طور پر نام پر منحصر ایسی پالیسی سے زیادہ واضح ہوتے ہیں جسے کوئی پڑھ نہیں سکتا۔
دو مزید خلاوں کا ذکر لائق ہے۔ prefix مماثلت یہ نہیں بتاتی کہ پیکٹ کس انٹرفیس سے آیا، اور کہیں اور کا HTTP قاعدہ اس listener کو محدود نہیں کر سکتا۔ دونوں اس بات کی وجوہات ہیں کہ ایک allow سطر کو پوری حد ماننے کے بجائے میزبان سطح کی ingress پالیسی کو تصویر میں رکھا جائے۔ حد کو دو کنٹرول کے طور پر لکھیں جن پر اتفاق ضروری ہو، تاکہ کسی ایک میں تبدیلی کا جائزہ لیا جائے۔
NGINX واقعی کس کا پتہ دیکھتا ہے؟
لوڈ بیلنسر، دوسرا proxy یا source NAT NGINX کے سامنے واسطہ رکھ سکتے ہیں، اس لیے جو peer نظر آتا ہے وہ VPN کلائنٹ کا اندرونی پتہ نہیں۔ prefix منتخب کرنے سے پہلے حقیقی راستہ جانچیں، کیونکہ غلط پتے کے لیے لکھی allowlist یا تو مترجم کے پیچھے سب کو داخلہ دیتی ہے یا کسی کو نہیں۔
PROXY پروٹوکول اور حقیقی IP کی افزائش جائز جوابات ہیں، اور یہ صرف موافق، واضح طور پر قابلِ اعتماد بھیجنے والوں کے لیے ترتیب دیے جائیں۔ دونوں طریقے بھیجنے والے کی بات مانتے ہیں، اور اسی لیے بھیجنے والوں کی فہرست مختصر ہونی چاہیے۔ کسی بھی انٹرنیٹ کلائنٹ کی شناخت ہیڈر پر اعتماد ماخذ معلومات کو دوبارہ قابلِ اعتماد نہیں بناتا؛ یہ درست انکار کو جعلی قبولیت میں بدل دیتا ہے۔
reload سے پہلے دونوں نتائج جانچیں
ترتیب کی تصدیق کریں، reload کریں، پھر دو بار جانچیں: ایک نیا اجازت یافتہ سیشن جو کام کرنا چاہیے، اور ایک مسترد جو نہیں کرنا چاہیے۔ اجازت یافتہ جانچ میں معمول کی backend سرٹیفکیٹ تصدیق رکھیں، کیونکہ جڑنے والا مگر backend کی تصدیق نہ کر سکنے والا ریلے ایک مسئلہ حل کر کے دوسرا پیدا کر چکا ہے۔
nginx -t
ss -tnp | grep ':443'backend کا راستہ اور جواب بھی الگ جانچیں۔ allowlist سے گزرنا صرف یہ ثابت کرتا ہے کہ NGINX نے سیشن قبول کیا؛ یہ ناقابلِ رسائی backend کو جواب دینے پر مجبور نہیں کر سکتا، اور آپ کے شروع کرنے سے پہلے غائب واپسی راستہ ٹھیک نہیں کر سکتا۔