PostgreSQL ผ่าน VPN: pg_hba จะเห็นที่อยู่ต้นทางใด

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

สามการตัดสินใจที่ต้องไม่หลอมรวมกัน

ที่ที่เซิร์ฟเวอร์รับฟังเป็นหนึ่งการตัดสินใจ ทราฟฟิกใดเข้าถึงที่อยู่นั้นได้เป็นอย่างที่สอง ซึ่งไฟร์วอลล์ของโฮสต์และขอบเขตเครือข่ายใด ๆ ข้างหน้าเป็นผู้กำหนด ข้อมูลประจำตัวฐานข้อมูลใดยืนยันตัวตนได้จากต้นทางใดเป็นอย่างที่สาม ซึ่งกำหนดใน pg_hba.conf

แต่ละอย่างถูกบังคับใช้โดยองค์ประกอบที่ต่างกัน และแต่ละอย่างล้มเหลวด้วยข้อความที่ต่างกัน การหลอมรวมกันในการสนทนาคือสาเหตุที่ผู้คนลงเอยด้วยการแก้ไขไฟล์ HBA เพื่อแก้ปัญหาไฟร์วอลล์ รักษาลำดับไว้: ตัวรับฟังที่ไม่ผูกไว้ไม่สามารถเข้าถึงได้ พอร์ตที่ถูกกรองไม่สามารถเชื่อมต่อได้ และกฎ HBA ตัดสินใจเพียงว่าจะเกิดอะไรขึ้นหลังจากมีการเชื่อมต่อแล้ว เมื่อการเปลี่ยนแปลงไม่มีผล ให้ระบุว่าคุณเปลี่ยนชั้นใดในสามชั้นจริง ๆ

ที่ที่เซิร์ฟเวอร์รับฟัง

ผูกกับที่อยู่ที่ถูกกำหนดให้เครื่องจริง ๆ ไม่ใช่ชื่ออินเทอร์เฟซ:

listen_addresses = '10.20.0.30'

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

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

ที่อยู่ที่ HBA เห็นจริง

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

สำหรับการติดตั้งที่ใช้ TLS และ SCRAM อยู่แล้ว ตัวอย่างการเข้าถึงระยะไกลที่ตั้งใจให้แคบมีลักษณะเช่นนี้:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

สิ่งนี้อนุญาตหนึ่งบทบาทและหนึ่งฐานข้อมูลผ่าน TLS จากพูลที่ระบุ แล้วปฏิเสธการเข้าถึง TCP ระยะไกลอื่น ๆ ไม่ใช่สิ่งทดแทนไฟล์ HBA ที่สมบูรณ์: รักษาการดูแลระบบภายใน เครื่องจำลอง และบริการอื่นที่ได้รับอนุญาต และวางกฎที่แคบไว้ก่อนการอนุญาตที่กว้างกว่า

เมื่อมีการแปลต้นทาง HBA ไม่สามารถแยกแยะลูกค้าด้วยที่อยู่เดิมได้ รักษาการรับเข้าเครือข่ายให้เข้มงวดและกำหนดให้ใช้ข้อมูลรับรองฐานข้อมูลจริง และอย่าแทนที่การยืนยันตัวตน trust ด้วยบัญชีจริงเลย

รายการแรกที่ตรงกันชนะ โดยไม่มีทางเลือกสำรอง

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

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

เอกสารอ้างอิง HBA กำหนดทั้งลำดับและความแตกต่างระหว่างระเบียน host และ hostssl ซึ่งสำคัญเมื่อจุดประสงค์ของกฎคือการเชื่อมต่อต้องถูกเข้ารหัส

การโหลดใหม่ การรีสตาร์ท และกรณีถูกปฏิเสธ

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

การเปลี่ยนแปลงตัวรับฟังต้องรีสตาร์ทของตัวเอง และสองการดำเนินการนั้นสับสนได้ง่ายเมื่อการเปลี่ยนแปลงดูเหมือนไม่มีผล

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