ทำไม VM บน GCP ของคุณจึงตอบกลับพูล IPv6 ของ OpenVPN ไม่ได้

ไคลเอนต์ VPN IPv6 ของคุณเข้าถึงเวิร์กโหลด เวิร์กโหลดตอบกลับเข้าไปในอุโมงค์ แต่คำตอบไม่เคยมาถึง สัญชาตญาณแรกคือโทษไฟร์วอลล์หรืออุโมงค์ และโดยปกติทั้งสองอย่างไม่ใช่ต้นเหตุ ที่อยู่ที่ OpenVPN แจกจ่ายให้เป็นเครือข่ายภายในที่มีอยู่เฉพาะในอุโมงค์เท่านั้น Google Cloud ไม่รู้เลยว่า fd42:90::/64 ควรอยู่หลัง VM เครื่องใดเครื่องหนึ่งจนกว่าคุณจะบอก

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

พูลคือเครือข่ายภายใน ไม่ใช่ซับเน็ต

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

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

การกำหนดที่อยู่ภายในแบบไม่ซ้ำ เช่น fd42:90::/64 เป็นตัวเลือกที่สมเหตุสมผลสำหรับเครือข่ายภายในนี้ คำนำหน้ายังเตือนว่าการออกแบบนี้เป็นส่วนตัวโดยธรรมชาติ ไม่มีสิ่งใดในพูล ULA ทำให้มันเป็นแหล่งที่มาที่ชอบด้วยกฎหมายบนอินเทอร์เน็ตสาธารณะ

ให้ VPC มีปลายทางและฮ็อปถัดไป

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

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

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

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

ต้องเปิดการส่งต่อสองครั้ง

เส้นทางนำแพ็กเก็ตไปยังอินสแตนซ์ แต่ไม่ได้ทำให้อินสแตนซ์ยินดีส่งต่อสิ่งที่ไม่ได้ส่งถึงมัน และสิทธิ์นั้นมีอยู่สองชั้น

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

sysctl -w net.ipv6.conf.all.forwarding=1

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

บอก OpenVPN ว่าใครเป็นเจ้าของอะไร

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

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

แยกทราฟฟิกออกสู่อินเทอร์เน็ตออกจากการออกแบบนี้

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

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