IP ส่วนตัวของ Cloud SQL ผ่าน VPN: เส้นทางที่ไม่มีใครส่งออก

หลายทีมเชื่อว่า IP ส่วนตัวของ Cloud SQL ทำงานได้เฉพาะจากภายใน VPC และความเชื่อนี้คงอยู่เพราะความล้มเหลวดูเหมือนปัญหาเรื่องฐานข้อมูล Google จัดทำเอกสารการเข้าถึงจากเครือข่ายที่เชื่อมต่อผ่าน Cloud VPN หรือ Cloud Interconnect สิ่งที่เครือข่ายเหล่านั้นต้องการไม่ใช่คุณสมบัติฐานข้อมูลพิเศษ แต่คือการแลกเปลี่ยนเส้นทางสองครั้งที่ปล่อยให้ตั้งค่าไว้เพียงครึ่งเดียวได้ง่าย ทันเนลขึ้นมา อินสแตนซ์ประมวลผลตอบสนอง และการเชื่อมต่อฐานข้อมูลหมดเวลา — เป็นชุดผสมที่ส่งคนไปยังคอนโซลผิดพอดี

ความเชื่อผิด: IP ส่วนตัวหมายถึงส่วนตัวต่อ VPC

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

เนื่องจากเป็น peering จึงมีพฤติกรรมของ peering ด้วย รวมถึงส่วนที่เส้นทางกำหนดเองไม่ข้ามโดยอัตโนมัติ

ความเชื่อผิด: ทันเนลที่ใช้งานได้พาเส้นทางของฐานข้อมูลไปด้วย

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

ทางฝั่ง Google นั่นหมายถึงการเปิด Export custom routes บนการเชื่อมต่อ peering ที่เกี่ยวข้อง และเพิ่มช่วงบริการที่จัดสรรลงในเส้นทางที่ Cloud Router ประกาศสำหรับทันเนล

รักษาการประกาศที่มีอยู่แล้วไว้ การเพิ่มช่วงบริการไม่ควรนำเส้นทาง VPC ที่เซสชัน BGP เดียวกันพาไปสำหรับทราฟฟิกอื่นออก และชุดการประกาศที่ถูกแทนที่ทั้งหมดคือการหยุดชะงักครั้งที่สองที่ซ่อนอยู่หลังครั้งแรก ตรวจสอบเส้นทางที่มีผลบนอุปกรณ์ภายนอกด้วย เพราะการเข้าถึงเกตเวย์ VPN หรือซับเน็ตอื่นพิสูจน์ได้เพียงการขนส่ง

ความเชื่อผิด: Cloud SQL Auth Proxy แก้ปัญหาเครือข่าย

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

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

ความเชื่อผิด: Private Service Connect เป็นไปตามกฎเดียวกัน

Private Service Connect ใช้ endpoint ในซับเน็ตของคุณเองและการจัดวาง DNS ที่คุณควบคุม ดังนั้นเส้นทางไปที่นั่นจึงเป็นเส้นทางปกติไปยังที่อยู่ที่คุณเป็นเจ้าของ การตั้งค่าการส่งออกของ peering ไม่ใช้กับการออกแบบนั้น และการคัดลอกการเปลี่ยนแปลง peering ไปยังการติดตั้ง PSC เพิ่มความเสี่ยงโดยไม่เพิ่มการเข้าถึง

ทั้งสองให้ที่อยู่ส่วนตัวกับคุณ ความคล้ายคลึงสิ้นสุดเพียงเท่านั้น

ทดสอบเส้นทางตามลำดับที่ถูกต้อง

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

หากช่วงไคลเอนต์ของคุณอยู่นอก RFC 1918 ให้ทบทวนข้อกำหนดเพิ่มเติมด้านการส่งออกเส้นทางและการอนุญาตเครือข่ายก่อนสรุปว่าการออกแบบไม่ได้รับการรองรับ

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