Windows 10 ไม่สนใจตารางเส้นทาง

ฉันมีพีซี Windows 10 ที่มี 2 อินเทอร์เฟซเครือข่าย หนึ่งในอินเทอร์เฟซเหล่านั้นเข้าสู่ LAN หลักซึ่งเป็นที่ตั้งของเซิร์ฟเวอร์ไฟล์ DNS และเราเตอร์สำหรับอินเทอร์เน็ต อินเทอร์เฟซที่สองคือ LAN ขนาดเล็กซึ่งมี PLC และ HMI ทั้งคู่อยู่ใน LAN เดียวกันแต่อยู่บนเครือข่ายย่อยที่แตกต่างกัน (ขออภัย ไม่สามารถเปลี่ยนแปลงได้ อยู่นอกเหนือการควบคุมของฉัน)

ดังนั้นฉันจึงมีอินเทอร์เฟซทางกายภาพสองอินเทอร์เฟซและอินเทอร์เฟซแบบลอจิคัลหนึ่งรายการ: eth0: DHCP, 172.16.x.y, MASK 255.255.255.0, เริ่มต้น gw 172.16.x.z eth1: คงที่ 192.168.1.158, หน้ากาก 255.255.255.0 คงที่ 192.168.19.158, หน้ากาก 255.255.255.0

HMI สามารถเข้าถึงได้ภายใต้ 192.168.19.135

ตอนนี้เมื่อฉันรีบูต HMI ฉันเริ่ม ping เพื่อดูว่าสามารถเข้าถึงได้อีกครั้งเมื่อใด สิ่งนี้ควรเกิดขึ้นหลังจากประมาณ 30 วินาทีแต่ฉันได้รับการตอบกลับ ping ในเชิงบวกหลังจาก 80-90s เท่านั้น

ปิง wird ausgeführt für 192.168.19.135 mit 32 Bytes Daten:
Antwort จาก 192.168.19.158: Zielhost nicht erreichbar.
Zeitüberschreitung der Anforderung
Zeitüberschreitung der Anforderung
Zeitüberschreitung der Anforderung

(ขออภัยสำหรับข้อความภาษาเยอรมัน แต่ฉันคิดว่ายังคงชัดเจนในสิ่งที่เราเห็นที่นี่) ฉันได้รับการตอบกลับอีกครั้งสำหรับ ping แรกมากกว่าอันที่สอง

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

ฉันพบ "วิธีแก้ปัญหา" บางอย่างที่ไม่ใช่วิธีแก้ปัญหาที่แท้จริงสำหรับฉัน (เพิ่มเติมด้านล่าง)

1. ดังนั้น ping จึงมีพารามิเตอร์ "-S" ที่ดีเพื่อกำหนดที่อยู่ต้นทาง และใช่สิ่งนี้ "แก้ปัญหา" ฉันได้รับการตอบกลับทันทีหาก ​​HMI หมด แต่ฉันใช้คำสั่งนั้นใน powershell-script และ source-parameter เพื่อ "test-connection" มีความหมายที่แตกต่างไปจากเดิมอย่างสิ้นเชิง และเนื่องจากฉันใช้สิ่งนี้ในสคริปต์ สิ่งนี้จึงล้มเหลวทันทีที่ IP ในเครื่องเปลี่ยนไป
2. ฉันกำหนดค่า eth0 แบบคงที่แทนโดย DHCP และไม่ได้กำหนดเส้นทางเริ่มต้น สิ่งนี้ "แก้ไข" ปัญหาด้วย (ฉันคิดว่าคุณสามารถจินตนาการได้ว่าทำไมนี่ไม่ใช่วิธีแก้ปัญหาจริงๆ)
3. ฉันได้สำรวจสิ่งนี้ในทางทฤษฎีเท่านั้น แต่ฉันสามารถติดตั้งเราเตอร์ที่ใช้ linux ที่มี 3 อินเทอร์เฟซระหว่างพีซี, LAN และ LAN แบบแยกด้วย PLC และ HMI และปล่อยให้มันทำการกำหนดเส้นทางทั้งหมด (สิ่งนี้จะช่วยแก้ปัญหาได้อย่างแน่นอน! แต่พูดตามตรง ฉันต้องการคอมพิวเตอร์เพิ่มเติมเพื่อแก้ไขการกำหนดเส้นทาง Windows ที่เสียหายหรือไม่)
4. ´arp -d *´ ดูเหมือนจะช่วยได้เช่นกัน แต่ต้องการสิทธิ์ขั้นสูง

ฉันได้ลองเพิ่มเส้นทางคงที่ด้วยพารามิเตอร์และเมตริกต่างๆ ไม่มีการเปลี่ยนแปลง! การเพิ่ม MAC ของ HMI แบบคงที่ไม่ได้ช่วยอะไรเนื่องจาก MAC นี้สามารถเปลี่ยนแปลงได้

ดังนั้นคำถามของฉันคือ:

1. มีเอกสารใด ๆ เกี่ยวกับการเปลี่ยนแปลงพฤติกรรมใน windows หรือไม่
2. มีวิธีบังคับให้ windows ใช้อินเทอร์เฟซที่กำหนดไว้หรือไม่

ดังนั้น หลังจากไม่พบวิธีแก้ปัญหาง่ายๆ ฉันจึงตัดสินใจเขียนโปรแกรมเพื่อแก้ไขปัญหาที่ Microsoft สร้างขึ้นโดยทำให้การกำหนดเส้นทางบน Windows ยุ่งเหยิง

ฉันไม่ต้องการใช้ ping แบบคลาสสิกกับพารามิเตอร์ -S แทน cmdlet test-connection ใน powershell

ตอนนี้ส่วน ping ของรหัสของฉันมีลักษณะดังนี้:

$localIPs = (รับ NetIPConfiguration -InterfaceAlias ​​"PLC").IPv4Address.IPAddress

# เนื่องจากคำสั่งนี้ส่งคืนสตริง เมื่ออินเทอร์เฟซมีที่อยู่ IP เดียว แต่มีอาร์เรย์ของสตริง หากอินเทอร์เฟซมีมากกว่าหนึ่งที่อยู่ เราจำเป็นต้องตรวจสอบสิ่งนี้
if ($localIPs.GetType().Name -eq "string") { # เพียง IP เดียวเท่านั้น
  $localIP = $localIPs
}
อื่น { # มากกว่าหนึ่ง IP
  $localIP = $localIPs[0] # เนื่องจากดูเหมือนว่า windows ใช้ที่อยู่ ip เป็นคำพ้องความหมายสำหรับอินเทอร์เฟซ จึงไม่สำคัญว่าจะใช้ที่อยู่ใดของอินเทอร์เฟซนั้น เราก็เลยเลือกอันแรก
}

$pingcount = 180

ทำ {
  ping $HMI4IP -n 1 -w 1,000 -S $localIP | Out-Null # เปลี่ยนเส้นทางเอาต์พุตของ ping ไปที่ /dev/null
  $pingreply = $?
  $pingcount = $pingcount - 1
}
จนกระทั่ง ($pingcount -eq '0' -หรือ $pingreply)
ถ้า ($pingreply) {
  #โค้ดที่นี่
}
อื่น {
  ออก 1337 # กลับมาพร้อมกับรหัสข้อผิดพลาด เรายังไม่ถึงเป้าหมายของเรา
}

สำหรับสิ่งนี้ ฉันต้องแน่ใจว่าอินเทอร์เฟซที่เชื่อมต่อ PLC และ HMI นั้นมีชื่อว่า "PLC" กว่าที่ฉันจะได้รับที่อยู่เป็นสตริงหรืออาร์เรย์ของที่อยู่ (ขึ้นอยู่กับว่าอินเทอร์เฟซมีที่อยู่ตั้งแต่หนึ่งแห่งขึ้นไป) ซึ่งฉันต้องจัดการ (ยินดีต้อนรับสู่การพิมพ์แบบไดนามิก...) ง่ายกว่าการป้อนข้อมูลนี้เพื่อ ping (เนื่องจากการทดสอบการเชื่อมต่อพยายามที่จะฉลาดเกินไปสำหรับข้อดีของมันเอง) ใน $? ฉันได้รับจริงจากคำสั่งสุดท้ายที่ส่งคืนความสำเร็จและเป็นเท็จหากล้มเหลว ดังนั้นมันจึงง่ายต่อการจัดการต่อจากนี้ไป

เท่าที่ฉันเห็นไม่มีเอกสารจาก Microsoft เกี่ยวกับพฤติกรรมนี้และวิธีจัดการกับมัน ซึ่งฉันคิดว่าค่อนข้างน่าเศร้า