VPN-এর উপর SQL: সরাসরি ক্লায়েন্ট না অভ্যন্তরীণ ওয়ার্কস্টেশন?
VPN ল্যাপটপ থেকে সরাসরি SQL এবং ম্যানেজড ওয়ার্কস্টেশনে SSMS দুটি ভিন্ন বিশ্বাস-পথ। প্রতিটি যে সোর্স অ্যাড্রেস ও অনুমতি তৈরি করে, তা তুলনা করুন।
দলগুলো তাদের ল্যাপটপে SSMS চায়, আর দ্রুত সমাধান হলো SQL পোর্টটি VPN পুলে প্রকাশ করা। ধীর উত্তরটি জিজ্ঞাসা করে ক্লায়েন্ট প্রসেসটি কোথায় চলা উচিত, কারণ সরাসরি অ্যাক্সেস ও অভ্যন্তরীণ ওয়ার্কস্টেশন ভিন্ন সোর্স অ্যাড্রেস, এন্ডপয়েন্ট বিশ্বাস ও ডেটা পথ তৈরি করে। কোনোটিই স্বয়ংক্রিয়ভাবে নিরাপদ নয়, এবং একা VPN সদস্যপদ কিছুই নির্ধারণ করে না। কোনো অনুমতি নিয়ম থাকার আগেই ডিজাইনগুলো তুলনা করুন।
দুটি পথ, দুটি সোর্স অ্যাড্রেস
সরাসরি অ্যাক্সেসে ল্যাপটপ নিজেই ক্লায়েন্ট কনফিগারেশন বহন করে এবং ডেটাবেস সংযোগ খোলে। দূরবর্তী ওয়ার্কস্টেশনে ল্যাপটপ একটি ডেস্কটপ সেশন খোলে, আর ওয়ার্কস্টেশন নিজের অ্যাড্রেস থেকে SQL সংযোগ করে। ফলে প্রথম ডিজাইনে ডেটাবেস VPN পুল বা অনূদিত গেটওয়ে দেখে, দ্বিতীয়টিতে ওয়ার্কস্টেশনের অ্যাড্রেস দেখে। এই পার্থক্যই নির্ধারণ করে কোন ফায়ারওয়াল রুল ও কোন SQL অনুমতি সত্যিই প্রযোজ্য।
ল্যাপটপ এখনও দূরবর্তী সেশন নিয়ন্ত্রণ করে, তাই ওয়ার্কস্টেশন ব্যবহারকারী প্রমাণীকরণ বা সেশন নীতির বিকল্প নয়।
ডেটাবেস আসলে কী দেখে তা যাচাই করুন
সোর্স অ্যাড্রেস হলো মাপার বিষয়, ডায়াগ্রাম থেকে অনুমান করার নয়। সক্রিয় সংযোগের সার্ভার দিক থেকে এটি পড়ুন।
Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"সংযোগ পরীক্ষা প্রমাণ করে লিসেনার সেই নেটওয়ার্ক থেকে TCP গ্রহণ করে, আর কোয়েরি প্রমাণ করে সেশন কোন লগইন ও ডেটাবেসে পৌঁছেছে। সার্ভার যে অ্যাড্রেস লিপিবদ্ধ করেছে তা দেখতে বর্তমান সেশনের জন্য sys.dm_exec_connections কোয়েরি করুন, যা যেকোনো অনুবাদের পর ক্লায়েন্ট অ্যাড্রেস ফেরত দেয়। সেই মান যদি ল্যাপটপ না হয়ে গেটওয়ে হয়, তবে প্রতি-ব্যবহারকারী হোস্ট রুল ডেটাবেস মেশিনে কাজ করতে পারবে না। পর্যবেক্ষিত মানটি নির্বাচিত ডিজাইনের পাশে লিখুন, কারণ পুনঃসংযোগ ও পুল পরিবর্তন তা সরায়।
লিসেনার খুলুন, অতিরিক্ত কিছু নয়
ডিপ্লয়মেন্টের প্রয়োজনীয় সেবাটিই কেবল খুলুন। পরিচিত 1433 হলো ডিফল্ট ইনস্ট্যান্সের পোর্ট, কোনো সর্বজনীন ধ্রুবক নয়।
Get-NetTCPConnection -State Listen -LocalPort 1433নামযুক্ত ইনস্ট্যান্স প্রায়ই গতিশীল পোর্টে শোনে, SQL Server Browser UDP 1434-এ ডিসকভারি উত্তর দেয়, আর এই নির্ভরতা আলাদা একটি এক্সপোজার যা ন্যায্যতার দরকার। ইনস্ট্যান্সের জন্য নির্দিষ্ট পোর্ট পিন করলে Browser-এর প্রয়োজন হয় না এবং ফায়ারওয়াল রুল স্থির থাকে। পরীক্ষা পার করার জন্য ক্লায়েন্টের বিদ্যমান এনক্রিপশন ও সার্টিফিকেট যাচাই বন্ধ না করে রাখুন। তারপর পুরো VPN গ্রুপকে সার্ভার রোলে না দিয়ে ওয়ার্কলোডের জন্য ডেটাবেস রোল দিন।
অনুমোদিত পথ ও অস্বীকৃত পথ—দুটোই প্রমাণ করুন
সাধারণ অনুমোদিত ব্যবহারকারী হিসেবে নতুন সেশন খুলুন এবং সার্ভার পরিচয়, ডেটাবেস ও প্রয়োজনীয় অপারেশন নিশ্চিত করুন। তারপর বর্জনটি নিশ্চিত করুন: নীতির বাইরের সোর্স বা অ্যাকাউন্ট একই পরীক্ষায় ব্যর্থ হতে হবে। ওয়ার্কস্টেশন ডিজাইনের জন্য যাচাই করুন ল্যাপটপ সরাসরি ডেটাবেসে পৌঁছে সীমা এড়াতে পারে না। সরাসরি অ্যাক্সেসের জন্য যাচাই করুন পুনঃসংযোগের পরেও রুট ও সোর্স রুল টেকে।
ক্লায়েন্ট কোথায় চলেছে, ডেটাবেস কোন সোর্স দেখেছে এবং কোন রুল অনুমতি দিয়েছে তা লিপিবদ্ধ করুন। পরবর্তী পর্যালোচনা এই প্রমাণই চাইবে।