مقامی ڈیٹا بیس کلائنٹ اور نجی 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 تصدیق کو برقرار رکھیں۔ کلائنٹ کو اب بھی سرور سرٹیفکیٹ کی تصدیق اُس نام کے خلاف کرنی چاہیے جس کی وہ توقع کرتا ہے؛ مقامی فارورڈ شدہ پورٹ تصدیق بند کرنے کی وجہ نہیں، اور اُسے بند کرنا وہی شناختی مسئلہ چھپا دیتا ہے جو پکڑنے کے قابل ہے۔

مکمل سرنگ اور تنگ فارورڈنگ کے درمیان انتخاب سیکیورٹی ڈرامہ نہیں، دائرے کا فیصلہ ہے۔

پیچھے دہرایا جا سکنے والا راستہ چھوڑیں

حل شدہ پتے کی بجائے اینڈ پوائنٹ کا نام، وہ ماخذ رینج جس کی سیکیورٹی گروپ اجازت دیتا ہے، اور وہ ڈیٹا بیس کردار جو ڈویلپر استعمال کرتا ہے، درج کریں۔ یہ تین حقائق آئندہ کی بیشتر ناکامیوں کی وضاحت بغیر کال کے کرتے ہیں۔ کلائنٹ پروفائل کا ورژن بھی شامل کریں، کیونکہ پروفائل کی تبدیلی اُس راستے کو ہٹا سکتی ہے جو پرانی پروفائل اٹھاتی تھی۔

پھر منفی صورت ایک بار جانچیں: منظور شدہ ماخذ سے باہر کا کلائنٹ پھر بھی مسترد ہونا چاہیے۔

وہ نجی ڈیٹا بیس جو صرف اُس شخص کے لیے کام کرے جس نے اُسے ترتیب دیا، نجی رسائی نہیں؛ وہ ایک غیر دستاویزی استثنا ہے جو دوبارہ دریافت ہونے کا منتظر ہے۔ راستہ لکھ لیں، اور اگلا ڈویلپر معمے کی بجائے طریقہ ورثے میں پائے گا۔