MariaDB ผ่าน VPN: เซิร์ฟเวอร์เห็น user@host ใด?
บัญชีถูกเลือกจากทั้งผู้ใช้และโฮสต์ร่วมกัน ค้นหาแหล่งที่มาที่เซิร์ฟเวอร์เห็น อ่าน CURRENT_USER() แล้วซ่อมแซวนั้น ไม่ใช่สิทธิ์
พิมพ์ชื่อผู้ใช้เดียวกันจากสองเส้นทางที่ต่างกัน และ MariaDB อาจพิสูจน์ตัวตนคุณเป็นสองบัญชีที่ต่างกัน บัญชีถูกกำหนดด้วยผู้ใช้และโฮสต์ร่วมกัน ดังนั้น 'reporter'@'localhost' และ 'reporter'@'10.90.0.23' จึงเป็นแถวแยกกันที่มีรหัสผ่านแยกกันและสิทธิ์แยกกัน เมื่อผ่าน VPN คำถามที่น่าสนใจไม่ใช่ผู้ใช้พิมพ์ชื่อใด แต่เป็น ที่อยู่ต้นทางที่เซิร์ฟเวอร์เห็น ต่างหาก
ระบุแหล่งที่มาที่เซิร์ฟเวอร์เห็นจริง
ย้อนกลับจากโฮสต์ฐานข้อมูล ไม่ใช่จากแล็ปท็อป ที่อยู่ที่ไคลเอนต์คิดว่าตนมีเป็นเพียงหนึ่งในหลายความเป็นไปได้
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
ใช้หลักฐานฝั่งเซิร์ฟเวอร์เพื่อตัดสิน บันทึกการเชื่อมต่อ รายการเซสชันที่ใช้งาน หรือรายการชั่วคราวในบันทึกทั่วไปแสดงที่อยู่ที่เซิร์ฟเวอร์ยอมรับ IP สาธารณะของแล็ปท็อปจากเบราว์เซอร์เป็นข้อเท็จจริงอีกอย่างและมักทำให้เข้าใจผิด
จับคู่บัญชีที่ MariaDB เลือก
การเลือกบัญชีเป็นไปตามลำดับที่เอกสารกำหนด ไม่ใช่การรวมสิทธิ์ การตรงกับโฮสต์แบบเจาะจงมีลำดับก่อนไวลด์การ์ด และแถวของผู้ใช้ไม่ระบุชื่อมีส่วนในการจับคู่ในแบบที่ทำให้คนที่คิดว่าชื่อเพียงอย่างเดียวเป็นตัวตัดสินประหลาดใจ เซิร์ฟเวอร์เลือกหนึ่งแถว มันไม่รวมสิทธิ์ของทุกแถวที่ชื่อเหมือนกัน การอ่านเอกสารอ้างอิงครั้งเดียวมีค่ามากกว่าการลองเดาทั้งบ่าย
นั่นหมายความว่าการเพิ่มสิทธิ์ให้ 'reporter'@'%' อาจไม่เปลี่ยนอะไรหากเซสชันพิสูจน์ตัวตนเป็น 'reporter'@'10.90.0.23' การแก้ไขต้องตกที่แถวที่ถูกเลือก จึงต้องระบุบัญชีให้ได้ก่อนแก้สิทธิ์
อ่านบัญชีที่เซสชันใช้จริง
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() บอกชื่อบัญชีที่พิสูจน์ตัวตนเซสชัน ส่วน USER() รายงานสิ่งที่ไคลเอนต์ขอและอาจแตกต่างกัน รันสิ่งเหล่านี้เป็นคำสั่งระดับบนสุดธรรมดา ไม่ใช่จากภายในรูทีนที่เก็บไว้ซึ่งมีบริบทของผู้กำหนด มิฉะนั้นคำตอบจะอธิบายเจ้าของรูทีนแทนเซสชันของคุณ
การเข้าสู่ระบบที่ล้มเหลวไม่สามารถรันสิ่งใดเหล่านี้ได้ และนั่นคือกรณีที่ผู้ดูแลระบบต้องตรวจสอบคำจำกัดความของบัญชีและหลักฐานการเชื่อมต่อของเซิร์ฟเวอร์แทน วางแผนไว้: คนที่แก้ปัญหาการเข้าสู่ระบบที่ถูกปฏิเสธมักไม่มีเซสชัน SQL ให้สอบถาม
แยกความสามารถในการเข้าถึงออกจากการพิสูจน์ตัวตน
ข้อความแสดงข้อผิดพลาดบอกคุณว่าอยู่ชั้นใด การเชื่อมต่อถูกปฏิเสธหรือหมดเวลาหมายความว่าไคลเอนต์ไม่เคยไปถึงตัวรับฟัง ดังนั้นบัญชีและรหัสผ่านยังไม่เป็นคำถาม คำตอบว่าปฏิเสธการเข้าถึงหมายความว่าเซิร์ฟเวอร์ตอบ แสดงว่าถึงได้และชี้ไปที่บัญชี การตรงกับโฮสต์ หรือข้อมูลรับรอง
ข้อกำหนดเบื้องต้นของเครือข่ายเป็นรายการของตัวเอง ตัวรับฟังที่ผูกกับที่อยู่ที่ต้องการไม่ใช่เฉพาะลูปแบ็ก การรับส่งที่อนุญาตไปยังพอร์ตที่กำหนด และเส้นทางกลับสำหรับคำตอบ แต่ละอย่างล้มเหลวได้อย่างอิสระ และอุโมงค์ที่ใช้งานได้ไม่ได้หมายความถึงสิ่งใดสิ่งหนึ่งเลย ตัวรับฟังบนลูปแบ็กยอมรับการเชื่อมต่อภายในและปฏิเสธทุกการเชื่อมต่อจากระยะไกล ซึ่งทำให้เกิดการเชื่อมต่อถูกปฏิเสธที่ดูเหมือนไฟร์วอลล์บล็อก
ตรวจสอบที่อยู่ผูกก่อนเปิดตั๋วกับทีมเครือข่าย ss -lntp บนโฮสต์ฐานข้อมูลแสดงว่าที่อยู่และพอร์ตใดกำลังรับฟังจริง และบรรทัดเดียวนั้นตัดความเป็นไปได้ทั้งหมวดออก
ซ่อมแซมอย่างแคบ แล้วทดสอบทั้งสองทิศทางใหม่
สร้างบัญชีที่ต้องการซึ่งระบุโฮสต์ผ่านกระบวนการที่องค์กรอนุมัติ ด้วยข้อมูลรับรองจากที่เก็บที่รองรับ ไม่ใช่ข้อมูลที่แชร์และวางในตั๋ว ให้เฉพาะการดำเนินการกับสคีมาที่งานต้องการ การเปลี่ยนการเข้าสู่ระบบระยะไกลที่ล้มเหลวเป็นบัญชี root นโยบายให้ทุกอย่าง หรือโฮสต์ไวลด์การ์ดแบบเหมารวมทำให้การทดสอบผ่านและลบการควบคุมที่คุณกำลังทดสอบ สิทธิ์ที่คุณเพิ่มอย่างเร่งรีบคือสิทธิ์ที่ไม่มีใครถอนออกในภายหลัง
ทดสอบใหม่ด้วยเซสชันใหม่ผ่านเส้นทางที่ต้องการ แล้วตรวจสอบกรณีเชิงลบ เส้นทางที่ควรถูกบล็อกต้องยังถูกบล็อก และการดำเนินการที่ไม่ได้ให้สิทธิ์ต้องยังถูกปฏิเสธ การตรวจสองอย่างนี้คือสิ่งที่แยกบัญชีที่ซ่อมแล้วออกจากบัญชีที่ขยายเกิน
สุดท้าย บันทึกที่อยู่ต้นทางที่สังเกตได้และชื่อบัญชีไว้ด้วยกัน อุโมงค์ให้ความสามารถในการเข้าถึง MariaDB ยังคงเลือกและอนุญาตบัญชีของตัวเอง และคนถัดไปต้องมีข้อเท็จจริงทั้งสองเพื่อทำผลลัพธ์ของคุณซ้ำ