ทำไมการเพิ่มคำนำหน้า Azure VPN จึงตัดการเชื่อมต่อ

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

ออบเจ็กต์สามอย่าง ซึ่งหนึ่งในนั้นถือคำนำหน้า

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

ยังมีเงื่อนไขที่สามที่ควรจำไว้ GatewaySubnet เป็นที่โฮสต์ของอินสแตนซ์เกตเวย์ที่จัดการ ต้องมีชื่อนั้นเป๊ะ และสำหรับ SKU ที่ไม่ใช่ Basic คาดว่าจะมีขนาดอย่างน้อย /27

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

ทำไมจึงลบการเชื่อมต่อ

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

การลบนั้นคือการหยุดชะงัก จึงควรปฏิบัติต่อมันเหมือนการเปลี่ยนแปลงที่วางแผนไว้ซึ่งมีจุดเริ่มต้นและจุดสิ้นสุดที่คาดไว้ ไม่ใช่การแก้ไขเร็ว ใน PowerShell ลำดับนั้นสั้น: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force จากนั้น Set-AzLocalNetworkGateway ด้วย -AddressPrefix อาร์เรย์ใหม่ จากนั้น New-AzVirtualNetworkGatewayConnection ด้วย -SharedKey เดิมและเกตเวย์เดิม การใช้คีย์ซ้ำสำคัญเพราะฝั่งไกลไม่ได้กำหนดค่าใหม่ และคีย์ใหม่หมายถึงการประสานกับผู้ที่เป็นเจ้าของอุปกรณ์ระยะไกล หากทีมอื่นดูแลอุปกรณ์นั้น ให้ตกลงช่วงเวลากับพวกเขาก่อนลบสิ่งใด

เมื่อใดต้องสร้างเกตเวย์เองใหม่

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

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

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

อ่านสถานะ ไม่ใช่ป้ายในพอร์ทัล

อ่านสถานะจากทรัพยากรแทนป้ายในพอร์ทัล Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 คืนค่า ConnectionStatus พร้อมตัวนับไบต์ขาเข้าและขาออก และตัวนับคือสิ่งที่แยกอุโมงค์ที่เชื่อมต่อแต่ไม่บรรทุกอะไรออกจากอุโมงค์ที่ไม่เคยถูกสร้าง

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

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

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

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