วิธีการเปลี่ยนพฤติกรรมการออกอากาศทั่วโลก (255.255.255.255) บน Windows?

พฤติกรรมที่ต้องการ

เมื่อแอปพลิเคชันส่งแพ็คเก็ตไปยังที่อยู่ IP การกระจายข้อมูลส่วนกลาง255.255.255.255ฉันต้องการให้ส่งแพ็คเก็ตไปยังที่อยู่ออกอากาศทั่วโลกของ Ethernet ( ff:ff:ff:ff:ff:ff) ในทุกอินเทอร์เฟซ

บน Linux และอาจเป็น OS อื่น ๆ เช่นนี้ดูเหมือนว่าจะทำงาน Windows XP และ Windows 7 มีพฤติกรรมที่แตกต่างกันเกี่ยวกับเรื่องนี้และพฤติกรรมไม่เหมาะสมกับสถานการณ์ของฉัน

พฤติกรรมของ Windows XP

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

ทุกอย่างถูกต้องจนถึงตอนนี้ ปัญหาคือเมื่อส่งไปยังอินเตอร์เฟสอื่นแอดเดรสต้นทางของแพ็กเก็ตบรอดคาสต์คือที่อยู่ IP ของอินเตอร์เฟสแรก ตัวอย่างเช่นลองนึกภาพการกำหนดค่าเครือข่ายนี้ (ลำดับเป็นสิ่งสำคัญ):

อะแดปเตอร์ 1: ที่อยู่ IP 192.168.0.1
อะแดปเตอร์ 2: ที่อยู่ IP 10.0.0.1
อะแดปเตอร์ 3: ที่อยู่ IP 172.17.0.1

ตอนนี้ถ้าฉันส่งแพ็กเก็ตบรอดคาสต์แพ็กเก็ตต่อไปนี้จะถูกส่ง (พร้อมที่อยู่ IP ต้นทางและปลายทาง):

บนอะแด็ปเตอร์ 1: 192.168.0.1=>255.255.255.255
บนอะแด็ปเตอร์ 2: 192.168.0.1=>255.255.255.255
บนอะแด็ปเตอร์ 3: 192.168.0.1=>255.255.255.255

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

พฤติกรรมของ Windows 7

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

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0   10.202.254.254       10.202.1.2    286
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3     10
       10.202.0.0      255.255.0.0         On-link        10.202.1.2    286
       10.202.1.2  255.255.255.255         On-link        10.202.1.2    286
   10.202.255.255  255.255.255.255         On-link        10.202.1.2    286
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0         On-link       192.168.0.3    266
      192.168.0.3  255.255.255.255         On-link       192.168.0.3    266
    192.168.0.255  255.255.255.255         On-link       192.168.0.3    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.0.3    266
        224.0.0.0        240.0.0.0         On-link        10.202.1.2    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.0.3    266
  255.255.255.255  255.255.255.255         On-link        10.202.1.2    286
===========================================================================

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

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

ข้อสรุป

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

เป้าหมาย

ฉันต้องการเปลี่ยนการสนับสนุนการออกอากาศ IP ทั่วโลกใน Windows (โดยเฉพาะ Windows 7) ทุกครั้ง แน่นอนว่าวิธีที่ดีกว่าคือมีการเปลี่ยนแปลงการกำหนดค่าที่รองรับ (การแฮกรีจิสทรีหรือคล้ายกัน) แต่ฉันเปิดรับข้อเสนอแนะทั้งหมด

ความคิดใด ๆ

— Etienne Dechamps
แหล่งที่มา

คุณใช้อะไรในการสร้างการออกอากาศเหล่านี้ ฉันไม่สามารถรับ XP กองซ้อนของฉันที่จะทำอะไรนอกจากการออกอากาศที่กำกับ เช่น 10.202.255.255 ในกรณีของคุณ

— Scott Lundberg

คุณสามารถอ้างอิง RFC หรือเอกสารอื่นที่ระบุพฤติกรรมที่ถูกต้องที่คุณอธิบายได้หรือไม่? ในขณะที่ฉันยอมรับว่ามันเป็นพฤติกรรมที่ต้องการการเรียกมันว่าพฤติกรรมที่ถูกต้องควรอ้างอิงข้อมูลจำเพาะที่กำหนดสิ่งที่ถูกต้อง เป็นไปได้หรือไม่ที่การนำการกำหนดเส้นทางเฉพาะไปใช้กับผู้ให้บริการ (Microsoft ในกรณีนี้)

— เจสันคูมบ์สอาร์

Scott Lundberg: แอปพลิเคชั่นมากมาย (โดยเฉพาะเกม) จะส่งการออกอากาศทั่วโลก คุณสามารถสร้างบางอย่างโดยใช้ netcat: "nc -v -u 255.255.255.255 5000" ตัวอย่างเช่น

— Etienne Dechamps

เจสันอาร์คูมบ์ส: จริง ๆ แล้วบางทีฉันอาจเลือกคำที่ไม่ดี ฉันควรจะใช้ "พฤติกรรมที่พึงประสงค์" ฉันไม่คิดว่าจะมี RFC สำหรับเรื่องนี้ แต่ฉันอาจจะผิด

— Etienne Dechamps

คุณกำลังส่งแพ็คเก็ต TCP หรือ UDP หรือไม่ ตามนี้ที่สำคัญsocial.msdn.microsoft.com/Forums/en/peertopeer/thread/...

— Nissan Fan

คำตอบ:

ไม่ใช่ว่าฉันอยู่ในธุรกิจของการปกป้อง Microsoft แต่หลังจากอ่าน RFC ต่อไปนี้ซึ่งพยายามกำหนดวิธีการออกอากาศฉันไม่คิดว่า Microsoft กำลังละเมิด RFC ใด ๆ IMO ปัญหาควรได้รับการแก้ไขในระดับแอปพลิเคชัน (เช่นการออกอากาศแบบกำกับไม่ใช่ทั่วโลก) ซึ่งจะเข้าสู่เส้นทางที่เหมาะสมในตารางเส้นทางและจะถูกส่งจากอินเทอร์เฟซที่ถูกต้องสำหรับเครือข่าย IP นั้น

พวกเขาทั้งสองระบุว่าไม่มีมาตรฐานที่กำหนดไว้สำหรับการออกอากาศ นอกจากนี้ยังกล่าวถึงใน 919 ว่าควรเลือกอินเทอร์เฟซทางกายภาพเฉพาะสำหรับการออกอากาศ ในกรณีของเครื่อง multi-homed, multi-NIC ที่สร้างการออกอากาศฉันไม่คิดว่าจะระบุอย่างชัดเจนว่าจะเกิดอะไรขึ้น การถ่ายทอดไม่ควรถูกส่งผ่านโดยเราเตอร์จากอินเทอร์เฟซหนึ่งไปยังอีกอินเตอร์เฟสดังนั้นเครื่อง Windows เป็นเราเตอร์หรือไม่ในกรณีนี้
ถ้ามันทำหน้าที่เป็นเราเตอร์โฮสต์ใด ๆ ที่ตอบกลับการออกอากาศด้วยที่อยู่ IP ที่ไม่ถูกต้องสำหรับเครือข่ายนั้น (อะแดปเตอร์ 2 และ 3 ในตัวอย่างของคุณ) ควรส่งแพ็กเก็ตกลับไปยังที่อยู่อีเธอร์เน็ตของ Adapters 2 และ 3 ที่อยู่ IP 1 และโฮสต์ Windows ควรกำหนดเส้นทางไปยังอินเทอร์เฟซที่เหมาะสม
ฟังดูสับสน ... แต่ไม่สามารถนึกถึงวลีที่ดีกว่านี้ได้

และในที่สุด RFC 919 พูดว่าโดยเฉพาะ จาก RFC 919

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

การอ่านที่จะแนะนำว่าที่อยู่ IP ต้นทางนั้นไม่เกี่ยวข้องกับการออกอากาศ

เนื่องจากแต่ละแอปพลิเคชันดูเหมือนจะจัดการการออกอากาศที่แตกต่างกันฉันคิดว่านั่นเป็นความรับผิดชอบ ตัวอย่างเช่น. nbtstatส่งการออกอากาศโดยตรงไปยังเครื่องที่มีหลาย NICed ในขณะที่เกมอาจใช้การออกอากาศทั่วโลก
ในระยะสั้นแอปพลิเคชันควรได้รับการแก้ไขไม่ใช่ระบบปฏิบัติการในกรณีนี้ ...

แก้ไข: นี่คือลิงค์สำหรับสถานการณ์เดียวกัน แต่บน Linux เคอร์เนล linux จัดการโดยส่งเพียงหนึ่งแพ็คเก็ตออกจากอินเตอร์เฟสเริ่มต้น (NIC A ในตัวอย่างนี้) พวกเขาแนะนำให้แอปพลิเคชั่นแจกแจง NICs และส่งการออกอากาศโดยตรงไปยัง NIC แต่ละรายการ ลิงค์

— Scott Lundberg
แหล่งที่มา

ในไม่เข้าใจความสัมพันธ์ระหว่างย่อหน้าที่คุณอ้างจาก RFC 919 และที่อยู่แหล่งที่มา ฉันเห็นได้ชัดว่ามันผิดเสมอที่จะส่งแพ็กเก็ต IP บนอินเทอร์เฟซที่มีแหล่งที่อยู่ของอินเทอร์เฟซอื่นโดยไม่คำนึงถึงลักษณะการออกอากาศ / unicast ของแพ็คเก็ต ฉันหมายความว่าคุณไม่สามารถพูดได้ว่า "ที่อยู่ IP ต้นทางนั้นไม่เกี่ยวข้องกับการออกอากาศ" แน่นอนว่ามันเป็น! แอปพลิเคชันควรรู้ว่าใครเป็นผู้ส่งการออกอากาศ

— Etienne Dechamps

"นอกจากนี้ยังกล่าวถึงใน 919 ว่าควรเลือกอินเทอร์เฟซทางกายภาพสำหรับออกอากาศ" ที่ไหน? "ที่อยู่ 255.255.255.255 หมายถึงการออกอากาศในเครือข่ายฮาร์ดแวร์ท้องถิ่น" (RFC919 7. )? ในกรณีที่ฉันไม่เห็นด้วยอย่างเคารพ เรากำลังพูดถึงสิ่งที่ต้องทำกับการออกอากาศในระดับโฮสต์ไม่ใช่ในระดับเครือข่าย นอกจากนี้ยังมีการกล่าวไว้ด้านล่างว่าโฮสต์อาจ "ออกอากาศไปยังเพื่อนบ้านที่อยู่ใกล้เคียงทั้งหมดโดยใช้ 255.255.255.255" เพื่อนบ้านทั้งหมดทันที ไม่ใช่ "เพื่อนบ้านทั้งหมดในอินเทอร์เฟซเครือข่ายเฉพาะ"

— Etienne Dechamps

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

— Etienne Dechamps

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

— Etienne Dechamps

ไม่แน่ใจว่าคุณหมายถึงอะไรโดยการทำซ้ำ RFCs ห้ามการส่งต่อแพ็กเก็ตออกอากาศเป็นพิเศษ ควรมีเพียงหนึ่งแพ็คเก็ตที่ส่งซึ่งฉันคิดว่าเป็นปมทั้งหมดของการสนทนาของเรา หากระบบปฏิบัติการทำตามที่คุณพูดจริง ๆ แล้วมันจะต้องสร้างแพ็กเก็ตทั้งหมด 9 แพ็กเก็ต (3 สำหรับแต่ละอินเตอร์เฟส) เพราะเลเยอร์ IP จะต้องสร้างแพ็กเก็ตสามชุดที่มี IP ต้นทางแยกต่างหาก (หนึ่งสำหรับแต่ละ NIC ที่ชั้น 3) NIC แต่ละตัวจะต้องส่งสิ่งเหล่านั้นออกบนอีเธอร์เน็ต (เลเยอร์ 2) หากมีเส้นทางระหว่างเครือข่ายคุณจะได้รับการตอบกลับ 3 ครั้ง! อันไหนที่ถูก?

— Scott Lundberg

ในที่สุดฉันก็แก้ไขมันโดยใช้โปรแกรม ฉันเขียนซอฟต์แวร์ขนาดเล็กมากที่เรียกว่าWinIPBroadcastซึ่งดูแลการถ่ายทอดเฟรมออกอากาศไปยังอินเทอร์เฟซทั้งหมด

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

— Etienne Dechamps
แหล่งที่มา

เนื่องจาก windows stack เป็นทางแยกของ stack BSD ฉันอยากรู้ว่า BSD แสดงพฤติกรรมแบบเดียวกันหรือไม่

— x0n

ซอฟต์แวร์ของคุณไม่ทำงาน The program can't start becuase api-ms-win-core-rtlsupport-l1-2-0.dll is missing from your computer.. โชคดีที่พบว่า.dllใน Google

— Alex G

@AlexG: ที่แปลกฉันคิดว่าฉันได้รับการแก้ไขปัญหาที่ผ่านgithub.com/dechamps/WinIPBroadcast/commit/... คุณแน่ใจหรือว่ากำลังใช้งานเวอร์ชันล่าสุด (1.6) โปรดส่งข้อผิดพลาดที่github.com/dechamps/WinIPBroadcast/issuesและฉันจะดู

— Etienne Dechamps