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 עדיין בוחרת ומאשרת את החשבון שלה, והאדם הבא זקוק לשתי העובדות כדי לשחזר את התוצאה שלכם.