MariaDB روی VPN: سرور کدام user@host را می‌بیند؟
حساب با کاربر و میزبان با هم انتخاب می‌شود. منبعی را که سرور دیده است پیدا کنید، CURRENT_USER() را بخوانید و سپس همان سطر را اصلاح کنید، نه مجوز را.
همان نام کاربری را از دو مسیر مختلف وارد کنید و ممکن است MariaDB شما را به عنوان دو حساب مختلف احراز هویت کند. حساب‌ها با کاربر و میزبان با هم کلید می‌خورند، بنابراین 'reporter'@'localhost' و 'reporter'@'10.90.0.23' سطرهای جداگانه با رمزهای عبور جداگانه و مجوزهای جداگانه هستند. روی VPN، پرسش جالب این نیست که کاربر چه نامی تایپ کرده، بلکه این است که سرور کدام نشانی مبدأ را دیده است.
منبعی را که سرور واقعاً می‌بیند تعیین کنید
از میزبان پایگاه داده به عقب کار کنید، نه از لپ‌تاپ. نشانی‌ای که کلاینت فکر می‌کند دارد فقط یکی از چندین احتمال است:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
برای حل این موضوع از شواهد سمت سرور استفاده کنید. گزارش اتصال، فهرست نشست‌های فعال یا یک ورودی موقت در گزارش عمومی نشانی‌ای را نشان می‌دهد که سرور پذیرفته است. IP عمومی لپ‌تاپ از مرورگر واقعیت دیگری است و اغلب گمراه‌کننده.
حسابی را که MariaDB انتخاب کرده تطبیق دهید
انتخاب حساب از ترتیب مستند پیروی می‌کند نه از اجتماع مجوزها. تطابق دقیق میزبان بر نویسه عام اولویت دارد و سطرهای کاربر ناشناس به روش‌هایی در تطبیق شرکت می‌کنند که کسانی را که گمان می‌کنند فقط نام تعیین‌کننده است شگفت‌زده می‌کند. سرور یک سطر را انتخاب می‌کند؛ امتیازات هر سطر هم‌نام را ادغام نمی‌کند. یک بار خواندن مرجع ارزشمندتر از یک بعدازظهر آزمودن حدس‌هاست.
این یعنی افزودن یک مجوز به 'reporter'@'%' ممکن است هیچ چیز را تغییر ندهد اگر نشست به عنوان 'reporter'@'10.90.0.23' احراز هویت شده باشد. اصلاح باید روی سطری بنشیند که انتخاب شده بود، به همین دلیل شناسایی حساب پیش از ویرایش مجوزها می‌آید.
حسابی را که نشست واقعاً استفاده می‌کند بخوانید
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() حسابی را نام می‌برد که نشست را احراز هویت کرده است؛ USER() آنچه کلاینت خواسته را گزارش می‌کند و می‌تواند متفاوت باشد. آن‌ها را به عنوان پرس‌وجوهای عادی سطح بالا اجرا کنید، نه از داخل یک روال ذخیره‌شده با زمینه تعریف‌کننده، وگرنه پاسخ‌ها مالک روال را توصیف می‌کنند نه نشست شما را.
ورود ناموفق نمی‌تواند هیچ‌یک از این‌ها را اجرا کند، و این همان حالتی است که مدیر باید به جای آن تعاریف حساب و شواهد اتصال سرور را بررسی کند. برای آن برنامه‌ریزی کنید: کسی که ورود ردشده را اشکال‌زدایی می‌کند معمولاً هیچ نشست SQL برای پرس‌وجو ندارد.
دسترسی‌پذیری را از احراز هویت جدا کنید
متن خطا به شما می‌گوید در کدام لایه هستید. اتصال ردشده یا وقفه زمانی یعنی کلاینت هرگز به شنونده نرسیده، پس حساب و رمز عبورش هنوز زیر سؤال نیستند. پاسخ دسترسی ردشده یعنی سرور پاسخ داده، که دسترسی‌پذیری را اثبات می‌کند و به حساب، تطابق میزبان یا اعتبارنامه اشاره می‌کند.
پیش‌نیازهای شبکه فهرست خودشان را دارند: شنونده‌ای متصل به نشانی موردنظر و نه فقط به loopback، ترافیک مجاز به پورت پیکربندی‌شده و مسیر بازگشت برای پاسخ. هر یک می‌تواند مستقلاً شکست بخورد و تونل کارکننده هیچ‌یک از آن‌ها را تضمین نمی‌کند. شنونده روی loopback اتصال‌های محلی را می‌پذیرد و هر اتصال راه دور را رد می‌کند، که اتصال ردشده‌ای شبیه به مسدودسازی فایروال تولید می‌کند.
پیش از باز کردن تیکت برای تیم شبکه، نشانی اتصال را بررسی کنید. ss -lntp روی میزبان پایگاه داده نشان می‌دهد کدام نشانی و پورت واقعاً گوش می‌دهند و همان یک خط یک دسته کامل از حدس‌ها را حذف می‌کند.
باریک اصلاح کنید، سپس هر دو جهت را دوباره بیازمایید
حساب موردنظرِ واجد میزبان را از طریق فرایند تأییدشده سازمان ایجاد کنید، با اعتبارنامه‌ای از مخزن پشتیبانی‌شده نه یکی مشترک که در تیکت چسبانده شده. فقط عملیات طرح‌واره‌ای را که وظیفه نیاز دارد اعطا کنید. تبدیل یک ورود راه دور ناموفق به حساب root، سیاست اعطای همه یا میزبان عام سراسری آزمون را قبول می‌کند و کنترلی را که در حال آزمودنش بودید حذف می‌کند. مجوزی که با عجله افزودید همانی است که بعداً کسی حذفش نمی‌کند.
با نشستی تازه از مسیر موردنظر دوباره بیازمایید، سپس موارد منفی را بررسی کنید. مسیری که باید مسدود باشد باید همچنان مسدود بماند و عملیاتی که اعطا نشده باید همچنان رد شود. همان دو بررسی چیزی است که حساب اصلاح‌شده را از حساب گسترش‌یافته جدا می‌کند.
سرانجام، نشانی مبدأ مشاهده‌شده و نام حساب را با هم ثبت کنید. تونل دسترسی‌پذیری را فراهم می‌کند؛ MariaDB هنوز حساب خودش را انتخاب و مجاز می‌کند و نفر بعدی برای بازتولید نتیجه شما به هر دو واقعیت نیاز دارد.