เราเตอร์ในโหมดไคลเอนต์ VPN: ทำไมอุปกรณ์ LAN ถึงหายไป
อุปกรณ์ LAN หายไปหลังเราเตอร์เข้าสู่โหมดไคลเอนต์ VPN: ทดสอบฟีเจอร์ตรวจสอบในเส้นทางส่งต่อก่อน จากนั้นจึงตรวจสอบช่วง LAN ที่เฟิร์มแวร์เปลี่ยนไป
ความเชื่อว่าโหมดไคลเอนต์เองทำให้การเข้าถึง LAN ตายนั้นพาคนไปยังเมนูตั้งค่าที่ผิด และสาเหตุจริงมักมีสองอย่าง อุโมงค์ไม่ได้ลบสะพาน LAN และไม่ได้ขัดขวางไคลเอนต์แบบมีสายและไร้สายไม่ให้เข้าถึงกัน สิ่งที่ทำให้การเข้าถึงในเครื่องเสียคือฟีเจอร์ตรวจสอบในเส้นทางส่งต่อของเราเตอร์ หรือช่วงที่อยู่ LAN ที่เลื่อนไปเมื่อเฟิร์มแวร์เปลี่ยน ทั้งสองอย่างทำให้เกิดคำร้องเรียนเดียวกัน และไม่มีอย่างไหนแก้ได้ด้วยการติดตั้งโปรไฟล์ VPN ใหม่
ความเชื่อผิด ๆ และสิ่งที่โหมดไคลเอนต์เปลี่ยนจริง ๆ
โหมดไคลเอนต์เพิ่มอินเทอร์เฟซอุโมงค์และเส้นทางเริ่มต้นที่ผ่านมัน แล้ว ส่งต่อทราฟฟิก LAN เข้าไปในอุโมงค์นั้น สะพานระหว่างพอร์ตมีสายกับวิทยุไร้สายยังคงอยู่ เช่นเดียวกับการสลับในเครื่อง สิ่งที่เปลี่ยนคือ นโยบาย: ทราฟฟิกใดถูกส่งต่อ แปลงที่ไหน และไคลเอนต์ได้รับตัวแก้ชื่อใด
ความแตกต่างนี้สำคัญเพราะ LAN ที่เสียมักหมายถึงหนึ่งในสามนโยบายนั้นเปลี่ยน ไม่ใช่เราเตอร์เลิกเป็นสวิตช์ เราเตอร์ที่ยังตอบหน้าจัดการของตัวเองได้คือหลักฐานว่าอินเทอร์เฟซ LAN ยังมีชีวิต เราเตอร์ที่ไม่ตอบอะไรเลยมีปัญหาอื่น เช่น ที่อยู่ LAN เปลี่ยนหรือไคลเอนต์อยู่ในซับเน็ตผิด
ดังนั้นก้าวแรกที่มีประโยชน์คือหาว่าชั้นไหนเสีย ไม่ใช่เปลี่ยนชั้นที่คุณสงสัย
ทดสอบสามเป้าหมายก่อนแตะการตั้งค่า
จากไคลเอนต์มีสาย ทดสอบสามเป้าหมายแยกกันและจดผลแต่ละอย่าง: ที่อยู่ LAN ของเราเตอร์เอง อุปกรณ์อื่นบนสวิตช์เดียวกันตาม IP และสิ่งที่เข้าถึงได้ทางอุโมงค์เท่านั้น ทำตามลำดับนั้น เพราะแต่ละผลตัดชั้นที่ต่างกันออกไป ใช้ที่อยู่แทนชื่อในรอบแรก เพราะความล้มเหลวของชื่อทำให้ DNS ปนเข้าไปในคำถามเรื่องการเชื่อมต่อ
รูปแบบของคำตอบคือการวินิจฉัย เราเตอร์ที่ตอบในขณะที่อุปกรณ์ในเครื่องไม่ตอบชี้ไปที่การสลับในเครื่องหรือฟีเจอร์กรอง ไม่ใช่การกำหนดเส้นทาง อุปกรณ์ในเครื่องที่ตอบในขณะที่ฝั่งอุโมงค์ไม่ตอบชี้ไปที่เส้นทางอุโมงค์หรือไฟร์วอลล์ระยะไกล หากทุกอย่างตอบตามที่อยู่แต่ชื่อล้มเหลว นั่นคือคำถามของตัวแก้ชื่อ และการแก้เส้นทางไม่ช่วย
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
เก็บตารางไว้ข้างผลการทดสอบ มันเปลี่ยนคำร้องเรียนที่คลุมเครือเป็นหนึ่งบรรทัดที่ลงมือได้
ชั้นความปลอดภัยภายในเส้นทางส่งต่อ
เราเตอร์สำหรับผู้บริโภคมาพร้อมฟีเจอร์ตรวจสอบที่เฝ้าดูทราฟฟิกที่ส่งต่อมากขึ้น และมันทำงานในเส้นทางเดียวกับที่บรรทุกแพ็กเก็ตจาก LAN ไปอุโมงค์ เมื่อการตรวจสอบนั้นจำแนกทราฟฟิกอุโมงค์ไม่ได้ การส่งต่ออาจหยุดชะงักในขณะที่อุโมงค์ยังทำงานและเราเตอร์รายงานการเชื่อมต่อที่ดี ไม่มีอะไรในบันทึก VPN แสดงสิ่งนี้ เพราะ VPN เชื่อมต่อจริง
การวินิจฉัยคือการทดลองแบบควบคุม ไม่ใช่การเปลี่ยนแปลงถาวร จดการตั้งค่าปัจจุบัน ปิดฟีเจอร์ระหว่างการทดสอบหนึ่งครั้ง เปิดอุโมงค์ใหม่ และทดสอบโฮสต์ในเครื่องหนึ่งเครื่องตามที่อยู่ สิ่งที่ส่งต่อกลับมาคือหลักฐานที่คุณต้องการ และการแลกเปลี่ยนกลายเป็นการตัดสินใจแทนการเดา หากไม่มีอะไรเปลี่ยน ให้เปิดกลับทันทีและไปที่สาเหตุด้านที่อยู่
การปล่อยฟีเจอร์ความปลอดภัยแบบเสียเงินไว้ปิดเพื่อให้อุโมงค์ทำงานต่อคือการแลกเปลี่ยนที่ต้องทำอย่างตั้งใจและจดไว้ ควรถามด้วยว่าอุโมงค์ควรอยู่บนอุปกรณ์อื่นหรือไม่ เพราะเราเตอร์ที่ต้องตรวจทุกอย่างกับเราเตอร์ที่ต้องส่งต่อทุกอย่างเป็นงานสองอย่างที่ต่างกัน
สาเหตุที่สอง: ช่วง LAN เลื่อนไป
การอัปเดตเฟิร์มแวร์มักรีเซ็ตที่อยู่ LAN กลับเป็นค่าเริ่มต้นของผู้ผลิต และเราเตอร์บางรุ่นมีสวิตช์โหมดชัดเจนที่ตัดสินว่าช่วง LAN จะคงช่วงส่วนตัวหรือรับช่วงจากอุปกรณ์ด้านบน 192.168.8.x ที่ไคลเอนต์คาดหวังอาจกลายเป็น 10.64.0.x และเซสชัน SSH ไปยังโฮสต์หมดอายุทั้งที่อุโมงค์สมบูรณ์
ipconfig /all
ip addr show
ip route get 192.168.8.20อ่านคำนำหน้าและเกตเวย์จากการเช่าก่อนเปิดหน้าเราเตอร์ สองคำสั่งแรกแสดงสิ่งที่ไคลเอนต์ได้รับจริง และคำสั่งที่สามแสดงว่าอินเทอร์เฟซใดที่ไคลเอนต์จะใช้สำหรับที่อยู่ในเครื่อง และนั่นคือวิธีที่เส้นทางที่เหลือหรือซับเน็ตเก่าเผยตัว จากนั้นเปรียบเทียบกับหน้า LAN และโหมดที่เราเตอร์อยู่
หากช่วงกลับไปไม่ได้ ให้อัปเดตทุกออบเจกต์ที่อ้างถึง: การจอง DHCP เส้นทางคงที่ใด ๆ ไปยังซับเน็ตเก่า และกฎไฟร์วอลล์ทุกข้อที่มีคำนำหน้าเดิม ช่วงที่ชนกับซับเน็ตระยะไกลของอุโมงค์เป็นรูปแบบที่แย่กว่า เพราะอุปกรณ์ในเครื่องยังเข้าถึงได้ในขณะที่ปลายทางระยะไกลถูกกำหนดเส้นทางผิดเข้า LAN อย่างเงียบ ๆ
เชื่อมต่อใหม่และทดสอบซ้ำตามลำดับแพ็กเก็ต
หลังการเปลี่ยนแปลงใด ๆ ให้เชื่อมต่ออุโมงค์ใหม่และทำการทดสอบซ้ำตามลำดับแพ็กเก็ต: เราเตอร์ โฮสต์ในเครื่อง โฮสต์ระยะไกล จากนั้นชื่อ จากนั้นแอปพลิเคชัน การทดสอบแอปพลิเคชันก่อนจะซ่อนว่าชั้นไหนยังเสีย และการลองใหม่ของเบราว์เซอร์กับชื่อที่แคชไว้อาจดูเหมือนความล้มเหลวในการกำหนดเส้นทาง
จดเวอร์ชันเฟิร์มแวร์ คำนำหน้า LAN และสถานะของฟีเจอร์ตรวจสอบไว้ข้างโปรไฟล์ VPN ทั้งสามอย่างเป็นการกำหนดค่าที่การอัปเดตครั้งถัดไปอาจเขียนทับ และบันทึกสองบรรทัดช่วยประหยัดชั่วโมงที่เพิ่งใช้ไป