VPN-এর মাধ্যমে PostgreSQL: 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-এর ভেতর থেকেও ব্যর্থ হয়। এই তিনটি ফলাফল নেটওয়ার্ক সীমানাকে ডেটাবেস অনুমোদন থেকে আলাদা করে, আর সিদ্ধান্তগুলো আলাদা রাখার পুরো কারণই সেটিই।