MySQL از طریق VPN: سرور را بررسی کنید، نه فقط رمزنگاری را
رمزنگاری به میزبان اشتباه همیشه اشتباه است. مقادیر ssl-mode را مقایسه کنید، سپس اتصالی اجرا کنید که سرور مورد نظر را نام می‌برد و آن را اثبات می‌کند.
شما اتصالی را به 10.20.4.15 ذخیره می‌کنید، VPN قطع می‌شود و کلاینت همچنان متصل می‌شود. این خبر خوبی نیست. یک نشانی خصوصی مکانی درون هر بافت مسیریابی است که در آن قرار دارید، و شبکه‌های زیادی از همان بازه‌ها استفاده می‌کنند. کلاینت به یک سرور MySQL رسید، فقط شاید به سرور شما نرسیده باشد.
اصلاح دو نیمه دارد و فقط یکی از آن‌ها درباره شبکه است. اتصال را روی مسیر مورد نظر نگه دارید و کاری کنید که کلاینت سروری را که با آن صحبت می‌کند احراز هویت کند. نیمه اول جایی است که VPN کمک می‌کند؛ نیمه دوم باید پیکربندی شود.
به چه چیزی رمزنگاری شده، دقیقاً؟
TLS گفت‌وگو را از هر کسی در میانه محافظت می‌کند و تا زمانی که کلاینت بررسی نکند، چیزی درباره هویتی که نقطه پایانی ادعا می‌کند نمی‌گوید. گواهی‌نامه‌ای که در برابر یک مرجع مورد اعتماد اعتبارسنجی می‌شود ثابت می‌کند که گواهی‌نامه از آن مرجع آمده است. ثابت نمی‌کند که گواهی‌نامه برای نام میزبانی صادر شده که می‌خواستید به آن برسید، و این‌ها پرسش‌های متفاوتی هستند.
این یک شکاف نظری نیست. پورتال‌های اسیر، اشتباهات مربوط به VRF نادرست و طرح‌های نشانی هم‌پوشان همه سروری تولید می‌کنند که کاملاً آماده مذاکره TLS با شماست. اگر کلاینت فقط رمزنگاری را الزام کند، نشست خصوصی است و به پایگاه داده اشتباه اشاره می‌کند.
بنابراین پرسش مرتبط این نیست که آیا اتصال رمزنگاری شده است، بلکه این است که آیا به هویتی که در نظر داشتید رمزنگاری شده است. در کلاینت MySQL، این تمایز کاملاً در تنظیم ssl-mode زندگی می‌کند.
پنج مقدار ssl-mode در عمل
پنج مقدار وجود دارد و تنها یکی از آن‌ها به پرسش این راهنما پاسخ می‌دهد. جدول آنچه هر یک واقعاً تضمین می‌کند را فهرست می‌کند، نه آنچه نامش القا می‌کند.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
تنها ردیف آخر به پرسش این مقاله پاسخ می‌دهد. PREFERRED به‌تنهایی ارزش اشاره دارد، زیرا کلاینتی که بی‌صدا به متن ساده سقوط می‌کند بدتر از کلاینتی است که امتناع می‌کند: باور دارید که رمزنگاری دارید و ضبط بسته‌ها مخالف است.
اتصالی که امروز می‌توانید اجرا کنید
دستور زیر شکلی است که باید استفاده کنید، با دو جای‌نگهدار: نام پایگاه داده تأییدشده و یک فایل CA که از طریق یک کانال تأییدشده به دست آمده است. هیچ‌یک نباید از آنچه سرور در اولین تماس به شما پیشنهاد می‌کند گرفته شود.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password بدون مقدار درخواست ورودی می‌کند، که راز را از فهرست فرایندها و از تاریخچه پوسته شما بیرون نگه می‌دارد. این عادت کوچکی با سود بزرگ روی میزبان‌های جهش مشترک است، جایی که خط فرمان برای دیگر کاربران قابل مشاهده است.
وقتی این شکست می‌خورد، متن خطا موارد را بهتر از شهود از هم جدا می‌کند. شکست CA یعنی زنجیره اعتبارسنجی نمی‌شود و باید ببینید کدام CA گواهی‌نامه سرور را امضا کرده است. شکست نام میزبان یعنی زنجیره درست است و نام مطابقت ندارد، که معمولاً یعنی به سرور درست با نام اشتباه متصل شده‌اید نه به سرور اشتباه.
ظاهر شدن یک اعلان دلیل بر این نیست که گذرواژه‌ای قبلاً منتقل شده است، و اتصال ناموفق ثابت نمی‌کند که چیزی از کلاینت خارج نشده است. اگر رویدادی در گذشته را بازسازی می‌کنید، کلاینت، پیکربندی آن، افزونه احراز هویت و مرحله‌ای که شکست خورده را مشخص کنید. برآورد قرار گرفتن در معرض خطر از پیام خطای نهایی حدس زدن است.
وقتی نام از یک تونل می‌آید
هدایت پورت محلی بررسی هویت را به شکلی می‌شکند که مردم را غافلگیر می‌کند. اگر یک پورت محلی را به پایگاه داده هدایت کنید و به localhost متصل شوید، کلاینت گواهی‌نامه را در برابر localhost اعتبارسنجی می‌کند، و هیچ گواهی‌نامه‌ای برای آن نام صادر نشده است. اتصال ممکن است کاملاً امن باشد و بررسی باز هم شکست بخورد، که یعنی بررسی همان‌طور که باید کار می‌کند.
دو پاسخ صادقانه وجود دارد. به نقطه پایانی هدایت‌شده نامی بدهید که به نشانی بازگشتی تجزیه شود و در گواهی‌نامه سرور ظاهر شود، یا از نام میزبان از ابتدا تا انتها استفاده کنید تا کلاینت هویت واقعی را بررسی کند. اولی برای توسعه‌دهندگان راحت است و به کار گواهی‌نامه نیاز دارد؛ دومی استدلال درباره‌اش ساده‌تر است و اغلب پیش‌فرض درست برای خودکارسازی است. غیرفعال کردن بررسی برای اینکه هدایت کار کند، ویژگی‌ای را که می‌خواستید اضافه کنید دور می‌ریزد.
پذیرش سه شرط است
آزمون پذیرش را به‌صورت سه گزاره جداگانه بنویسید: اتصال از مسیر مورد نظر استفاده کرد، رمزنگاری الزامی بود نه ترجیحی، و هویت سرور در برابر مواد مورد اعتماد بررسی شد. یک نماد VPN سبز هیچ‌یک از آن‌ها را برقرار نمی‌کند.
برای کلاینت‌های گرافیکی و برای MariaDB، مستندات خود فروشنده را بررسی کنید نه اینکه فرض کنید املای پرچم منتقل می‌شود. مستندات MySQL درباره اتصال‌های رمزنگاری‌شده تفاوت‌های حالت‌ها و الزام توزیع CA را پوشش می‌دهد، و مرجعی است که باید قبل از تغییر رشته اتصال تولیدی بررسی کنید.