General failure เมื่อ ping ไปยังที่อยู่ LAN ขณะเปิดไคลเอนต์ VPN อยู่
Windows บอกว่าเข้าถึงอะแดปเตอร์ใด ๆ ไม่ได้เลย ทั้งที่ตารางเส้นทางดูถูกต้อง ตัดสินว่าการบล็อกมาจากการกำหนดเส้นทาง การกรอง หรือไคลเอนต์
เส้นทางโฮสต์หนึ่งรายการ ที่อยู่หนึ่งรายการ และ ping ล้มเหลวทันทีด้วย General failure แทนที่คำขอจะหมดเวลา ความแตกต่างนี้คือการวินิจฉัยทั้งหมด การหมดเวลาหมายถึงแพ็กเก็ตออกไปแล้วและมีบางอย่างเพิกเฉยต่อมัน General failure หมายถึง Windows ไม่สามารถส่งแพ็กเก็ตให้อินเทอร์เฟซใดเลยได้ตั้งแต่แรก
ดังนั้นเมื่อตารางเส้นทางดูสมบูรณ์แบบแต่ข้อผิดพลาดยังเป็น General failure การบล็อกเกิดขึ้นใต้การตัดสินใจเรื่องเส้นทาง และไคลเอนต์ของผู้ให้บริการคือสิ่งที่ทำงานอยู่ตรงนั้น
อ่านข้อผิดพลาดก่อนดูตารางเส้นทาง
Windows คืนข้อผิดพลาดนั้นเมื่อหาอินเทอร์เฟซสำหรับส่งไม่ได้ และไม่บอกอะไรเกี่ยวกับสิ่งที่ปลายทางจะทำกับแพ็กเก็ต การเข้าถึงได้ ไฟร์วอลล์ที่ปลายอีกด้าน และความพร้อมของบริการล้วนเป็นคำถามปลายน้ำที่คุณยังไปไม่ถึง
การกำหนดค่าดั้งเดิมสำหรับกรณีนี้คือเส้นทางโฮสต์ที่ชี้ที่อยู่ LAN หนึ่งรายการไปยังเกตเวย์ทางกายภาพเพื่อให้ข้ามอุโมงค์ไป route add ยอมรับมัน route print แสดงมัน และ ping ยังคงล้มเหลว เพราะไดรเวอร์ตัวกรองตัดสินใจไปแล้วว่าแพ็กเก็ตไม่ได้รับอนุญาตให้ออก
ก่อนจะยอมรับคำอธิบายนั้น ให้ยืนยันว่าเส้นทางถูกเลือกจริง: ตรวจสอบดัชนีอินเทอร์เฟซและเมตริก และตรวจสอบว่ารายการไม่ล้าสมัยหลังเชื่อมต่อใหม่ เส้นทางที่ชี้ไปยังอินเทอร์เฟซที่ไม่มีอยู่แล้วให้ข้อผิดพลาดคล้ายกันด้วยสาเหตุที่น่าสนใจน้อยกว่ามาก
สามชั้น สามเจ้าของที่ต่างกัน
ชั้นที่ชนะคือชั้นที่ทำงานสุดท้าย และทั้งสามไม่ได้อยู่ในลำดับที่คนส่วนใหญ่คิด
| Layer | What it decides |
|---|---|
| Routing table | Which interface and next hop should carry the packet |
| Client filter driver | Whether this packet is permitted to leave outside the tunnel at all |
| Client feature | Whether a named feature, such as LAN blocking, is active right now |
ชั้นกลางคือเหตุผลที่เส้นทางหนึ่งสามารถถูกต้องและไร้ประโยชน์ในเวลาเดียวกัน ไคลเอนต์ของผู้ให้บริการติดตั้งตัวกรองและกฎไฟร์วอลล์เพื่อให้ทราฟฟิกนอกอุโมงค์ถูกทิ้ง ซึ่งเป็นกลไกเดียวกับที่ใช้ทำ kill switch ของพวกเขา ไม่มีอะไรในตารางเส้นทางมีส่วนร่วมในการตัดสินใจนั้น
ชั้นที่สามอธิบายรายงานแปลก ๆ ที่มาอย่างสม่ำเสมอ: ซับเน็ตภายในเครื่องเข้าถึงไม่ได้แม้หลังตัดการเชื่อมต่อไคลเอนต์แล้ว บริการยังทำงานอยู่และตัวกรองยังติดตั้งอยู่ ดังนั้นการไม่เชื่อมต่อไม่เหมือนกับการไม่กรอง ออกจากไคลเอนต์แทนที่จะเพียงตัดการเชื่อมต่อก่อนสรุปสิ่งใด
สิ่งที่ควรลองตามลำดับ
เริ่มจากการปิดฟีเจอร์ที่ปิดได้ถูกและเปิดคืนได้ง่าย การค้นหา LAN ซึ่งบางครั้งเรียกว่าการมองไม่เห็นบน LAN บล็อกทราฟฟิกไปยังช่วงที่อยู่ส่วนตัวเพื่อให้เครื่องซ่อนจากเพื่อนบ้าน เครื่องพิมพ์ เซิร์ฟเวอร์ไฟล์ภายใน และเราเตอร์เองก็หายไปหลังสวิตช์นั้น ฟีเจอร์ป้องกันภัยคุกคามที่กรอง DNS จะติดตั้งฮุกของตัวเองและมีรายงานว่าทำลายการเข้าถึงภายในในลักษณะเดียวกัน
ปิดทั้งสองอย่าง ออกจากไคลเอนต์ให้หมด แล้วทดสอบที่อยู่ ลำดับนั้นแยกฟีเจอร์ที่บล็อกทราฟฟิกออกจากอุโมงค์ที่กำหนดเส้นทางผิด และใช้เวลาสองนาทีแทนที่จะเสียบ่ายทั้งบ่ายกับเส้นทางแบบคงที่
ping 192.168.1.50
tracert -d 192.168.1.50
route print -4หากที่อยู่ตอบกลับเมื่อปิดฟีเจอร์แล้ว คุณมีเรื่องการตัดสินใจเชิงนโยบายไม่ใช่ข้อบกพร่อง: เลือกระหว่างปล่อยฟีเจอร์ปิดไว้ เพิ่มข้อยกเว้น หรือยอมรับว่าเครื่องจะยังมองไม่เห็นบนเครือข่ายภายใน
ใช้เส้นทางข้อยกเว้นของไคลเอนต์อย่างแคบ
เมื่อฟีเจอร์ต้องเปิดอยู่ การแยกอุโมงค์ของไคลเอนต์เองคือทางออกที่รองรับ ทำให้ข้อยกเว้นเล็กที่สุดเท่าที่ข้อกำหนดอนุญาต ซึ่งปกติหมายถึงที่อยู่โฮสต์หนึ่งรายการสำหรับเซิร์ฟเวอร์หนึ่งเครื่อง หรือพรีฟิกซ์หนึ่งรายการสำหรับเซกเมนต์เดียว กฎที่ครอบคลุมช่วงส่วนตัวทั้งหมดคือรูถาวรที่ไม่มีใครจำได้ว่าเพิ่มเข้าไปและไม่มีใครกล้าลบออก
จากนั้นตรวจสอบด้วยที่อยู่ก่อนและด้วยชื่อทีหลัง หากที่อยู่ตอบกลับด้วยฮ็อปแรกบนเกตเวย์ทางกายภาพ ข้อยกเว้นนั้นได้ผล หากชื่อยังล้มเหลว แสดงว่าคุณย้ายไปที่ DNS เพราะตัวแปลงชื่อของอุโมงค์ไม่รู้จักโซนภายในและไม่มีการเปลี่ยนแปลงเส้นทางใดจะสอนมันได้
เก็บเส้นทางหรือข้อยกเว้นไว้ อย่างใดอย่างหนึ่ง ไม่ใช่ทั้งสอง พร้อมบันทึกว่าอันไหนทำงาน สองกลไกที่ซ้อนทับกันจะซ่อนกันเอง และคนต่อไปที่แก้ปัญหาเครื่องนี้จะลบหนึ่งในนั้นแล้วไม่เห็นการเปลี่ยนแปลงใด ๆ
เมื่อไคลเอนต์เองเป็นอุปสรรค
บางบิลด์กรองทราฟฟิกในแบบที่ทั้งเส้นทางแบบคงที่และข้อยกเว้นของไคลเอนต์เอาชนะไม่ได้ เมื่อเป็นเช่นนั้น ทางเลือกที่ซื่อตรงคือรอฟีเจอร์ข้ามหรือเชื่อมต่อด้วยไคลเอนต์ OpenVPN ธรรมดาโดยใช้โปรไฟล์ของผู้ให้บริการเอง ซึ่งเป็นสิ่งที่คำตอบฝ่ายสนับสนุนของผู้ขายแนะนำในรายงานต้นฉบับ
เข้าใจการแลกเปลี่ยนก่อนทำการแทนที่นั้น โปรไฟล์ธรรมดาทำงานเหมือนอุโมงค์ทั่วไป: ติดตั้งเส้นทางของตัวเองและไม่ปรับโครงสร้างส่วนที่เหลือของสแตก ดังนั้นเส้นทางโฮสต์แบบแคบยังทำงานตามที่คุณคาดหวัง สิ่งที่คุณเสียไปคือทุกอย่างที่ไคลเอนต์แบรนด์เนมทำไว้รอบอุโมงค์ รวมถึง kill switch และการกรอง DNS และสิ่งเหล่านั้นต้องสร้างขึ้นใหม่โดยเจตนาหรือยอมรับว่าไม่มี
ไม่ว่าคุณจะเลือกอะไร บันทึกว่าชั้นใดเป็นเจ้าของการบล็อก แพ็กเก็ตที่ไม่เคยออกจากเครื่องคือผลลัพธ์ของตัวกรอง และไม่มีการเปลี่ยนแปลงเส้นทางใดซ่อมแซมตัวกรองได้