VPN จากไซต์ถึงไซต์ของ Azure กับเพียร์ที่อยู่หลัง NAT: รายการตรวจสอบ

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

ขั้นตอนที่ 1: ยืนยันว่าเพียร์อยู่หลัง NAT จริงหรือไม่

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

หากสองที่อยู่ตรงกัน ให้หยุดตรงนี้: NAT ไม่ใช่ปัญหาของคุณและส่วนที่เหลือของรายการนี้จะไม่ช่วย

บันทึกที่อยู่ทั้งสองและรุ่นของตัวแปลลงในตั๋ว บรรทัดเดียวนั้นป้องกันการถามตอบรอบถัดไปว่าทำไมเพียร์ที่กำหนดค่าไว้ไม่ตอบสนอง

ขั้นตอนที่ 2: ตกลงกันว่าใครจะเป็นฝ่ายเริ่ม

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

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

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

ขั้นตอนที่ 3: ตั้งที่อยู่เพียร์ให้ถูกต้อง

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

หากที่อยู่สาธารณะเปลี่ยน ออบเจกต์นั้นก็ต้องเปลี่ยนตามไปด้วย ชื่อที่แปลงไปยังที่อยู่เก่าแย่กว่าที่อยู่คงที่ที่คุณต้องอัปเดตด้วยมือ

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

ขั้นตอนที่ 4: เปิดเฉพาะพอร์ตที่ NAT-T ต้องการ

NAT-T บรรจุ ESP ไว้ใน UDP และ RFC 3948 อธิบายการห่อหุ้มนั้นโดยใช้พอร์ต 4500 หลังการเจรจาเริ่มต้นที่พอร์ต 500 ทั้งไฟร์วอลล์ของคุณและตัวแปลต้องอนุญาตการแลกเปลี่ยนและทราฟฟิกตอบกลับ การอนุญาตพอร์ต TCP ที่ไม่เกี่ยวข้องไม่ได้พิสูจน์อะไรเกี่ยวกับเส้นทางนี้ และกฎที่อนุญาตขาออกแต่ไม่อนุญาตคำตอบก็ยังล้มเหลว

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

ดักจับครั้งเดียวทั้งสองฝั่งของตัวแปล ความแตกต่างของการห่อหุ้มจะเห็นได้ทันที

ขั้นตอนที่ 5: แยกการขนส่งภายนอกออกจากการกำหนดเส้นทางภายใน

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

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

จัดประเภทความล้มเหลวตามขั้นตอนก่อนที่คุณจะเปลี่ยนอะไร และเก็บการจัดประเภทนั้นไว้ในตั๋วเพื่อให้คนถัดไปเริ่มจากจุดที่คุณหยุด