อินสแตนซ์แบบมีชื่อของ SQL Server ผ่าน VPN: การค้นหา ไม่ใช่พอร์ต 1433

คนส่วนใหญ่ถือว่าชื่อโฮสต์ของ SQL Server เป็นที่อยู่ที่สมบูรณ์ และมอง VPN ว่าเป็นสิ่งที่อนุญาตหรือไม่อนุญาต ในทางปฏิบัติ อินสแตนซ์แบบมีชื่อทำให้ไคลเอนต์ต้องค้นหาครั้งที่สองหลังจาก DNS และการค้นหานั้นคือส่วนที่อุโมงค์มักพังบ่อยที่สุด ปลายทางที่ระบุชัดเจนหลีกเลี่ยงปัญหานี้ จึงเป็นเหตุให้ tcp:host,port ทำงานได้ในขณะที่ host\INSTANCE หมดเวลา ความแตกต่างอยู่ระหว่างการพบบริการกับการได้รับอนุญาตให้ใช้บริการนั้น

ความเชื่อผิด: ชื่อโฮสต์หนึ่งชื่อหมายถึงพอร์ตเดียว

ชื่อโฮสต์แปลงเป็นที่อยู่ และงานของมันจบตรงนั้น อินสแตนซ์แบบมีชื่อเพิ่มชื่ออินสแตนซ์ที่เซิร์ฟเวอร์ต้องแปลงเป็นพอร์ต TCP และไคลเอนต์ไม่สามารถเดาได้ พอร์ต 1433 เป็นค่าเริ่มต้นของอินสแตนซ์เริ่มต้น ไม่ใช่คุณสมบัติของทุกอินสแตนซ์บนเครื่อง การถือว่าทั้งสองอย่างเป็นสิ่งเดียวกันทำให้เกิดอาการคลาสสิก: ping ทำงาน DNS ทำงาน การสแกน 1433 ไม่แสดงอะไร และข้อสรุปคือเครือข่ายบล็อก SQL

สมมติฐานที่สองล้มเหลวเช่นเดียวกัน: การเปิด TCP 1433 นั้นเพียงพอ หากอินสแตนซ์รับฟังที่อื่น พอร์ต 1433 ที่เปิดอยู่เพียงพิสูจน์ว่ามีอย่างอื่นอยู่ที่นั่น พอร์ตต้องตรงกับตัวรับฟัง และ ว่าตัวรับฟังเป็นรายละเอียดการกำหนดค่าฝั่งเซิร์ฟเวอร์ ควรถามแทนการเดา

ไคลเอนต์ทำอะไรจริง ๆ กับอินสแตนซ์แบบมีชื่อ

หลังจากแปลงชื่อโฮสต์แล้ว ไคลเอนต์ส่งคำขอค้นหาไปยัง SQL 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 เป็นที่อยู่ที่สมบูรณ์ มันคือโฮสต์บวกกับการค้นหาที่อุโมงค์อาจไม่พาไปสำหรับอินสแตนซ์แบบมีชื่อ ระบุพอร์ต ระบุเส้นทางการค้นหา และความล้มเหลวครั้งถัดไปจะบอกว่าต้องแก้เลเยอร์ใด