FortiGate หลัง NAT: local-gw, localid และ IP สาธารณะ

FortiGate ที่อยู่หลัง NAT สามารถมี 10.0.0.2 บนอินเทอร์เฟซ WAN ขณะที่อินเทอร์เน็ตแสดงให้เห็นเป็น 198.51.100.40 และตัวเลขทั้งสองเป็นของจริง ที่อยู่ที่อุปกรณ์ผูกไว้และตัวตนที่ส่งระหว่างการพิสูจน์ตัวตน IKE เป็นการตัดสินใจแยกกัน ทำในฟิลด์แยกกัน สำหรับผู้ชมแยกกัน NAT เขียนที่อยู่ภายนอกใหม่ระหว่างทาง แต่ไม่เขียนตัวตนที่ผ่านการพิสูจน์แล้วให้เป็นสิ่งที่คู่ค้าปลายทางคาดหวัง ความล้มเหลวของเฟส 1 ส่วนใหญ่ในรูปแบบนี้มาจากการใส่ค่าที่ถูกต้องในฟิลด์ที่ผิด

สามค่า สามเจ้าของ

เริ่มจากการตั้งชื่อค่าทั้งสามและระบุว่าใครเป็นเจ้าของแต่ละค่า local-gw คือที่อยู่ที่ FortiGate ใช้เป็นแหล่งสำหรับ IKE บนอินเทอร์เฟซภายนอก และต้องเป็นที่อยู่ที่อุปกรณ์มีอยู่จริง จุดปลายสาธารณะคือที่อยู่ของอุปกรณ์ NAT และเป็นของใครก็ตามที่ทำการแปล ตัวตน IKE คือสตริงที่คู่ค้าใช้เปรียบเทียบกับการกำหนดค่าของตัวเอง และไม่จำเป็นต้องเป็นที่อยู่ IP เลย

ชื่อฟิลด์ใกล้กันพอที่จะชักจูงให้สลับกัน และนั่นคือกับดัก localid และ localid-type อธิบายการระบุตัวตน; local-gw อธิบายการผูกภายใน

ตัวอย่างทำให้ความแตกต่างเป็นรูปธรรม บน FortiGate ให้เปิด config vpn ipsec phase1-interface จากนั้น set interface "wan1" และ set local-gw 10.0.0.2 — ที่อยู่ที่กล่องมีอยู่ และนี่คือสิ่งที่ทำให้ซ็อกเก็ต IKE ผูกได้สำเร็จ ปล่อย local-gw ไว้ที่ 0.0.0.0 แล้วจะใช้ที่อยู่ของอินเทอร์เฟซ ซึ่งโดยปกติเป็นสิ่งเดียวกันแต่ชัดเจนน้อยกว่า อย่าตั้ง local-gw เป็น 198.51.100.40 เพราะอุปกรณ์ไม่ได้เป็นเจ้าของที่อยู่นั้นและซ็อกเก็ตจะไม่ผูกกับมัน การทำให้สองค่าดูเท่ากันบนกระดาษไม่ใช่การกำหนดค่า

ขั้นที่ 1: เลือกตัวตนที่คู่ค้าจะยอมรับ

ตอนนี้คือตัวตน ซึ่งเป็นการตัดสินใจที่แตกต่าง set localid รับค่าที่คู่ค้าจะเปรียบเทียบ และ set localid-type บอก FortiGate ว่าจะตีความอย่างไร: ที่อยู่ FQDN FQDN ของผู้ใช้ หรือ ID กุญแจ ด้วย auto อุปกรณ์จะอนุมานมัน โดยปกติจากที่อยู่ของอินเทอร์เฟซขาออก ซึ่งเป็นค่าที่อุปกรณ์ NAT กำลังจะเปลี่ยน

การอนุมานนั้นคือเหตุผลที่ตัวตนที่ชัดเจนสำคัญในโทโพโลยีนี้ หากคู่ค้าคาดหวังตัวตนแบบที่อยู่ ให้ตั้ง localid-type address และ localid เป็นที่อยู่สาธารณะที่คู่ค้าจะเห็น แล้วยืนยันว่าคู่ค้ายอมรับค่านั้นเป็นตัวตนไม่ใช่เป็นเป้าหมายการกำหนดเส้นทาง หากคู่ค้าคาดหวัง FQDN ให้ใช้ localid-type fqdn และชื่อที่ใช้กำหนดค่า ตรวจสอบว่าสิ่งที่ส่งไปจริงคืออะไรด้วย diagnose vpn ike gateway list ซึ่งแสดงสถานะเกตเวย์และตัวระบุที่ใช้อยู่ ไม่ใช่สิ่งที่คุณตั้งใจจะพิมพ์ อย่าสันนิษฐานว่าตัวเลือกประเภทตัวตนยอมรับที่อยู่ที่ไม่ใช่ภายในตามอำเภอใจ ตรวจสอบความหมายที่เอกสารระบุของรีลีสก่อน

ขั้นที่ 2: ส่งต่อ UDP 500 และ 4500 ไปยังอุปกรณ์

ค่าที่สามเป็นของอุปกรณ์ NAT และเป็นค่าที่คนลืมตรวจสอบ จุดปลายสาธารณะต้องส่งต่อ UDP 500 และ UDP 4500 ไปยัง FortiGate เพราะการตรวจจับ NAT-T และ ESP ที่ห่อหุ้มซึ่งตามมาล้วนขึ้นอยู่กับการมาถึงของพอร์ตเหล่านั้น การออกแบบนี้ถือว่ามีการแมปแบบหนึ่งต่อหนึ่ง; การแบ่งที่อยู่สาธารณะเดียวตามพอร์ตระหว่างคู่ค้าหลายรายเป็นโทโพโลยีอื่นที่มีข้อจำกัดต่างกัน

ยืนยันการส่งต่อด้วยการดักจับ ไม่ใช่ด้วยความหวัง: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 แสดงว่าแพ็กเก็ตมาถึงหรือไม่และการตอบกลับออกไปหรือไม่

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

ขั้นที่ 3: ตรวจสอบว่าเฟส 1 ไม่ได้แก้อะไร

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

ดังนั้นให้ตรวจสอบเป็นชั้น ๆ get vpn ipsec tunnel details แสดงว่าอุโมงค์ขึ้นหรือไม่และตัวเลือกใดถูกเจรจา และความไม่ตรงกันระหว่างซับเน็ตไกลที่กำหนดค่าไว้กับตัวเลือกที่เจรจาเป็นปัญหาการกำหนดเส้นทางในชุดเฟส 2 execute vpn ike gateway clear บังคับให้เจรจาใหม่ คุณจึงทดสอบการกำหนดค่าปัจจุบันไม่ใช่เซสชันที่สร้างก่อนการเปลี่ยนแปลงครั้งล่าสุดของคุณ จากนั้นส่งทราฟฟิกไปยังโฮสต์ในคำนำหน้าไกลและยืนยันว่าตัวนับขยับ เพราะอุโมงค์ที่ขึ้นอยู่แต่ไม่ผ่านอะไรเลยดูเหมือนอันที่ทำงานได้จนกว่าคุณจะตรวจสอบ

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

การเปลี่ยนเลขอุปกรณ์ NAT ไม่ใช่เหตุผลที่จะแตะ local-gw ของ FortiGate และการเปลี่ยนตัวตนไม่ใช่เหตุผลที่จะเปลี่ยนเลขอะไร การผสมทั้งสองอย่างคือวิธีที่อุโมงค์ที่ทำงานอยู่ถูกสร้างใหม่ระหว่างหน้าต่างบำรุงรักษาที่ไม่เกี่ยวข้อง คำแนะนำ NAT ของ Cloud VPN เป็นข้อมูลอ้างอิงสำหรับโทโพโลยีที่รองรับในด้านนั้น

การทดสอบที่ชี้ขาดนั้นน่าเบื่อและรวดเร็ว: ดักจับบนอินเทอร์เฟซภายนอก ยืนยันว่า UDP 500 และ 4500 มาจากคู่ค้า ยืนยันว่าตัวตนในการแลกเปลี่ยน IKE ตรงกับสิ่งที่คู่ค้าถูกกำหนดค่าให้คาดหวัง จากนั้นยืนยันว่าตัวเลือกที่เจรจาครอบคลุมซับเน็ตที่คุณสนใจ หากการตรวจสอบครั้งแรกล้มเหลว ผู้ต้องสงสัยคืออุปกรณ์ NAT หากครั้งที่สองล้มเหลว คือฟิลด์ตัวตน หากครั้งที่สามล้มเหลว ทั้ง NAT และตัวตนไม่เคยเป็นปัญหาเลย