ค่ารีจิสทรี NAT-T ของ Windows: ตรวจสอบโครงสร้างเครือข่ายก่อน

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

ค่าที่เลือกจริงคืออะไร

AssumeUDPEncapsulationContextOnSendRule กำหนดว่าการใช้งาน IPsec ของ Windows จะพยายามสร้างความสัมพันธ์กับคู่ปลายทางที่อยู่หลังอุปกรณ์ NAT หรือไม่ ค่าเริ่มต้นที่เอกสารระบุคือ 0 ไม่อนุญาตกรณีนั้น 1 อนุญาตเมื่อเซิร์ฟเวอร์เป็นฝั่งที่อยู่หลัง NAT และ 2 ครอบคลุมการแปลทั้งสองปลาย นี่คือข้อความเกี่ยวกับโครงสร้างเครือข่ายว่าใครอยู่ที่ไหน

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

จับคู่โครงสร้างเครือข่ายก่อนตัวเลข

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

ข้ออ้างที่ว่า Windows Server รุ่นปัจจุบันมาพร้อม NAT traversal ที่ปิดอยู่นั้นกว้างเกินกว่าจะลงมือทำ สิ่งที่สำคัญคือ นโยบายบนระบบของคุณ โครงสร้างเครือข่ายที่อยู่ข้างหน้า และการแลกเปลี่ยนที่ล้มเหลว ตามลำดับนั้น หากทั้งสองปลายมีที่อยู่สาธารณะ การตั้งค่านี้ไม่ใช่ปัญหาของคุณ ให้ดูข้อเสนอ ใบรับรอง หรือบัญชีแทน และปล่อยรีจิสทรีไว้

ตรวจสอบขั้นตอนที่ล้มเหลวก่อน

L2TP/IPsec ก่อให้เกิดความล้มเหลวอย่างน้อยสามแบบที่แตกต่างกัน: เข้าถึงคู่ปลายไม่ได้ ป้องกัน IPsec ไม่ได้ และ การรับรองผู้ใช้ PPP ถูกปฏิเสธหลังจากอุโมงค์มีอยู่บัญชีที่ถูกปฏิเสธไม่สามารถซ่อมได้ด้วยการเปลี่ยนนโยบาย NAT และความไม่ตรงกันของข้อเสนอไม่สามารถซ่อมได้ด้วยการรีบูต

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

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

SSTP บน HTTPS และ IKEv2 แบบดั้งเดิมมีบันทึกและมาตรการควบคุมของตัวเอง ไม่มีสิ่งใดกลายเป็นกรณี NAT-traversal เพียงเพราะทำงานบน Windows ด้วย

ทำการเปลี่ยนแปลงโดยมีทางกลับ

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

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