کلاینت محلی پایگاه داده و 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 را در آن طرح دست‌نخورده نگه دارید. کلاینت باید همچنان گواهی سرور را با نامی که انتظار دارد اعتبارسنجی کند؛ درگاه ارسال‌شده محلی دلیلی برای خاموش کردن بررسی نیست، و خاموش کردن آن دقیقاً همان مشکل هویتی را پنهان می‌کند که ارزش گرفتن دارد.

انتخاب میان تونل کامل و ارسال باریک تصمیمی درباره دامنه است، نه درباره نمایش امنیتی.

مسیری تکرارپذیر پشت سر بگذارید

نام نقطه پایانی را مستند کنید نه نشانی تفکیک‌شده، محدوده منبعی را که گروه امنیتی می‌پذیرد، و نقش پایگاه داده‌ای را که توسعه‌دهنده استفاده می‌کند. این سه واقعیت بیشتر شکست‌های آینده را بدون تماس توضیح می‌دهند. نسخه پروفایل کلاینت را هم بیفزایید، زیرا تغییر پروفایل می‌تواند مسیری را که پروفایل قدیمی حمل می‌کرد حذف کند.

سپس مورد منفی را یک بار بیازمایید: کلاینتی بیرون از منبع تأییدشده باید همچنان رد شود.

پایگاه داده خصوصی‌ای که فقط برای کسی کار می‌کند که آن را راه‌اندازی کرده، دسترسی خصوصی نیست؛ استثنایی مستندنشده است که در انتظار کشف دوباره است. مسیر را بنویسید، و توسعه‌دهنده بعدی روشی را به ارث می‌برد نه معما.