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 socket โดยค่าเริ่มต้น การเปลี่ยนแค่พอร์ตจึงอาจทำให้มันยังหา socket ที่ไม่เกี่ยวข้องกับการส่งต่อของคุณ ใช้โปรโตคอล 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 socket ภายในเครื่อง พอร์ตส่งต่อของคุณ หรือตัวรับฟังส่วนตัว ความล้มเหลวสามอย่างนี้มีวิธีแก้ต่างกัน และการเปลี่ยนเส้นทาง VPN ขณะไคลเอนต์ยังคุยกับ localhost ที่ผิดคือการเสียแรงเปล่า เก็บการยืนยันตัวตน SSH และการยืนยันตัวตนฐานข้อมูลแยกกันในบันทึกด้วย เพราะจากไคลเอนต์เดสก์ท็อปความล้มเหลวของอย่างหนึ่งดูเหมือนความล้มเหลวของอีกอย่าง จากนั้นลบการส่งต่อเมื่อคุณทำเสร็จ

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