ทำไมเส้นทาง VPN ที่กว้างจึงทำให้เว็บสาธารณะบางแห่งเสีย

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

แก้ไขชื่อที่ล้มเหลว จากนั้นดูตารางเส้นทางแทนเบราว์เซอร์

เปรียบเทียบที่อยู่ ไม่ใช่ชื่อเว็บไซต์

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

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

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

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

บันทึกคำนำหน้า อินเทอร์เฟซ และที่อยู่ที่แก้ไขแล้ว ค่าสามค่านี้คือการวินิจฉัยทั้งหมด

หาว่าใครเป็นผู้ติดตั้งเส้นทาง

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

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

อ่านพฤติกรรมแบบเนทีฟที่อิงคลาสอย่างระมัดระวัง

โปรไฟล์ Windows แบบเนทีฟมีการตั้งค่าที่มีเอกสารกำกับ NativeProfile/DisableClassBasedDefaultRoute ซึ่งควบคุมเส้นทางอัตโนมัติที่อนุมานจากที่อยู่อินเทอร์เฟซ ที่อยู่โปรไฟล์ที่ขึ้นต้นด้วย 45 อาจสร้างรายการ 45.0.0.0/8 ภายใต้พฤติกรรมนั้น และนั่นคือวิธีที่ที่อยู่สาธารณะเดียวจับช่วงคลาส A ทั้งหมด

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

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

แก้ต้นทาง แล้วตรวจทั้งสองเส้นทางอีกครั้ง

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

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

การเพิ่ม MTU หรือล้าง DNS จะไม่แก้ไขคำนำหน้าที่ยังคงนำที่อยู่นั้นเข้าอุโมงค์ ทดสอบการเลือกก่อน แล้วจึงทดสอบเส้นทาง