OpenVPN UDP کے لیے Nginx stream ریلے: کیا بدلتا ہے

آپ کا کلائنٹ UDP پر سیٹ ہے، Nginx سرور میں VPN پورٹ کی طرف اشارہ کرنے والا location بلاک ہے، اور کچھ نہیں پہنچتا۔ یہ متوقع ہے: HTTP location کسی UDP ڈیٹاگرام کو نہیں لے جا سکتا، سامنے والے حصے کو کوئی بھی نام دیا جائے۔ اس کے لیے Nginx کو stream سننے والا درکار ہے، اور ترتیب وہاں منتقل کرنے کے بعد سیشن بچے گا یا نہیں یہ تفصیلات کا دوسرا مجموعہ طے کرتا ہے۔

پروکسی پرت پتے سے پہلے آتی ہے

Nginx کا stream ماڈیول HTTP کی تجزیہ کیے بغیر TCP اور UDP کی پروکسی کرتا ہے۔ اس کا HTTP ماڈیول درخواست کی سطر، ہیڈر اور جواب کی توقع کرتا ہے، اور ان میں سے کوئی بھی مقامی OpenVPN ڈیٹاگرام میں نہیں ہوتا۔ اس لیے پرت کا انتخاب پہلا فیصلہ ہے، اور یہ اس پر منحصر نہیں کہ سننے والا IPv4 ہے یا IPv6۔

TCP OpenVPN کے ساتھ کام کرتی دکھنے والی ترتیب UDP معاملے کے بارے میں کچھ نہیں کہتی۔ یہاں نقل و حمل پروٹوکول کا حصہ ہے، تعیناتی کی تفصیل نہیں۔

سننے والا اور backend

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

کچھ بھی ترمیم کرنے سے پہلے یقینی بنائیں کہ build میں stream ماڈیول موجود ہے؛ تقسیمی پیکیج اسے الگ ماڈیول میں تقسیم کر سکتا ہے، اور ماڈیول نہ ہونے پر سرنگ کے بجائے ترتیب کی خرابی آتی ہے۔ بلاک کو مرکزی ترتیب کے سیاق میں رکھیں، http کے اندر نہیں، اور دستاویزی پتے کو حقیقی backend سے بدلیں۔

دونوں راستوں اور دونوں فائر والز کو ڈیٹاگرام کی اجازت دینی ہوگی: سننے والے تک کا راستہ اور پروکسی سے backend تک کا راستہ۔ IPv6 سننے والا IPv4 راستہ بھی نہیں بناتا، اس لیے اگر کچھ کلائنٹ اب بھی IPv4 استعمال کرتے ہیں تو وہ سننے والا اپنی الگ جانچ کے ساتھ الگ اندراج ہے۔ backend کی اپنی فائر وال پروکسی کے پتے سے جانچیں، اپنے لیپ ٹاپ سے نہیں۔

سیشن کی ٹائم آؤٹ مدتیں درخواست کی ٹائم آؤٹ مدتیں نہیں

stream پروکسی UDP سیشن کے لیے حالت رکھتا ہے اور اپنی ٹائم آؤٹ اور جواب کی ترتیبات کے مطابق اسے پھینک دیتا ہے۔ DNS ریلے سے نقل کی گئی مختصر ٹائم آؤٹ گھنٹوں تک ڈیٹاگرام کا تبادلہ کرنے کی توقع رکھنے والے VPN کے لیے موزوں نہیں، اور ناکامی شروع ہونے سے انکار کرنے والے کنکشن کے بجائے خاموشی سے مرنے والے کنکشن کے طور پر ظاہر ہوتی ہے۔

تعیناتی کا مؤثر proxy_timeout اور جواب گننے کی کوئی بھی ترتیب پڑھیں، پھر ان کا موازنہ VPN کے اصل keepalive رویے سے کریں۔ مختلف لوگوں نے مختلف فائلوں میں لکھے دو نمبر کسی کام کرنے والے نظام کی عام حالت ہیں۔ کبھی موازنہ نہ کیے گئے دو نمبر وقفے وقفے سے رک جانے والے نظام کی عام حالت ہیں۔ موازنہ ایک بار، دن کی روشنی میں ہو اس لیے دونوں کو سروس ریکارڈ میں لکھیں۔

ریلے کیا بدلتا ہے اور کیا نہیں

stream پروکسی OpenVPN کا TLS کنٹرول چینل ختم نہیں کرتا اور نہ اسے HTTPS میں بدلتا ہے۔ backend ہی VPN سروس رہتا ہے، اور سرٹیفکیٹ کا تعلق کلائنٹ اور اسی سروس کے درمیان رہتا ہے۔ مطلوبہ backend شناخت محفوظ رکھنا اب بھی کلائنٹ اور سرور کا کام ہے۔

عام پروکسی backend کو نظر آنے والا ماخذ پتہ بھی بدل دیتی ہے۔ لاگز پروکسی دکھائیں گے، اور VPN سرور پر IP پر مبنی کوئی بھی رسائی قاعدہ کلائنٹ کے بجائے اسی پتے کا جائزہ لے گا۔ شفاف ماخذ تحفظ ایک الگ روٹنگ اور اختیار کا ڈیزائن ہے، سننے والے میں udp شامل کرنے سے آنے والی چیز نہیں۔ کلائنٹ پتے پر منحصر پالیسی لکھے جانے سے پہلے اس کا منصوبہ بنائیں۔

پورٹ سے نہیں، کلائنٹ سے تصدیق کریں

UDP پورٹ کھلا ہونے کی مقامی جانچ ثابت کرتی ہے کہ سننے والا موجود ہے۔ یہ ثابت نہیں کرتی کہ کوئی کلائنٹ اس کے ذریعے تصدیق کر سکتا ہے یا ٹریفک کا تبادلہ جاری رکھ سکتا ہے۔ منظور شدہ کلائنٹ سے حقیقی کنکشن مکمل کریں، پھر یقینی بنائیں کہ سیشن کافی دیر تک قائم رہتا ہے۔

جب کوئی بتاتا ہے کہ Nginx UDP نہیں کر سکتا کیونکہ اس کی جگہ ایک سادہ ریلے ٹول کام کر گیا، تو یہ دو حقائق بے تعلق ہیں۔ ٹول نے ثابت کیا کہ backend جواب دیتا ہے؛ اس نے اس بارے میں کچھ نہیں کہا کہ سامنے والا حصہ کیا معاونت کرتا ہے۔ دونوں سچ ہو سکتے ہیں، اور ان میں سے صرف ایک اس تعیناتی کی ترتیب ہے۔