ไคลเอนต์ฐานข้อมูลในเครื่องกับ RDS ส่วนตัว: ทำไมการเชื่อมต่อจึงหมดเวลา

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

อ่านความล้มเหลวในชั้นที่ถูกต้อง

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

dig +short db.internal.example
nc -vz db.internal.example 5432

ถ้าชื่อคืนที่อยู่สาธารณะ หรือคืนค่าเปล่า อุโมงค์ยังไม่ใช่ปัญหา

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

แยกอุโมงค์ออกจากเส้นทาง

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

ip route get 10.20.40.15
ip addr show tun0

เส้นทางที่ชี้ไปยังอินเทอร์เฟซอุโมงค์เป็นสิ่งจำเป็น แต่ยังไม่เพียงพอ เพราะอีกฝั่งยังต้องยอมรับทราฟฟิก

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

จับคู่กลุ่มความปลอดภัยกับต้นทางจริง

กลุ่มความปลอดภัยของ RDS อนุญาตต้นทาง ไม่ใช่บุคคล ขึ้นอยู่กับสถาปัตยกรรม ต้นทางอาจเป็นพูลไคลเอนต์ VPN ที่อยู่ส่วนตัวของแบสเตียน หรือที่อยู่ NAT ที่ทราฟฟิกถูกแปลงไป อ่านกฎและต้นทางจริงของแพ็กเก็ตไปพร้อมกัน

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

กฎสำหรับที่อยู่บ้านของแล็ปท็อปเครื่องเดียวเป็นปัญหาการบำรุงรักษา ไม่ใช่การออกแบบการเข้าถึง

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

เลือกเส้นทางแคบกว่าเส้นทางกว้าง

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

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

รักษาการตรวจสอบ TLS ให้ครบถ้วนในการออกแบบนั้น ไคลเอนต์ยังควรตรวจสอบใบรับรองเซิร์ฟเวอร์กับชื่อที่คาดไว้ พอร์ตที่ส่งต่อในเครื่องไม่ใช่เหตุผลที่จะปิดการตรวจสอบ และการปิดมันจะซ่อนปัญหาตัวตนที่ควรจับไว้พอดี

การเลือกหว่างอุโมงค์เต็มรูปแบบกับการส่งต่อแคบ ๆ เป็นการตัดสินใจเรื่องขอบเขต ไม่ใช่ละครความปลอดภัย

ทิ้งเส้นทางที่ทำซ้ำได้ไว้ข้างหลัง

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

จากนั้นทดสอบกรณีลบหนึ่งครั้ง ไคลเอนต์ที่อยู่นอกต้นทางที่อนุมัติยังควรถูกปฏิเสธ

ฐานข้อมูลส่วนตัวที่ใช้งานได้เฉพาะคนที่ตั้งค่ามันไม่ใช่การเข้าถึงส่วนตัว แต่เป็นข้อยกเว้นที่ไม่ได้บันทึกไว้รอการค้นพบอีกครั้ง เขียนเส้นทางไว้ แล้วนักพัฒนาคนต่อไปจะได้รับวิธีการแทนปริศนา