Cloud Run สู่ VPN ภายในองค์กร: ตั้งค่า Direct VPC egress

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

เชื่อมรีวิชันก่อนแก้ไขอุโมงค์

Cloud Run รองรับ Direct VPC egress ซึ่งวางทราฟฟิกของบริการบนซับเน็ตใน VPC ของคุณโดยไม่ต้องใช้ตัวเชื่อมต่อ Serverless VPC Access สำหรับบริการที่มีอยู่ การอัปเดตมีลักษณะดังนี้:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

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

เลือกโหมดขาออกที่ตรงกับปลายทาง

private-ranges-only ส่งปลายทางที่จัดว่าเป็นส่วนตัวผ่าน VPC ซึ่งไม่ได้หมายความว่า «ทุกอย่างที่เข้าถึงได้ผ่าน VPN» และช่องว่างนั้นจะปรากฏเมื่อบริการภายในอยู่ในช่วงที่การตั้งค่าไม่ได้จัดประเภทเช่นนั้น หากปลายทางไม่ครอบคลุม all-traffic คือโหมดอื่นที่มีเอกสารรองรับ และส่งทุกอย่างผ่าน VPC รวมถึงการพึ่งพาสาธารณะของบริการ เลือกอย่างมีสติและบันทึกผลลัพธ์ในบันทึกการเปลี่ยนแปลง

บริการที่ใช้ตัวเชื่อมต่ออยู่แล้วต้องย้าย ไม่ใช่สลับ ดังนั้นจงวางแผนแทนที่จะกำหนดค่าทั้งสอง

กำหนดเส้นทางต้นทางของ Cloud Run ไม่ใช่ต้นทางของ VM

Direct VPC egress จัดสรรที่อยู่ชั่วคราวจากซับเน็ตที่เลือก และฝั่งภายในต้องส่งทราฟฟิกกลับไปยังช่วงนั้น เส้นทางย้อนกลับหรือการอนุญาตไฟร์วอลล์ที่เขียนไว้สำหรับซับเน็ต VM อื่นจะดูถูกต้องในแผนภาพแต่ล้มเหลวในทางปฏิบัติ ดึง CIDR ของซับเน็ตจาก VPC ไม่ใช่จากความจำ แล้วยืนยันว่าคริปโต ACL หรือตารางเส้นทางของอุปกรณ์ปลายทางรวมไว้

ด้วยการกำหนดเส้นทางแบบไดนามิก ตรวจสอบว่า Cloud Router ประกาศอะไรจริงและ VPC นำเข้าอะไร รวมถึงนโยบายการประกาศที่กำหนดเองใด ๆ เส้นทางที่มีในคอนโซลแต่ไม่ได้เลือกสำหรับปลายทางนี้เท่ากับไม่มีเส้นทาง

สามเงื่อนไขที่ต้องเป็นจริงทั้งหมด

เส้นทางที่ใช้งานได้ต้องมีทุกข้อต่อไปนี้ และแต่ละข้อล้มเหลวในแบบของตัวเอง:

• เส้นทางใน VPC ไปยังคำนำหน้าภายในผ่านการเชื่อมต่อ Cloud VPN ที่ตั้งใจไว้
• เส้นทางย้อนกลับฝั่งภายในสำหรับซับเน็ตของ Cloud Run
• ขอบเขตการป้องกันไฟร์วอลล์และ IPsec ที่อนุญาตต้นทาง ปลายทาง และพอร์ต

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

อย่าใส่ที่อยู่ Cloud Run ชั่วคราวเพียงรายการเดียวในรายการที่อนุญาต ใช้ช่วงของซับเน็ตและการออกแบบการอนุญาตที่เหมาะกับแอปพลิเคชัน

ทดสอบรีวิชันที่ให้บริการคำขอ

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

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

การย้อนกลับและสิ่งที่สิ่งนี้ไม่ได้ทำ

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

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