לא, מחרוזת חיבור לא יכולה להפעיל את מנהרת ה-VPN שלך

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

מיתוס: מחרוזת החיבור יכולה לבחור מנהרה

ההתקן פותח סוקט TCP למארח ולפורט. אין לו API להעלאת מנהרה, אין שדה לפרופיל מנהרה ואין דרך לאמת מול שער VPN.

לכן הכלים מתנהגים באופן זהה כשקיים מסלול. SSMS, DBeaver, Eclipse Data Tools ו-sqlcmd רגיל מתנהגים כאילו השרת ברשת המקומית, כי מנקודת המבט של הסוקט הוא אכן שם. המתאם הווירטואלי הפך את תת-הרשת של מסד הנתונים לנגישה, וההתקן לעולם לא יודע איך.

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

העלו את המנהרה לפני שההתקן רץ

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

השאירו את הפיקוח על המנהרה מחוץ ליישום. שירות PHP או Java שמנסה להעלות את הקישור בעצמו מקודד את התנהגות של ספק אחד לתוך קוד עסקי, וכל מעבר כשל הופך לשחרור יישום. מפקח שמחזיק במנהרה, צופה בה ומפעיל אותה מחדש הוא עניין נפרד מנתיב השאילתה.

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

מיתוס: כשל אימות Windows אומר שהמסלול שבור

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

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

מתג ‎/netonly שומר את ההרשאות האלה לאימות מרחוק בלבד. אמתו מה השרת קיבל בפועל באמצעות SELECT SUSER_SNAME() במקום לסמוך על דיאלוג החיבור. דווח ששמירת ההרשאה עבור כתובת השרת ב-Windows Credential Manager עובדת ב-SSMS אבל לא תמיד בשירות שרץ תחת חשבון אחר, לכן בדקו איזו זהות התהליך משתמש לפני שמשנים את הכניסה.

השהיה הופכת סמן בצד השרת לפסק זמן

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

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

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

בדקו את הפורט, המופע והמסנן המקומי

מופע בשם מאזין בפורט דינמי, לכן אשרו את הפורט במקום להניח 1433. במופע ברירת מחדל אפשר לקרוא את הערך מערך הרישום TcpPort תחת מפתח SuperSocketNetLib של המופע. עבור Oracle, ודאו שהמארח ב-tnsnames.ora מפוענח, שהכתובת עונה ושפורט המאזין מותר; 1521 הוא ברירת מחדל נפוצה, לא הבטחה.

לאחר מכן שללו את רשימת הגישה של המנהרה עצמה, ולבסוף אנטי-וירוס מקומי או חומת אש של המארח שחוסמת את החיבור גם כשהלקוח והשרת הם אותו מחשב. תעדו את השלב שנכשל לפני שתשנו תצורה, כי פענוח שמות, נגישות TCP ו-TLS או התחברות נכשלים כל אחד בהודעה אחרת.

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