เปิดใช้งานการส่งต่อ IP บนเกตเวย์ GCE VPN ที่มีอยู่

VM ถูกสร้างขึ้นโดยไม่ได้เปิดการส่งต่อ IP มีซอฟต์แวร์ VPN ทำงานอยู่แล้ว และสัญชาตญาณคือการสร้างใหม่จากเทมเพลตโดยเปิดแฟล็ก การสร้างใหม่นั้นไม่จำเป็น Compute Engine เปิดเผย canIpForward เป็นพร็อพเพอร์ตี้ที่อัปเดตได้ และเส้นทางการอัปเดตตามเอกสารจะนำไปใช้พร้อม refresh แทนการรีสตาร์ต สิ่งที่แฟล็กควบคุมจริงนั้นแคบ: หากไม่มีแฟล็ก แพลตฟอร์มจะทิ้งแพ็กเก็ตที่มาถึงอินสแตนซ์แต่ไม่ได้กำหนดที่อยู่ปลายทางเป็นที่อยู่ของอินสแตนซ์เอง เกตเวย์ที่ส่งต่อทราฟฟิกของเครื่องอื่นทำเช่นนั้นจริง แฟล็กจึงต้องเปิดอยู่ ทุกอย่างหลังจากนั้นคือการกำหนดค่าของเกสต์และการกำหนดเส้นทาง ซึ่งแฟล็กไม่ได้แตะต้อง

แฟล็กอนุญาตอะไร และไม่อนุญาตอะไร

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

เมื่อเปิดการส่งต่อ อินสแตนซ์สามารถทำหน้าที่เป็นฮอปถัดไปสำหรับเส้นทาง VPC ซึ่งเป็นบทบาทที่อุปกรณ์ VPN ต้องการ แฟล็กไม่ได้บอกอะไรเกี่ยวกับไฟร์วอลล์ การกำหนดเส้นทางของเกสต์ การกำหนดค่าอุโมงค์ หรือเส้นทางขากลับ และ ค่า true บนเกตเวย์ที่เสียหายยังคงเป็นเกตเวย์ที่เสียหาย

อ่านพร็อพเพอร์ตี้ปัจจุบัน

ตรวจสอบการตั้งค่าก่อนเปลี่ยนแปลงสิ่งใด โดยใช้ describe แบบอ่านอย่างเดียวกับอินสแตนซ์ โปรเจ็กต์ และโซนที่ต้องการ:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

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

อัปเดตอินสแตนซ์ที่มีอยู่

ขั้นตอนของ Google ในการอัปเดตพร็อพเพอร์ตี้ของอินสแตนซ์จะส่งออกทรัพยากรปัจจุบัน แก้ไขพร็อพเพอร์ตี้ และส่งผลลัพธ์ นี่เป็นเวิร์กโฟลว์ที่แตกต่างจากแฟล็ก --can-ip-forward ตอนสร้าง และเป็นวิธีที่ใช้ได้กับ VM ที่กำลังทำงาน

ส่งออกคำจำกัดความไปยังไฟล์ในเครื่องก่อน และเก็บสำเนาที่ไม่เปลี่ยนแปลงไว้เปรียบเทียบ:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

ในไฟล์ที่ส่งออกนั้น ให้ตั้งค่าพร็อพเพอร์ตี้และไม่เปลี่ยนแปลงสิ่งอื่น:

canIpForward: true

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

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

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

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

นำไฟล์ที่ตรวจทานแล้วไปใช้โดยจำกัดที่ refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

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

เกสต์ยังต้องกำหนดเส้นทางให้แพ็กเก็ต

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

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

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

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

ตรวจสอบจากไคลเอนต์ที่ต้องการเข้าถึง

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

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

ลำดับงาน: อ่านพร็อพเพอร์ตี้ ส่งออกและแก้ไขหนึ่งบรรทัด ตรวจสอบด้วย NO_EFFECT นำไปใช้ด้วย REFRESH ยืนยันว่าเกสต์ส่งต่อ แล้วทดสอบจากไคลเอนต์