Firebird 3 کی وائر انکرپشن اور VPN دو مختلف سرحدیں ہیں

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

دو سرحدیں، اور وہ ایک دوسرے پر نہیں چڑھتیں

VPN سرحد کلائنٹ اور گیٹ وے کے درمیان پیکٹوں کی حفاظت کرتی ہے۔ Firebird کی وائر انکرپشن کلائنٹ لائبریری اور سرور پروسیس کے درمیان ڈیٹا بیس پروٹوکول کی حفاظت کرتی ہے۔ دونوں موجود ہو سکتے ہیں، اور کوئی ایک دوسرے کا متبادل نہیں۔

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

پہلی سرحد: سننے والا کون کھول سکتا ہے

اصل سرور پتہ اور تشکیل شدہ پورٹ کی نشاندہی کریں، جو تبدیل نہ ہوا ہو تو 3050 ہے، پھر ہوسٹ اور نیٹ ورک فائر وال پر صرف منظور شدہ VPN ذرائع کو اجازت دیں۔ VPN گیٹ وے پر کسی بھی پتہ ترجمے کو مدنظر رکھیں، اور اگر گیٹ وے الگ ہے تو ڈیٹا بیس ہوسٹ کو کلائنٹ پول کی طرف واپسی راستہ دیں۔

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

دوسری سرحد: Firebird کس پر بات چیت کرتا ہے

Firebird 3 نے وائر انکرپشن کا فریم ورک متعارف کرایا جس میں سرور پالیسی غیر فعال، فعال یا لازمی ہو سکتی ہے۔ پالیسی کم از کم سطح مقرر کرتی ہے۔ اصل سیشن اب بھی اس کلائنٹ لائبریری پر منحصر ہے جو ایپلیکیشن لوڈ کرتی ہے اور ان پلگ انز پر جو دونوں فریق معاونت کرتے ہیں۔

Firebird 3 کے ریلیز نوٹس میں Arc4 کو اس ریلیز کے لیے ڈیفالٹ وائر انکرپشن پلگ ان کے طور پر درج کیا گیا ہے۔ Arc4 ایک تاریخی ڈیفالٹ ہے، جدید سائفر کی سفارش نہیں، اور یہ بیرونی VPN تحفظ کے برابر نہیں۔

توثیق اسی بات چیت میں تیسرا متغیر ہے۔ سرور توثیق پلگ انز کا ایک مجموعہ قبول کرتا ہے، کلائنٹ لائبریری اس کا ذیلی مجموعہ پیش کرتی ہے، اور دونوں کو باہم ملنا ہوتا ہے۔

Legacy_Auth کا جال

Legacy_Auth کی معاونت کے لیے سرور کی ڈیفالٹ لازمی انکرپشن پالیسی کو نرم کرنا پڑتا ہے۔ یہی دستاویزی مطابقت کی لاگت ہے، اور اسی لیے کنکشن کی خرابی کو خاموش کرنے کے لیے پالیسی کم کرنا اصلاح نہیں بلکہ حفاظتی تبدیلی ہے۔

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

اہم کنکشن کی جانچ کریں

اس بلڈ پر جو سیاق متغیر فراہم کرتا ہے، یہ استفسار موجودہ کنکشن کی انکرپشن حالت بتاتا ہے:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

اسے ایپلیکیشن کے اپنے کنکشن سے چلائیں، اسی سرور پر منتظم سیشن سے نہیں۔ انکرپٹڈ منتظم کنکشن کسی دوسری کلائنٹ لائبریری کے سیشن کے بارے میں کچھ نہیں بتاتا، اور متغیر کی معاونت نہ کرنے والا پرانا بلڈ اس بات کا ثبوت نہیں کہ انکرپشن بند ہے۔

کلائنٹ لائبریری کا ورژن، سرور بلڈ اور نتیجہ ایک ساتھ درج کریں، کیونکہ ان میں سے کوئی بھی اکیلا پڑھا نہیں جا سکتا۔

اجازتیں اور اپ گریڈ کا راستہ

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

آخر میں، طویل المدتی تعیناتی کو دیکھ بھال کا سوال سمجھیں۔ ٹنل کسی پرانی کلائنٹ لائبریری کو غیر معینہ مدت تک محفوظ نہیں بناتا، اور معاونت یافتہ اپ گریڈ راستہ اس پلگ ان کے ہٹائے جانے کا پتہ لگانے سے سستا ہے جس کی اسے ضرورت ہے۔