PostgreSQL عبر VPN: أي عنوان مصدر سيراه pg_hba

لا يعرف PostgreSQL أبدًا أن العميل متصل عبر VPN. فهو يتلقى اتصال TCP من عنوان ومجموعة بيانات اعتماد، ثم يقرر ما يفعل بها. لذلك يعني ربط الوصول بالنفق ترتيب ثلاثة قرارات منفصلة كي تتفق، ثم التحقق من العنوان الوحيد الذي يراه الخادم فعلًا بدلًا من العنوان الذي رسمته على المخطط.

ثلاثة قرارات لا يجوز دمجها

أين يستمع الخادم قرار واحد. وأي حركة يمكنها الوصول إلى ذلك العنوان قرار ثانٍ، يتخذه جدار النار على المضيف وأي حد شبكي أمامه. وأي هوية قاعدة بيانات يمكنها المصادقة من أي مصدر قرار ثالث، يُتخذ في pg_hba.conf.

كل قرار منها يفرضه مكوّن مختلف، وكل منها يفشل برسالة مختلفة. ودمجها في نقاش هو ما يجعل الناس يعدّلون ملف HBA لإصلاح مشكلة جدار نار. أبقها مرتبة: المستمع غير المرتبط لا يمكن الوصول إليه، والمنفذ المفلتر لا يمكن الاتصال به، وقاعدة HBA تقرر فقط ما يحدث بعد وجود اتصال. وعندما لا يكون لتغيير أي أثر، حدّد أي الطبقات الثلاث غيّرتها فعلًا.

أين يستمع الخادم

اربط بعنوان مُسنَد فعليًا إلى الجهاز، لا باسم واجهة:

listen_addresses = '10.20.0.30'

قد تقع قاعدة البيانات خلف بوابة VPN دون واجهة نفق خاصة بها، وهذا بالضبط سبب كون العنوان هو الشيء الصحيح الذي يجب تسميته. تغيير هذا الإعداد يتطلب إعادة تشغيل كاملة؛ وإعادة التحميل لا تكفي.

ثم رشّح المنفذ، وهو عادة 5432، على المضيف وعند كل حد أمامه. الربط بعنوان خاص ليس دليلًا على الحجب العام، لأن إعادة توجيه منفذ أو تعيين عنوان سحابي قد يوصّل الحزم إلى ذلك المستمع الخاص.

العنوان الذي تراه HBA فعلًا

مع الوصول الموجّه يرى الخادم عنوان النفق الداخلي لكل عميل. ومع ترجمة المصدر يرى بدلًا من ذلك عنوان البوابة المترجَم، وينهار كل عميل في تلك القيمة الواحدة. افحص المصدر من خلال أدلة الاتصال الخاصة بالخادم قبل أن تختار بادئة للسماح بها.

لنشر يستخدم أصلًا TLS وSCRAM، يبدو مثال وصول عن بُعد ضيّق عمدًا هكذا:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

يسمح ذلك بدور واحد وقاعدة بيانات واحدة عبر TLS من التجمع المذكور، ثم يرفض أي وصول TCP بعيد آخر. وهو ليس بديلًا عن ملف HBA كامل: أبقِ الإدارة المحلية والنسخ المتماثل وأي خدمة مصرّح بها، وضع القواعد الضيقة قبل الأذونات الأوسع.

عندما تكون الترجمة قيد العمل، لا تستطيع HBA التمييز بين العملاء بعناوينهم الأصلية. أبقِ قبول الشبكة مشدودًا واطلب بيانات اعتماد قاعدة بيانات حقيقية، ولا تستبدل مصادقة trust أبدًا بحساب فعلي.

أول تطابق يفوز، دون بديل

يقرأ PostgreSQL الملف من الأعلى إلى الأسفل ويستخدم أول سجل يطابق الاتصال. ولا توجد محاولة ثانية إذا فشلت مصادقة ذلك السجل، لذا فإن سماحًا واسعًا سابقًا يهزم رفضًا لاحقًا بصمت.

قاعدة الترتيب هذه هي السبب الأكثر شيوعًا لأن رفضًا مكتوبًا بعناية لا يسري أبدًا. ضع القواعد المحددة أولًا والواسعة أخيرًا، ثم اقرأ الملف كتسلسل لا كمجموعة. القاعدة التي أضفتها في الأسفل ليست سياسة، بل تعليق. حرّكها إلى الأعلى وأعد التحميل قبل أن تستنتج أن الملف يُتجاهل.

يحدد مرجع HBA كلا الترتيب والفرق بين سجلات host وسجلات hostssl، وهذا يهم عندما يكون المقصود من القاعدة أن الاتصال يجب أن يكون مشفرًا.

إعادة التحميل وإعادة التشغيل وحالة الرفض

تُطبّق تغييرات HBA بإعادة تحميل، ويساعدك عرض pg_hba_file_rules في العثور على أخطاء التحليل. يصف ذلك العرض محتوى الملف الحالي، لا ما إذا كان الخادم العامل قد حمّله بنجاح، لذا فقائمة نظيفة ليست دليلًا على أن القواعد الجديدة مفعّلة.

تغييرات المستمع تحتاج إلى إعادة تشغيل خاصة بها، ومن السهل الخلط بين العمليتين عندما يبدو أن لتغيير ما أثرًا.

اختبر بجلسات جديدة: يتصل عميل معتمد بالحساب المقصود، ولا يتصل الحساب نفسه من مسار غير معتمد، وتبقى هوية قاعدة بيانات غير مصرّح بها تفشل من داخل VPN. تفصل هذه النتائج الثلاث الحد الشبكي عن تفويض قاعدة البيانات، وهو جوهر إبقاء القرارات منفصلة.