برنامه روی سرور دفتر به MySQL در localhost وصل می‌شود، شما آن نام میزبان را در یک کلاینت رومیزی کپی می‌کنید و اتصال یا شکست می‌خورد یا پایگاه‌داده دیگری باز می‌کند. VPN چیزی از معنای این واژه را تغییر نداده است: localhost هنوز به همان ماشینی اشاره دارد که کلاینت را اجرا می‌کند. VPN بسته‌ها را جابه‌جا کرد، نه رابط‌ها را. پیش از دست زدن به هر مسیر تصمیم بگیرید لپ‌تاپ باید به کدام نقطه پایانی برسد.

گام 1: تصمیم بگیرید لپ‌تاپ باید به کدام نقطه پایانی برسد

هر دو طرح مشروع‌اند و به پرسش‌های متفاوتی پاسخ می‌دهند. دسترسی مستقیم یعنی پایگاه‌داده روی نشانی خصوصی‌ای گوش می‌دهد که تونل به آن می‌رسد و لپ‌تاپ به همان نشانی وصل می‌شود. دسترسی منتقل‌شده یعنی پایگاه‌داده روی loopback می‌ماند و یک نشست SSH درگاه را به ماشین شما می‌برد. یکی را آگاهانه انتخاب کنید، چون آمیختن آن‌ها اتصالی می‌سازد که به دلیل اشتباه کار می‌کند.

برای دسترسی مستقیم، نام یا نشانی خصوصی خود میزبان پایگاه‌داده و درگاهش را از کسی که آن را اداره می‌کند بگیرید. نشانی دروازه VPN نشانی پایگاه‌داده نیست، مگر اینکه همان ماشین باشد. سپس تأیید کنید که شنونده واقعاً به همان رابط بسته شده است، چون مسیر به یک رابط شنونده‌ای روی آن نمی‌سازد.

گام 2: درگاه را تنها وقتی منتقل کنید که شنونده محلی بماند

اگر پایگاه‌داده باید فقط روی loopback بماند، آن را از طریق SSH منتقل کنید و انتهای محلی را هم به loopback ببندید. نشانی اتصال سمت چپ متعلق به لپ‌تاپ شماست؛ هدف سمت راست از دید سرور SSH تفسیر می‌شود، چنان‌که مرجع OpenSSH توضیح می‌دهد. وارونه کردن این دو نقش دلیل معمول این است که انتقالی کار می‌کند به نظر می‌رسد اما به هیچ‌چیز وصل نمی‌شود.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

اگر SSH به جای میزبان پایگاه‌داده روی میزبان پرش فرود بیاید، loopback سمت راست به میزبان پرش اشاره دارد و هدف باید به نشانی‌ای تغییر کند که آن میزبان به آن می‌رسد. ExitOnForwardFailure شکست در برقراری انتقال را می‌گیرد، اما ثابت نمی‌کند که اتصال‌های بعدی به هدف موفق می‌شوند. بررسی کلید میزبان را روشن نگه دارید و درگاه انتقال را با بستن به همه رابط‌ها به کل LAN خود عرضه نکنید.

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

گام 3: کلاینت را به TCP وادارید

در Unix، کلاینت MySQL که localhost بگیرد به‌طور پیش‌فرض یک سوکت Unix انتخاب می‌کند، پس تغییر تنها درگاه می‌تواند آن را به جست‌وجوی سوکتی بگذارد که هیچ ربطی به انتقال شما ندارد. از پروتکل صریح TCP و نشانی loopback استفاده کنید تا کلاینت اتصالی به درگاه انتقال شما باز کند.

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

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

اگر ابزار را نمی‌توان به TCP وادار کرد، متوقف شوید. آن‌گاه از کلاینت دیگری یا دسترسی مستقیم به شنونده خصوصی استفاده کنید.

گام 4: ثابت کنید واقعاً به کدام نقطه پایانی رسیدید

از سرور بپرسید که اتصال را چه می‌پندارد. متغیرهای نام میزبان، درگاه و سوکت می‌گویند آیا از TCP آمده‌اید و کدام شنونده پاسخ داده است، و فهرست اتصال‌ها نشانی منبعی را نشان می‌دهد که سرور ثبت کرده است. این شاهد از یک تغییر مسیر دیگر سودمندتر است.

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

ثبت کنید کدام نقطه پایانی را آزمودید: سوکت Unix محلی، درگاه انتقال یا شنونده خصوصی. این سه شکست درمان‌های متفاوتی دارند و تغییر مسیر VPN در حالی که کلاینت هنوز با localhost اشتباه حرف می‌زند تلاشی هدررفته است. مصادقه SSH و مصادقه پایگاه‌داده را هم در یادداشت‌ها جدا نگه دارید، چون شکست در یکی از دید کلاینت رومیزی مانند شکست در دیگری به نظر می‌رسد. سپس وقتی کارتان تمام شد انتقال را بردارید.

سیاهه وقتی پایان می‌یابد که بتوانید نقطه پایانی، پروتکل کلاینت، نشانی منبعی که سرور دید و مجوزی که آن را ممکن کرد را نام ببرید. چهار واقعیت، و مشکل اتصال بعدی به‌جای یک بعدازظهر چند دقیقه طول می‌کشد.

مقالات مرتبط