না, একটি কানেকশন স্ট্রিং আপনার VPN টানেল চালু করতে পারে না

ডেভেলপাররা এখনো সেই জায়গাটি খোঁজেন যেখানে একটি কানেকশন স্ট্রিং, একটি JDBC URL বা একটি tnsnames.ora এন্ট্রি VPN নির্বাচন করে। এমন জায়গা নেই। টানেলটি প্রতিষ্ঠা করে অপারেটিং সিস্টেম বা একটি ভেন্ডর ক্লায়েন্ট, যা একটি ভার্চুয়াল অ্যাডাপ্টার নিবন্ধন করে, আর তার উপরের প্রতিটি ডেটাবেস লাইব্রেরি ফলে যে সকেট স্তর তৈরি হয় তা ব্যবহার করে। একটি কানেকশন স্ট্রিং একটি হোস্ট, একটি পোর্ট এবং একটি ক্রেডেনশিয়ালের নাম বলে, আর এটাই পুরো শব্দভান্ডার।

মিথ: কানেকশন স্ট্রিং একটি টানেল নির্বাচন করতে পারে

ড্রাইভার একটি হোস্ট ও পোর্টে TCP সকেট খোলে। টানেল তোলার কোনো API নেই, টানেল প্রোফাইলের কোনো ফিল্ড নেই, এবং VPN গেটওয়েতে প্রমাণীকরণের কোনো উপায় নেই।

এই কারণেই একটি রুট তৈরি হওয়ার পর টুলগুলো একইভাবে আচরণ করে। SSMS, DBeaver, Eclipse Data Tools এবং সাধারণ sqlcmd সবই এমনভাবে কাজ করে যেন সার্ভারটি লোকাল নেটওয়ার্কে আছে, কারণ সকেটের দৃষ্টিকোণ থেকে তা-ই। ভার্চুয়াল অ্যাডাপ্টার ডেটাবেস সাবনেটকে পৌঁছানোর উপযোগী করেছে, আর ড্রাইভার কখনো জানে না কীভাবে।

এটি আরও ব্যাখ্যা করে কেন একটি কানেকশন স্ট্রিং ছিঁড়ে যাওয়া টানেল মেরামত করতে পারে না। লিঙ্কটি মরে গেলে ড্রাইভার টাইমআউট বা সাধারণ নেটওয়ার্ক ত্রুটি জানায়, আর যে অ্যাপ্লিকেশন কোড এটিকে কুয়েরি সমস্যা ভাবে সে চিরকাল ভুল স্তরে পুনরায় চেষ্টা করে।

ড্রাইভার চালু হওয়ার আগেই টানেল তোলো

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

টানেল তত্ত্বাবধান অ্যাপ্লিকেশনের বাইরে রাখো। যে PHP বা Java সার্ভিস নিজেই লিঙ্কটি তোলার চেষ্টা করে, সে এক প্রদানকারীর আচরণ ব্যবসায়িক কোডে লিখে ফেলে, আর প্রতিটি ফেলওভার একটি অ্যাপ্লিকেশন রিলিজ হয়ে যায়। যে সুপারভাইজার টানেলের মালিক, তা দেখে এবং পুনরায় চালু করে, সে কুয়েরি পথ থেকে আলাদা বিষয়।

ড্রাইভারকে দোষ দেওয়ার আগে রুটটি যাচাই করো। যদি হোস্ট রিজলভ না হয় বা শেল থেকে পোর্ট উত্তর না দেয়, কোনো কানেকশন স্ট্রিং তা বদলাবে না।

মিথ: Windows প্রমাণীকরণ ব্যর্থতা মানে রুট ভাঙা

VPN-এর উপর দিয়ে Windows প্রমাণীকরণ প্রায়ই নেটওয়ার্ক ত্রুটির মতো দেখতে একটি ত্রুটি দেয়, অথচ রুট ঠিক থাকে। যখন অ্যাকাউন্টটি অন্য ডোমেইনের এবং ল্যাপটপটি তাতে যোগ দিতে পারে না, তখন ডেস্কটপ সেশনের পরিচয়ের বদলে স্পষ্ট ক্রেডেনশিয়াল দিয়ে ক্লায়েন্ট চালু করো।

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

/netonly সুইচ ওই ক্রেডেনশিয়াল শুধু দূরবর্তী প্রমাণীকরণের জন্য রাখে। সংযোগ ডায়ালগে বিশ্বাস না করে SELECT SUSER_SNAME() দিয়ে সার্ভার আসলে কী পেয়েছে তা নিশ্চিত করো। সার্ভার ঠিকানার ক্রেডেনশিয়াল Windows Credential Manager-এ সংরক্ষণ SSMS-এ কাজ করে বলে জানা যায়, কিন্তু ভিন্ন অ্যাকাউন্টে চলা সার্ভিসে সবসময় নয়, তাই লগইন বদলানোর আগে প্রসেসটি কোন পরিচয় ব্যবহার করে তা দেখো।

লেটেন্সি সার্ভার-সাইড কার্সরকে টাইমআউটে পরিণত করে

সার্ভার-সাইড কার্সর ডেটাবেসকে ফলাফল ধরে রেখে ধীরে ধীরে আনতে বলে, যা একটি বড় ফলাফলকে অনেক ছোট রাউন্ড ট্রিপে ভাগ করে। লোকাল নেটওয়ার্কে এটি সস্তা। কয়েক ডজন মিলিসেকেন্ড বাড়তি লেটেন্সিযুক্ত টানেলের উপর দিয়ে একই কুয়েরি প্রায় কোনো ডেটা না পাঠিয়েই কমান্ড টাইমআউট ছাড়িয়ে যেতে পারে।

ক্লায়েন্ট-সাইড কার্সরে যাও, বা fetch size বাড়িয়ে সারিগুলো ব্যাচ করো, তখন রাউন্ড ট্রিপের সংখ্যা কমে। বাধা হলো বিনিময়ের সংখ্যা, নয় নামমাত্র লিঙ্ক গতি, তাই থ্রুপুট মাপলে তোমাকে বিভ্রান্ত করবে, রাউন্ড ট্রিপ মাপলে করবে না। তোমার ব্যবহারকারীরা সত্যিই যে সবচেয়ে বড় ফলাফল সেট টানে তা দিয়ে পরীক্ষা করো, তাৎক্ষণিক ফেরা এক-সারির কুয়েরি দিয়ে নয়। টাইমআউট সরলে কিন্তু না মিললে, কমান্ড টাইমআউট ও fetch size একসাথে বাড়িয়ে আবার মাপো।

একই হিসাব প্রযোজ্য বাচাল ORM এবং প্রতি সারিতে একটি স্টেটমেন্ট পাঠানো যেকোনো ক্লায়েন্টের ক্ষেত্রে। কুয়েরি প্ল্যান ঠিক থাকলে এবং স্থানান্তর ছোট হলে, ডেটাবেস টিউন করার আগে নেটওয়ার্ক বিনিময়গুলো গুনে দেখো।

পোর্ট, ইনস্ট্যান্স এবং লোকাল ফিল্টার যাচাই করো

নামযুক্ত ইনস্ট্যান্স ডাইনামিক পোর্টে শোনে, তাই 1433 ধরে নেওয়ার বদলে পোর্ট নিশ্চিত করো। ডিফল্ট ইনস্ট্যান্সে মানটি ইনস্ট্যান্সের SuperSocketNetLib কী-এর অধীন TcpPort রেজিস্ট্রি মান থেকে পড়া যায়। Oracle-এর ক্ষেত্রে যাচাই করো যে tnsnames.ora-র হোস্ট রিজলভ হয়, ঠিকানাটি উত্তর দেয় এবং listener পোর্ট অনুমোদিত; 1521 একটি সাধারণ ডিফল্ট, গ্যারান্টি নয়।

তারপর টানেলের নিজস্ব অ্যাক্সেস লিস্ট এবং শেষে একটি লোকাল অ্যান্টিভাইরাস বা হোস্ট ফায়ারওয়াল বাদ দাও, যা ক্লায়েন্ট ও সার্ভার একই মেশিন হলেও সংযোগ আটকায়। কনফিগারেশন বদলানোর আগে ব্যর্থ স্তরটি ধরে ফেলো, কারণ নাম রিজলভিং, TCP পৌঁছানো এবং TLS বা লগইন প্রত্যেকে ভিন্ন বার্তায় ব্যর্থ হয়।

স্তরটি টিকিটে লেখো। নাহলে পরের ব্যক্তি ঠিক সেই কানেকশন-স্ট্রিং খোঁজাটাই পুনরাবৃত্তি করবে যা দিয়ে সব শুরু হয়েছিল।