Nextcloud صرف VPN کے ذریعے: پہلے ہر داخلے کی فہرست بنائیں

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

چیک لسٹ کو ترتیب سے مکمل کریں۔ پہلا نکتہ طے کرتا ہے کہ اس تعیناتی کے لیے نجی کا مطلب کیا ہے؛ بعد کے نکات جانچتے ہیں کہ تعیناتی واقعی اس تعریف سے مطابقت رکھتی ہے یا نہیں۔

دائرہ بدلنے سے پہلے نجی کی تعریف کریں

ضرورت کو ایک جملے میں لکھیں: ہر صارف کو ایپلیکیشن تک پہنچنے سے پہلے VPN میں شامل ہونا چاہیے، یا ایپلیکیشن عام رہ سکتی ہے جبکہ اس کی اصل نجی رہتی ہے۔ یہ مختلف ڈیزائن ہیں، اور نجی ٹنل میں بھیجنے والا عوامی ریورس پراکسی صرف دوسرا پورا کرتا ہے۔

نجی backend پتہ ایپلیکیشن کو نجی نہیں بناتا۔ اگر عوامی میپنگ، دوسرا ہوسٹ نام یا IPv6 سننے والا اب بھی اسی Nextcloud انسٹانس تک پہنچتا ہے تو داخلہ موجود ہے بھلا backend کہیں بھی ہو۔ سروس کو نجی قرار دینے سے پہلے ہر نام کو باہر سے جانچیں۔ گمشدہ DNS ریکارڈ بند پورٹ کے برابر نہیں۔

مطلوبہ سامعین پر بھی اتفاق کریں: ملازمین، ایک گھر، پارٹنر تنظیم یا اکاؤنٹس کا ذیلی مجموعہ۔ جواب طے کرتا ہے کہ عوامی شیئرنگ لنک خصوصیت ہے یا تضاد۔ وہ سامعین رسائی منصوبے میں لکھیں۔ یہ آگے آنے والی ہر استثنا کی آزمائش ہے۔

ہر داخلے اور ہر نام کی فہرست بنائیں

عوامی پتہ میپنگز، ریورس پراکسیز، متبادل ہوسٹ نام، IPv6 سننے والے اور سروس تک پہنچنے والا کوئی بھی ٹنل یا میش پتہ درج کریں۔ ان ناموں کو بھی شامل کریں جو ان پتوں میں حل ہوتے ہیں، کیونکہ بھولا ہوا DNS ریکارڈ دوستانہ لیبل والا داخلہ ہے۔

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

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

ہر کلائنٹ کو ایک سروس نام دیں

نجی DNS کو سروس کی طرف موڑیں، وہ نام VPN کے ذریعے گزاریں اور اس کے لیے سرٹیفکیٹ جاری کریں۔ نام کو نجی راستے سے حل ہونا چاہیے اور بغیر انتباہ کے تصدیق ہونا چاہیے۔ سیدھا IP تک پہنچنے والے کلائنٹ کو بھی نام کے کام کرنے کی ضرورت ہے۔

غیر متعلق IP پتے کے ذریعے جڑنے والے کلائنٹس کو ڈیزائن کے کام کرنے کے لیے سرٹیفکیٹ غلطیاں مسترد نہیں کرنی چاہئیں۔ مستحکم نام پتہ بدلنے پر سنک کلائنٹس کو دہرائے گئے سرور اندراجات بنانے سے بھی روکتا ہے۔ نجی سروس اور نجی IP کے درمیان یہی فرق ہے۔

سرٹیفکیٹ کی تصدیق فعال رکھیں۔ نجی نیٹ ورک نمائش کم کرتا ہے مگر غیر تصدیق شدہ TLS کنکشن کو قابل قبول نہیں بناتا، اور انتباہات نظر انداز کرنے کا عادی کلائنٹ دوسرے نیٹ ورکس میں بھی انہیں نظر انداز کرے گا۔

نیٹ ورک رسائی محدود کریں، پورا LAN نہیں

رجسٹرڈ صارفین کو Nextcloud سروس اور اس کے ضروری انحصار تک پہنچنے دیں، اور سرور انتظام الگ راستے پر رکھیں۔ جو VPN کلائنٹ کو پورے گھر یا دفتر کے نیٹ ورک میں داخل ہونے دیتا ہے وہ اس کلائنٹ کو ایپلیکیشن کی ضرورت سے کہیں زیادہ دیتا ہے۔

VPN میں داخلہ Nextcloud اکاؤنٹس، اجازتوں یا اضافی توثیق کی جگہ نہیں لیتا۔ ایپلیکیشن اب بھی طے کرتی ہے کہ کون صارف کون سی فائل پڑھ سکتا ہے، اور نیٹ ورک پرت واحد کنٹرول نہیں ہونی چاہیے۔

منظور شدہ ماخذ کی حد اور سروس پورٹس درج کریں۔ ہدف کے مالک کو مشاہدہ شدہ ماخذ چاہیے، اور درخواست ایپلیکیشن تک پہنچنے سے پہلے NAT یا پراکسی اسے دوبارہ لکھ سکتے ہیں۔

براؤزر سے باہر کے ہر ورک فلو کا جائزہ لیں

ڈیسک ٹاپ سنک اور موبائل اپ لوڈز اپنے وقت پر اپنے کنکشن کھولتے ہیں۔ جڑتے وقت انہیں منظور شدہ نجی راستہ چاہیے، اور VPN نہ ہونے پر وہ مختلف برتاؤ کر سکتے ہیں: دوبارہ کوشش، وقفہ یا خرابی دکھانا۔ ہر ایک کو جانچیں، صرف براؤزر کو نہیں۔

WebDAV ٹولز اور کیلنڈر یا رابطہ کلائنٹس اپنی کنفیگریشن والے الگ انٹیگریشن ہیں۔ عوامی URL کیش کرنے والا کلائنٹ دائرہ بدلنے کے بعد بھی وہی URL آزماتا رہتا ہے، اور ناکامی ایپلیکیشن کے مسئلے جیسی لگتی ہے۔

مشترکہ لنکس واضح فیصلے کے مستحق ہیں۔ لنک اپنے وصول کنندہ کو VPN رسائی نہیں دیتا، اس لیے واقعی صرف VPN کے ڈیزائن میں بیرونی وصول کنندہ لنک درست ہونے کے باوجود استعمال نہیں کر سکتا۔ اگر باہر شیئر کرنا ضروری ہو تو یہ اپنے رسائی راستے والی دانستہ استثنا ہے، بعد میں ملنے والی کوتاہی نہیں۔

فیڈریشن اور سرور سے سرور انٹیگریشنز کو بھی وہی برتاؤ چاہیے۔ یہ تنصیبات کے درمیان رسائی کے تعلقات ہیں، اور صرف نجی تعیناتی کو بتانا ہوگا کہ وہ معاون ہیں یا نہیں۔

اجازت یافتہ اور مسترد دونوں صورتوں کو قبول کریں

منظور شدہ کلائنٹ سے ویب انٹرفیس اور عام فائل اپ لوڈ یا ڈاؤن لوڈ جانچیں۔ پھر سنک کلائنٹ اور براؤزر سے باہر ایک ورک فلو جانچیں۔ صرف براؤزر میں کامیابی قبولیت نہیں۔

غیر منظور شدہ راستے سے تصدیق کریں کہ ایپلیکیشن فہرست کے ہر داخلے سے ناقابل رسائی ہے۔ متبادل ہوسٹ نام اور IPv6 پتہ جانچیں، صرف بنیادی URL نہیں۔

آخر میں ایپلیکیشن کی وہ سیٹنگز دیکھیں جو نیٹ ورک پالیسی سے آسانی سے الجھ جاتی ہیں۔ trusted_domains ان ناموں کی فہرست دیتا ہے جو انسٹانس قبول کرتا ہے؛ یہ کلائنٹ IP کی اجازت فہرست نہیں۔ اگر ریورس پراکسی پتے کی معلومات فراہم کرے تو trusted_proxies کو اصل پراکسی کا نام دینا چاہیے، اور آگے بھیجے گئے ہیڈرز صرف اسی سے قبول کیے جانے چاہئیں۔

نیٹ ورک تبدیلی کے ساتھ معمول کی مضبوطی کا کام جاری رکھیں: ڈیٹا اور بیک اپ کو غیر ارادی ویب راستوں سے باہر رکھیں، ایپلیکیشن کو پیچ کریں، منتظم کی رسائی محفوظ کریں اور بحالی کو قابل استعمال رکھیں۔ VPN ایک داخلے کی سطح ہٹاتا ہے؛ یہ رجسٹرڈ کلائنٹ کو قابل اعتماد نہیں بناتا۔