Cloud VPN ไปยัง VM บน GCP: ใช้ IP ภายใน ไม่ใช่ IP ของ NAT
ปลายทางของเกตเวย์ ที่อยู่ภายในของ VM และที่อยู่ NAT ภายนอกแบบหนึ่งต่อหนึ่งมีงานสามอย่างที่ต่างกัน ตรวจสอบว่าเส้นทางของคุณใช้ที่อยู่ใด
เมื่อเครือข่ายภายในองค์กรเข้าถึง VPC ผ่าน Cloud VPN ปลายทางสำหรับบริการ Compute Engine มักเป็นที่อยู่ภายในของ VM ที่อยู่ IPv4 ภายนอกไม่ใช่ที่อยู่ที่สองที่คุณจะใส่แทนในเส้นทางส่วนตัวเดียวกันได้ ความสับสนส่วนใหญ่ในด้านนี้มาจากการปฏิบัติต่อที่อยู่สามรายการซึ่งมีสามหน้าที่ราวกับว่าสลับกันได้ ดังนั้นเริ่มจากการระบุว่าแพ็กเก็ตหนึ่งใช้ที่อยู่ใด
สามที่อยู่ สามหน้าที่
ระบุทั้งสามก่อนที่คุณจะดีบักที่อยู่ใด ๆ เพราะคำตอบเปลี่ยนวัตถุที่คุณจะตรวจสอบต่อไป
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
ที่อยู่แรกเป็นของอุโมงค์ ที่สองเป็นของการออกแบบเส้นทางและไฟร์วอลล์ของคุณ ที่สามเป็นของการเข้าถึงอินเทอร์เน็ตขาเข้าและถูกแมป ไม่ได้ถูกแนบ การออกแบบที่ใช้ได้กับที่อยู่หนึ่งไม่ได้บอกอะไรเกี่ยวกับอีกสองที่อยู่
ทำไมที่อยู่ภายนอกจึงไม่ใช่อินเทอร์เฟซที่สอง
คู่มือการกำหนดที่อยู่คือแหล่งอ้างอิงว่าการเข้าถึงภายในและภายนอกแตกต่างกันอย่างไรบน Compute Engine ที่อยู่ IPv4 ภายนอกของ Compute Engine เป็นการแมปแบบหนึ่งต่อหนึ่งบน NIC ภายในเพียงตัวเดียวของอินสแตนซ์ ผู้เยี่ยมชมจึงไม่เคยเห็นอินเทอร์เฟซที่สองหรือที่อยู่ที่สองบน NIC นั้น สิ่งที่ VM รายงานจากภายในยังคงเป็นที่อยู่ภายในหลักหนึ่งรายการ
นั่นคือเหตุผลที่ไคลเอนต์ส่วนตัวที่กำหนดเส้นทางผ่านอุโมงค์ไปยัง 10.24.1.7 กับไคลเอนต์ที่มุ่งเป้าไปที่ที่อยู่ภายนอกของ VM อยู่บนเส้นทางที่ต่างกัน การเปิดกฎไฟร์วอลล์สำหรับที่อยู่สาธารณะไม่เปลี่ยนอะไรในเส้นทาง VPC ที่ต้องขนส่งทราฟฟิกของอุโมงค์ และการแก้ไขเส้นทางบนผู้เยี่ยมชมไม่ขยับการแมปของแพลตฟอร์ม เลือกที่อยู่ที่เส้นทางของคุณระบุ แล้วตรวจเฉพาะวัตถุที่ควบคุมมันเท่านั้น วินัยนี้ตัดการเดาส่วนใหญ่ออกจากเส้นทางการแก้ปัญหานี้
เดินเส้นทางด้วย gcloud
เริ่มจากอินสแตนซ์และอ่านที่อยู่ทั้งสองจากวัตถุเดียวกัน เพื่อให้รู้ว่าเอกสารของคุณกำลังพูดถึงที่อยู่ใด:
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"จากนั้นยืนยันการกำหนดเส้นทางและสิทธิ์ที่เส้นทางพึ่งพาจริง:
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1อ่านช่วงที่ประกาศและเรียนรู้ของอุโมงค์, เส้นทาง VPC สำหรับซับเน็ตของเวิร์กโหลด และกฎไฟร์วอลล์ที่อนุญาตต้นทางภายในองค์กร ทั้งสามอย่างนี้ต้องตรงกันก่อนที่ตัวรับฟังบนผู้เยี่ยมชมจะเกี่ยวข้องเสียด้วยซ้ำ
จากนั้นตรวจผู้เยี่ยมชม: บริการรับฟังบนที่อยู่ภายในหรือไม่ และเส้นทางขากลับผ่าน VPC อีกครั้งหรือไม่ ตัวรับฟังที่ผูกกับที่อยู่สาธารณะเท่านั้นจะล้มเหลวในการทดสอบนี้แม้ว่าวัตถุทุกชิ้นฝั่งคลาวด์จะถูกต้อง
คำนำหน้าสาธารณะเป็นอีกคำถามหนึ่ง
ไม่มีข้อใดข้างต้นหมายความว่าทุกที่อยู่ที่บรรทุกภายใน VPN ต้องเป็น RFC1918 เครือข่ายระยะไกลสามารถกำหนดเลขจากพื้นที่สาธารณะได้อย่างชอบธรรม หากแพลตฟอร์มรองรับการกำหนดเส้นทางและผู้ปฏิบัติงานมีอำนาจเหนือที่อยู่ นั่นเป็นการออกแบบปกติ
นี่ไม่เหมือนกับการปฏิบัติต่อที่อยู่ NAT ภายนอกทั่วไปราวกับว่าเป็นที่อยู่ซับเน็ตภายในอีกอันหนึ่ง อย่างหนึ่งคือคำนำหน้าที่คุณกำหนดเส้นทาง อีกอย่างคือการแมปที่แพลตฟอร์มใช้กับการเข้าถึงขาเข้า
IPv6 ภายนอกและการจัดวางที่อยู่ที่ออกแบบมาเป็นพิเศษมีความหมายของตัวเอง หากแผนของคุณขึ้นกับอย่างใดอย่างหนึ่ง ให้อ่านเอกสารแพลตฟอร์มสำหรับคุณลักษณะนั้นแทนการสรุปจากกรณี IPv4 การแมป IPv4 เป็นกรณีทั่วไป ไม่ใช่กรณีเดียว และข้อยกเว้นแต่ละข้อมีกฎของตัวเอง
ช่วงที่ทับซ้อนกันเป็นอีกปัญหา
ช่วงส่วนตัวที่ทับซ้อนกันเป็นเหตุผลจริงที่ผู้คนเอื้อมไปหาที่อยู่สาธารณะ และมันเป็นคันโยกที่ผิด การเปลี่ยนปลายทางเป็นที่อยู่ NAT ของ VM ไม่ได้แก้การทับซ้อน แต่เปลี่ยนว่าที่อยู่ใดที่แพ็กเก็ตอ้างว่าสำหรับ โดยไม่กำหนดว่าเส้นทางขากลับทำงานอย่างไร
แก้การทับซ้อนอย่างตั้งใจ: กำหนดเลขใหม่ ใช้การออกแบบการแปลที่รองรับ หรือกำหนดเส้นทางผ่านเครือข่ายที่คำนำหน้าไม่ชนกัน แต่ละอย่างเป็นการออกแบบที่มีเจ้าของ ที่อยู่ NAT ไม่ใช่การออกแบบ
จัดทำเอกสารสองฟิลด์แยกกัน
บันทึกคู่ของอุโมงค์และปลายทางของเวิร์กโหลดเป็นฟิลด์ runbook สองฟิลด์แยกกัน แต่ละฟิลด์มีเส้นทางและกฎไฟร์วอลล์ที่รองรับ อุโมงค์ IPsec ที่ขึ้นมาบอกเพียงว่าทั้งสองฝ่ายเห็นพ้อง ไม่ได้บอกว่าที่อยู่ใดที่เข้าถึงเวิร์กโหลดได้ และไม่ได้บอกว่าเส้นทางส่วนตัวของมันครบถ้วนหรือไม่
ตรวจสอบด้วยไคลเอนต์จริงที่อีกฝั่ง: แปลงชื่อ ยืนยันว่าคืนที่อยู่ภายใน เชื่อมต่อ และตรวจทราฟฟิกขากลับ เอกสารที่อยู่ IP ของ Compute Engine เป็นข้อมูลอ้างอิงสำหรับความแตกต่างระหว่างภายในและภายนอกที่ใช้ข้างต้น