ยกเว้นโฮสต์หนึ่งเครื่องจากเส้นทางเริ่มต้นของ VPN บน Windows

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

อุโมงค์เข้ายึดรายการใด

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

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

route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.30

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

เส้นทางโฮสต์ชนะด้วยความเฉพาะเจาะจง

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

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

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

ทำให้เส้นทางอยู่รอดการเชื่อมต่อครั้งถัดไป

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

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

route -p add 198.51.100.30 mask 255.255.255.255 10.0.0.1 metric 1 if 7

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

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

rasdial Office
route add 198.51.100.30 mask 255.255.255.255 10.0.0.1 metric 1 if 7

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

การกำหนดเส้นทางเลือกโปรเซสไม่ได้

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

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

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

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

ยืนยันว่าข้อยกเว้นอยู่รอดการเชื่อมต่อใหม่

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

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