স্থানীয় ডেটাবেস ক্লায়েন্ট, ব্যক্তিগত RDS: সংযোগটি কেন সময়সীমা ছাড়িয়ে যায়

একজন ডেভেলপারের ল্যাপটপ ব্যক্তিগত RDS এন্ডপয়েন্টে সংযোগ করার সময় সময়সীমা ছাড়িয়ে যায়, অথচ একই শংসাপত্র একটি ব্যাস্টিয়ন হোস্ট থেকে কাজ করে। কিছুই বন্ধ হয়নি। ওই ল্যাপটপ ও ডেটাবেসের মধ্যের পথে তিনটি জিনিসের একটি অনুপস্থিত: একটি নাম যা রিজলভ হয়, একটি রুট যা ট্রাফিক বহন করে, বা একটি সিকিউরিটি গ্রুপ নিয়ম যা ডেটাবেস আসলে যে সোর্স দেখে তাকে অনুমতি দেয়। বাকি দুটি বদলানোর আগে কোনটি অনুপস্থিত তা খুঁজে বের করুন।

সঠিক স্তরে ব্যর্থতাটি পড়ুন

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

dig +short db.internal.example
nc -vz db.internal.example 5432

নামটি যদি পাবলিক ঠিকানা ফেরত দেয়, বা কিছুই ফেরত না দেয়, তবে টানেল এখনও সমস্যা নয়।

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

টানেলকে রুট থেকে আলাদা করুন

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

ip route get 10.20.40.15
ip addr show tun0

টানেল ইন্টারফেসের দিকে নির্দেশ করা রুট প্রয়োজনীয়; এটি যথেষ্ট নয়, কারণ অপর প্রান্তকে এখনও ট্রাফিক গ্রহণ করতে হবে।

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

সিকিউরিটি গ্রুপকে প্রকৃত সোর্সের সঙ্গে মিলান

RDS সিকিউরিটি গ্রুপ মানুষকে নয়, সোর্সকে অনুমতি দেয়। আর্কিটেকচার অনুযায়ী সোর্স হতে পারে VPN ক্লায়েন্ট পুল, ব্যাস্টিয়নের ব্যক্তিগত ঠিকানা, বা যে NAT ঠিকানায় ট্রাফিক অনুবাদ হয়। নিয়মটি আর প্রকৃত প্যাকেট সোর্স একসঙ্গে পড়ুন।

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

একটি ল্যাপটপের বাড়ির ঠিকানার জন্য নিয়ম অ্যাক্সেস ডিজাইন নয়, রক্ষণাবেক্ষণের সমস্যা।

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

প্রশস্ত পথের চেয়ে সংকীর্ণ পথ পছন্দ করুন

একজন ডেভেলপারের একটি ডেটাবেস দরকার হলে, সেশনভিত্তিক ফরওয়ার্ডিং সাধারণত পূর্ণ নেটওয়ার্ক টানেলের চেয়ে পরিচালনা করতে সস্তা। স্থানীয় ক্লায়েন্ট একটি ফরওয়ার্ড করা পোর্টে সংযোগ করে, এবং দূরবর্তী উপাদানটি নেটওয়ার্কের ভেতর থেকে ডেটাবেস সংযোগ তৈরি করে।

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

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

পূর্ণ টানেল আর সংকীর্ণ ফরওয়ার্ডের মধ্যে পছন্দ নিরাপত্তার নাটক নয়, পরিধি নিয়ে সিদ্ধান্ত।

পিছনে একটি পুনরাবৃত্তিযোগ্য পথ রেখে যান

রিজলভ করা ঠিকানার বদলে এন্ডপয়েন্টের নাম, সিকিউরিটি গ্রুপ যে সোর্স রেঞ্জ অনুমতি দেয়, এবং ডেভেলপার যে ডেটাবেস রোল ব্যবহার করেন তা নথিভুক্ত করুন। এই তিনটি তথ্য ভবিষ্যতের বেশিরভাগ ব্যর্থতা ফোন কল ছাড়াই ব্যাখ্যা করে। ক্লায়েন্ট প্রোফাইলের সংস্করণও যোগ করুন, কারণ প্রোফাইল পরিবর্তন পুরোনোটি বহন করা একটি রুট সরিয়ে দিতে পারে।

তারপর নেতিবাচক কেসটি একবার পরীক্ষা করুন: অনুমোদিত সোর্সের বাইরের ক্লায়েন্টকেও এখনও প্রত্যাখ্যান করা উচিত।

যে ব্যক্তিগত ডেটাবেস কেবল যে এটি সেট করেছে তার জন্যই কাজ করে তা ব্যক্তিগত অ্যাক্সেস নয়; এটি একটি অনথিভুক্ত ব্যতিক্রম যা আবার আবিষ্কৃত হওয়ার অপেক্ষায় আছে। পথটি লিখে রাখুন, এবং পরের ডেভেলপার রহস্যের বদলে একটি পদ্ধতি উত্তরাধিকার পাবে।