App Engine เข้าถึงฐานข้อมูล VPN ของคุณได้: สิ่งที่ต้องตรงกัน

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

คำตอบเก่ามาจากไหน

ก่อนมีคอนเนกเตอร์ คำตอบในทางปฏิบัติคือ Standard พูดคุยได้เฉพาะกับปลายทางสาธารณะ และทีมต่างๆ ย้ายไปใช้ VM พร็อกซีหรือรันไทม์อื่นเพื่อหลีกเลี่ยง แพลตฟอร์มเปลี่ยนไป แต่ตำนานไม่เปลี่ยน คำแนะนำออนไลน์จำนวนมากยังสะท้อนยุคที่ไม่มีตัวเลือก egress เลย

การแก้ไขแคบกว่าที่ฟังดู Standard เข้าถึงเครือข่ายส่วนตัวได้ แต่เฉพาะผ่านการผสานรวม egress ที่รองรับ และเฉพาะปลายทางที่การผสานรวมนั้นดักจับได้จริง

เลือกเส้นทาง egress ก่อน

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

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only ส่งปลายทางส่วนตัวเข้า VPC และปล่อยอย่างอื่นไว้บนเส้นทางอินเทอร์เน็ตปกติ ซึ่งโดยทั่วไปคือสิ่งที่การเชื่อมต่อฐานข้อมูลต้องการ all-traffic ดันทราฟฟิกขาออกผ่าน VPC อย่างกว้างขวาง ดังนั้นการเรียกอินเทอร์เน็ตทั่วไปจึงสืบทอดท่าที NAT และไฟร์วอลล์ของ VPC ด้วย

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

ที่อยู่ต้นทางคือคอนเนกเตอร์ ไม่ใช่แล็ปท็อปของคุณ

เวลาดีบักส่วนใหญ่อยู่ที่นี่ เกตเวย์ VPN ระยะไกลและไฟร์วอลล์ของฐานข้อมูลต้อง อนุญาตช่วงที่จัดสรรให้คอนเนกเตอร์ ภายใน VPC ไม่ใช่ที่อยู่สำนักงานของคุณและไม่ใช่ที่อยู่ egress สาธารณะของบริการ ค้นหาช่วงนั้นในคอนโซลก่อนเขียนกฎแม้แต่ข้อเดียว

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

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

DNS เดินทางคนละเส้นทาง

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

หากชื่อแก้เป็นที่อยู่สาธารณะจากภายใน VPC คุณกำลังจะดีบักไฟร์วอลล์ผิดตัว

URL Fetch ไม่ใช้คอนเนกเตอร์

การตั้งค่า egress ครอบคลุมซ็อกเก็ตขาออกปกติของรันไทม์ และบริการ URL Fetch แบบเดิมไม่ได้อยู่ในเส้นทางนั้น คำขอที่ออกผ่าน urlfetch จะเพิกเฉยต่อคอนเนกเตอร์ไม่ว่าการกำหนดค่าจะพูดอย่างไร เมื่อการเรียกที่ล้มเหลวอยู่ในไลบรารีเก่าที่ยังใช้ URL Fetch วิธีแก้คือย้ายการเรียกนั้นไปยังไคลเอนต์ HTTP มาตรฐาน

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

ตรวจสอบด้วยคิวรีแคบๆ หนึ่งครั้ง

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

คิวรีที่สำเร็จจาก VM ภายใน VPC ยืนยันว่าเส้นทางมีอยู่ ไม่ได้ยืนยันว่าบริการเลือกเส้นทางนั้น