MySQL localhost דרך VPN: זה עדיין אומר התהליך המקומי

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

הרשימה מסתיימת כשאתם יכולים לנקוב בקצה, בפרוטוקול הלקוח, בכתובת המקור שהשרת ראה ובהרשאה שאפשרה זאת. ארבע עובדות, והבעיה הבאה בחיבור אורכת דקות במקום אחר צהריים.