QGIS PostGIS SSH টানেল: TLS-এর জন্য সার্ভারের নাম রাখুন

টানেল ওঠে, QGIS সংযোগ করে, এবং লগইন ডেটাবেস হোস্টের বদলে 127.0.0.1 নাম বলা একটি সার্টিফিকেট ত্রুটিতে মারা যায়। পরের লোভনীয় পদক্ষেপটি হলো sslmode শিথিল করা, যা যাচাই বন্ধ করে দেয় এবং আপনি প্রথম থেকেই যে পরিচয়ের নিশ্চয়তা চেয়েছিলেন তা ফেলে দেয়। আসল সমস্যা হলো লোকাল পোর্ট আর সার্ভারের নাম একই ফিল্ডে রাখা হচ্ছে। একটি libpq সার্ভিস এন্ট্রি এদের আলাদা করে, ফলে সকেট ফরওয়ার্ড করা পোর্টে যায় আর TLS সার্টিফিকেটে ছাপা নামটিই যাচাই করে।

ক্লায়েন্ট মনে করে সে কীসে সংযোগ করছে

sslmode=verify-full অবস্থায় libpq সার্ভারের দেওয়া সার্টিফিকেটকে যে হোস্ট নামে পৌঁছাতে বলা হয়েছিল তার সঙ্গে তুলনা করে। সেই নামটি loopback ঠিকানা হলে তুলনা ব্যর্থ হয়, যদিও সার্টিফিকেটটি আসল ডেটাবেস হোস্টের জন্য বৈধ। SSH ফরওয়ার্ড বদলায় কোন সকেট বাইটগুলো বহন করে, ক্লায়েন্টের প্রত্যাশিত পরিচয় নয়। এই দুটি ধারণা আলাদা হয়ে গেলে ত্রুটিটি আর TLS-এর দোষ বলে মনে হয় না।

ফরওয়ার্ডও অনুমোদন নয়। SSH সার্ভার যে সংযোগ তৈরি করে তার উপর PostgreSQL এখনও নিজের নিয়ম প্রয়োগ করে, তাই কিছু বদলানোর আগে পরিবহন স্তর আর ডেটাবেস স্তর আলাদা রাখুন।

ফরওয়ার্ডকে শুধু loopback-এ বাঁধুন

লিসেনারটি QGIS মেশিনে থাকা উচিত, আর কোথাও নয়। 127.0.0.1 স্পষ্টভাবে লেখা থাকলে এটি অন্য ইন্টারফেস থেকে দূরে থাকে, আর বাইন্ড ঠিকানা বাদ দিলে SSH ক্লায়েন্টের গেটওয়ে সেটিংসের ওপর নির্ভর করে পোর্টটি বাইরে খুলে যেতে পারে।

ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 [email protected]

দ্বিতীয় কোলনের পরের গন্তব্যটি SSH সার্ভারের দিক থেকে নির্ধারিত হয়, তাই এই উদাহরণ ধরে নেয় PostgreSQL sshd-এর মতো একই হোস্টে আছে; অন্য মেশিনের ডেটাবেসের জন্য ওই ঠিকানা আর তার অনুমতিগুলো দরকার। সেশনটি -N দিয়ে চালান যাতে কোনো শেল না খোলে, হোস্ট-কি যাচাইয়ে হাত দেবেন না, আর QGIS-কে দোষ দেওয়ার আগে লিসেনারটি দেখা যাচ্ছে কি না নিশ্চিত করুন। পোর্ট আগে থেকেই ব্যবহৃত হলে ফরওয়ার্ড কুয়েরির সময় নয়, শুরুতেই ব্যর্থ হয়।

নাম আর সকেট একটিই সার্ভিস এন্ট্রিতে রাখুন

একটি সার্ভিস ফাইল একই সংযোগকে একটি যাচাইয়ের নাম আর আলাদা সকেট গন্তব্য বহন করতে দেয়। এন্ট্রিটি যেখানে libpq সার্ভিস খোঁজে সেখানে রাখুন, অথবা PGSERVICEFILE সেটির দিকে নির্দেশ করুন।

[gis-via-ssh]
host=db.geo.example
hostaddr=127.0.0.1
port=15432
dbname=gisdb
user=gis_reader
sslmode=verify-full
gssencmode=disable
sslrootcert=/path/to/approved-root.crt

এখানে host সার্টিফিকেট যাচাইয়ের জন্য ব্যবহৃত পরিচয়টি ধরে রাখে, আর hostaddr প্যাকেটগুলো ফরওয়ার্ড করা loopback পোর্টে পাঠায়, এবং এই ব্যবস্থা কাজ করতে দুটোই দরকার। gssencmode=disable এমন বিল্ডে গুরুত্বপূর্ণ যেগুলো নাহলে আগে GSSAPI এনক্রিপশনের জন্য দরকষাকষি করত, কারণ ওই পথটি এইমাত্র সেট করা TLS সেটিংস উপেক্ষা করে। QGIS-এর PostgreSQL সংযোগ ডায়ালগ থেকে নাম ধরে সার্ভিসটির উল্লেখ করুন এবং পাসওয়ার্ডটি শেয়ার করা ফাইলের ভেতরে নয়, স্বাভাবিক প্রম্পটের মাধ্যমে দিন। উপরের নাম আর পথগুলো প্লেসহোল্ডার; সেগুলো আপনার নিজের অনুমোদিত মান দিয়ে বদলে নিন।

টানেলের পরে PostgreSQL আর কী যাচাই করে

সার্ভার SSH হোস্ট থেকে, এই ব্যবস্থায় loopback থেকে, একটি সংযোগ দেখে এবং ক্রম অনুসারে হোস্ট-ভিত্তিক প্রমাণীকরণ নিয়মের সঙ্গে মেলায়। আপনার ডেটাবেস রোলকে এখনও প্রমাণীকরণ করতে হবে, আর SSH লগইন নিজে থেকে কোনো ডেটাবেস পরিচয় দেয় না। ক্লায়েন্ট যা ধরে নিয়েছে তা নয়, সার্ভার যা মনে করে তা যাচাই করুন।

psql "service=gis-via-ssh" -c "select inet_server_addr(), current_user"

কাজ শেষ হলে ফরওয়ার্ডিং সেশনটি বন্ধ করুন; লোকাল এন্ট্রি তখন কাজ করা বন্ধ করে দেয় আর বাকি কিছুই বদলায় না। একটি ডেটাবেস পথ পুরো GIS ক্লায়েন্টের জন্য VPN নয়, আর এটিকে VPN ভেবে নেওয়াই পরের সংযোগটিকে ভুল নির্ণয়ের দিকে নিয়ে যায়।