ไม่ใช่ สตริงการเชื่อมต่อไม่สามารถเริ่มอุโมงค์ VPN ของคุณได้

นักพัฒนายังคงมองหาที่ที่สตริงการเชื่อมต่อ URL ของ JDBC หรือรายการใน tnsnames.ora เลือก VPN ไม่มีที่แบบนั้น อุโมงค์ถูกสร้างโดยระบบปฏิบัติการหรือไคลเอนต์ของผู้จำหน่ายที่ลงทะเบียนอะแดปเตอร์เสมือน และทุกไลบรารีฐานข้อมูลที่อยู่เหนือขึ้นไปใช้ชั้นซ็อกเก็ตที่เกิดขึ้น สตริงการเชื่อมต่อระบุโฮสต์ พอร์ต และข้อมูลประจำตัว และนั่นคือคำศัพท์ทั้งหมด

ความเชื่อผิด: สตริงการเชื่อมต่อเลือกอุโมงค์ได้

ไดรเวอร์เปิดซ็อกเก็ต TCP ไปยังโฮสต์และพอร์ต มันไม่มี API สำหรับยกอุโมงค์ ไม่มีฟิลด์สำหรับโปรไฟล์อุโมงค์ และไม่มีวิธีพิสูจน์ตัวตนกับเกตเวย์ VPN

นี่คือเหตุผลที่เครื่องมือต่างๆ มีพฤติกรรมเหมือนกันเมื่อมีเส้นทางอยู่แล้ว SSMS, DBeaver, Eclipse Data Tools และ sqlcmd ธรรมดาต่างทำตัวราวกับเซิร์ฟเวอร์อยู่ในเครือข่ายท้องถิ่น เพราะจากมุมมองของซ็อกเก็ตมันเป็นเช่นนั้น อะแดปเตอร์เสมือนทำให้ subnet ของฐานข้อมูลเข้าถึงได้ และไดรเวอร์ไม่เคยรู้ว่าทำได้อย่างไร

นี่อธิบายด้วยว่าทำไมสตริงการเชื่อมต่อจึงซ่อมอุโมงค์ที่หลุดไม่ได้ เมื่อลิงก์ตาย ไดรเวอร์รายงานว่าหมดเวลาหรือเกิดข้อผิดพลาดเครือข่ายทั่วไป และโค้ดแอปพลิเคชันที่ถือว่านี่เป็นปัญหาคิวรีจะลองผิดชั้นซ้ำไปตลอด

ยกอุโมงค์ขึ้นก่อนที่ไดรเวอร์จะทำงาน

เชื่อมต่อ VPN ในระดับระบบปฏิบัติการ ตามคำแนะนำของผู้ให้บริการหรือทีมเครือข่าย แล้วจึงเปิดเครื่องมือ ในทางปฏิบัติหมายความว่ามีเส้นทางไปยัง subnet ของฐานข้อมูลก่อนที่ไดรเวอร์จะแก้ชื่อโฮสต์

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

ความหน่วงเปลี่ยนเคอร์เซอร์ฝั่งเซิร์ฟเวอร์เป็นหมดเวลา

เคอร์เซอร์ฝั่งเซิร์ฟเวอร์ขอให้ฐานข้อมูลเก็บผลลัพธ์และดึงมาทีละน้อย ซึ่งเปลี่ยนผลลัพธ์ใหญ่หนึ่งชุดเป็นการไปกลับเล็กๆ หลายครั้ง ใน LAN นั่นถูก แต่ผ่านอุโมงค์ที่มีความหน่วงเพิ่มขึ้นหลายสิบมิลลิวินาที คิวรีเดียวกันอาจเกินเวลาของคำสั่งโดยแทบไม่ส่งข้อมูลเลย

เปลี่ยนไปใช้เคอร์เซอร์ฝั่งไคลเอนต์ หรือเพิ่มขนาดการดึงและจัดกลุ่มแถว จำนวนการไปกลับก็ลดลง คอขวดคือจำนวนการแลกเปลี่ยน ไม่ใช่ความเร็วลิงก์ตามที่ระบุ ดังนั้นการวัดปริมาณงานจะทำให้คุณเข้าใจผิด แต่การวัดการไปกลับจะไม่ การทดสอบควรใช้ชุดผลลัพธ์ที่ใหญ่ที่สุดที่ผู้ใช้ของคุณดึงจริง ไม่ใช่คิวรีแถวเดียวที่คืนผลทันที ถ้าหมดเวลาเลื่อนแต่ไม่หายไป ให้เพิ่มเวลาของคำสั่งและขนาดการดึงพร้อมกันแล้ววัดอีกครั้ง

คณิตศาสตร์เดียวกันใช้กับ ORM ที่พูดมากและไคลเอนต์ใดๆ ที่ส่งคำสั่งหนึ่งต่อแถว ถ้าแผนคิวรีดีและการถ่ายโอนน้อย ให้นับการแลกเปลี่ยนเครือข่ายก่อนปรับแต่งฐานข้อมูล

ตรวจสอบพอร์ต อินสแตนซ์ และตัวกรองในเครื่อง

อินสแตนซ์ที่ตั้งชื่อจะฟังบนพอร์ตแบบไดนามิก ดังนั้นยืนยันพอร์ตแทนการสมมติว่าเป็น 1433 บนอินสแตนซ์เริ่มต้น ค่าอ่านได้จากค่าทะเบียน TcpPort ใต้คีย์ SuperSocketNetLib ของอินสแตนซ์นั้น สำหรับ Oracle ให้ตรวจสอบว่าโฮสต์ใน tnsnames.ora แก้ชื่อได้ ที่อยู่ตอบสนอง และพอร์ตของ listener ได้รับอนุญาต 1521 เป็นค่าเริ่มต้นทั่วไป ไม่ใช่การรับประกัน

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

เขียนขั้นตอนลงในตั๋ว ไม่อย่างนั้นคนถัดไปจะทำการค้นหาสตริงการเชื่อมต่อแบบเดิมซ้ำ ซึ่งเป็นจุดที่ทุกอย่างเริ่มต้น