מופע בשם של SQL Server דרך VPN: גילוי, לא פורט 1433

רוב האנשים מתייחסים לשם מארח של SQL Server ככתובת מלאה, ול-VPN כאל משהו שמותר או לא. בפועל, מופע בשם מחייב את הלקוח לבצע חיפוש שני אחרי DNS, והחיפוש הזה הוא החלק שקרוב לוודאי ישבר במנהרה. נקודת קצה מפורשת עוקפת אותו, ולכן tcp:host,port יכול לעבוד בעוד host\INSTANCE מגיע לפסק זמן. ההבדל הוא בין למצוא את השירות לבין לקבל רשות להשתמש בו.

המיתוס: שם מארח אחד משמעו פורט אחד

שם המארח נפתר לכתובת, ושם תפקידו נגמר. מופע בשם מוסיף שם מופע שעל השרת לתרגם לפורט TCP, והלקוח אינו יכול לנחש אותו. פורט 1433 הוא ברירת המחדל של מופע ברירת מחדל, לא תכונה של כל מופע במכונה. התייחסות לשניהם כדבר אחד מייצרת את התסמין הקלאסי: ping עובד, DNS עובד, סריקת 1433 לא מראה דבר, והמסקנה היא שהרשת חוסמת SQL.

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

מה הלקוח באמת עושה עם מופע בשם

לאחר פתרון המארח, הלקוח שולח בקשת גילוי ל-SQL Server Browser ב-UDP 1434 ושואל איזה פורט משתמש המופע בשם. שירות הדפדפן עונה מהרישום של השרת עצמו, ואז הלקוח פותח חיבור TCP לאותו פורט. שני פרוטוקולים ושני פורטים מעורבים לפני שמנסים התחברות בכלל.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

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

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

למה נקודת הקצה המפורשת עובדת כשהשם לא

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

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

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

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

אחרי הגילוי: אימות וזהות הם נפרדים

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

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

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