ทำไมตารางเส้นทาง VPN ของ Windows จึงแสดง 0.0.0.0/1 และ 128.0.0.0/1

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

ตัวเลือกเกตเวย์เริ่มต้นติดตั้งอะไร

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

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

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

การรื้อถอนถูกกว่าการเก็บเกตเวย์ไว้

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

ไคลเอนต์อื่นมาถึงการออกแบบเดียวกัน โปรไฟล์ OpenVPN ที่มี redirect-gateway def1 จะติดตั้งคำนำหน้าสองรายการนั้นแทนการลบเส้นทางเริ่มต้น และไคลเอนต์ Windows ก็ทำตามรูปแบบเดียวกันด้วยเหตุผลด้านเส้นทางเดียวกัน

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

คำนำหน้าที่ยาวที่สุดชนะก่อนเมตริกใด ๆ

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

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

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

เลือกเจ้าของเดียวสำหรับคำนำหน้าสำนักงาน

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

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

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

ความเป็นเจ้าของคือคำถามที่ส่วนนี้ตอบ ไม่ใช่ไวยากรณ์ เจ้าของสองรายสำหรับคำนำหน้าเดียวคือโหมดล้มเหลวที่ควรหลีกเลี่ยง.

ตรวจสอบด้วยปลายทาง ไม่ใช่เว็บไซต์

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

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

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

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