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 شکست می‌خورد. این سه نتیجه مرز شبکه را از مجوز پایگاه داده جدا می‌کنند، و این تمام نکتهٔ جدا نگه داشتن تصمیم‌هاست.