Windows에서 글로벌 브로드 캐스트 주소 (255.255.255.255) 동작을 변경하는 방법은 무엇입니까?

원하는 행동

응용 프로그램이 글로벌 브로드 캐스트 IP 주소로 패킷을 보낼 때 모든 인터페이스 255.255.255.255에서 패킷을 이더넷 글로벌 브로드 캐스트 주소 ( 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 이외의 다른 인터페이스에서는 작동하지 않습니다. 제 생각에 이것은 Windows XP의 TCP / IP 스택에서 명백한 버그입니다.

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)에서 한 번에 변경하고 싶습니다. 물론 더 좋은 방법은 일종의 지원되는 구성 변경 (레지스트리 해킹 또는 이와 유사한 것)을 갖는 것이지만 모든 제안에 개방적입니다.

어떤 아이디어?

— 에티엔 느 챔프
소스

이 방송을 생성하기 위해 무엇을 사용하고 있습니까? XP 스택이 직접 방송 이외의 작업을 수행하도록 할 수 없습니다. 즉 귀하의 경우 10.202.255.255입니다.

— Scott Lundberg

설명하는 올바른 행동을 나타내는 RFC 또는 기타 문서를 참조 할 수 있습니까? 나는 그것이 바람직한 행동이라고 동의하지만, 그것을 올바른 행동이라고 부르려면 무엇이 올바른지를 정의하는 사양을 참조해야합니다. 특정 라우팅 구현이 공급자 (이 경우 Microsoft)에게 맡겨 질 수 있습니까?

— Jason R. Coombs

Scott Lundberg : 많은 응용 프로그램 (특히 게임)이 글로벌 브로드 캐스트를 보냅니다. netcat을 사용하여 일부를 생성 할 수 있습니다 (예 : "nc -v -u 255.255.255.255 5000").

— Etienne Dechamps

Jason R. Coombs : 사실, 어쩌면 나는 단어를 잘못 선택했을 것입니다. 나는 "원하는 행동"을 사용해야했다. RFC가 있다고 생각하지 않지만 잘못되었을 수 있습니다.

— Etienne Dechamps

TCP 또는 UDP 패킷을 보내십니까? 이것에 따르면 social.msdn.microsoft.com/Forums/en/peertopeer/thread/… 가 중요 합니다 .

— Nissan Fan

답변:

내가 Microsoft를 방어하는 사업은 아니지만 브로드 캐스트 작동 방식을 정의하려는 다음 RFC를 읽은 후에 Microsoft가 RFC를 반드시 위반하고 있다고 생각하지 않습니다. IMO 문제는 응용 프로그램 수준 (즉, 전역이 아닌 직접 방송)에서 수정되어야합니다.이 경로는 라우팅 테이블의 해당 경로에 도달하고 해당 IP 네트워크의 올바른 인터페이스에서만 전송됩니다.

둘 다 방송에 대해 정의 된 표준이 없다고 말합니다. 또한, 919 년에 방송을 위해 특정 물리적 인터페이스가 선택되어야한다고 언급하고있다. 브로드 캐스트를 생성하는 멀티 홈, 멀티 NIC 시스템의 경우 어떤 일이 발생해야하는지 명확하게 밝히지 않았다고 생각합니다. 브로드 캐스트는 한 인터페이스에서 다른 인터페이스로 라우터에 의해 전달되지 않아야하므로 Windows 시스템이 라우터입니까? 라우터 역할 을하는
경우 해당 네트워크에 대해 잘못된 IP 주소 (예 : 어댑터 2 및 3)로 브로드 캐스트에 응답하는 모든 호스트는 어댑터에 대한 응답으로 어댑터 2 및 3의 이더넷 주소로 패킷을 다시 보내야합니다. 1의 IP 주소와 Windows 호스트는 적절한 인터페이스로 라우팅해야합니다.
혼란스러워 보이지만 이것을 표현하는 더 좋은 방법은 생각할 수 없습니다.

마지막으로 RFC 919는 RFC 919에서 구체적으로 말합니다 .

데이터 링크 계층에서 문제가 이미 해결되었다고 가정하기 때문에
로컬 브로드 캐스트 또는 직접 브로드 캐스트 를 보내려 는 IP 호스트
는 적절한 대상 주소 만 지정하고
평소처럼 데이터 그램을 보내면됩니다 . 정교한 알고리즘은 게이트웨이에만 있어야합니다.

소스 IP 주소가 브로드 캐스트와 관련이 없음을 나타내는 읽기

각 응용 프로그램은 방송을 다르게 처리하는 것처럼 보이므로 책임이있는 곳이라고 생각합니다. 예를 들어. nbtstat게임은 글로벌 브로드 캐스트를 사용하는 반면 다중 NIC 컴퓨터에서 직접 브로드 캐스트를 보냅니다.
요컨대, 응용 프로그램은이 경우 OS가 아닌 수정되어야합니다 ...

편집 : 여기 같은 상황에 대한 링크 가 있지만 Linux에 있습니다. 리눅스 커널은 하나의 패킷을 기본 인터페이스 (이 예제에서는 NIC A)로 보내서 처리합니다. 응용 프로그램은 NIC를 열거하고 각 NIC 로 직접 브로드 캐스트를 보내도록 권장합니다 . 링크

— 스콧 룬드 버그
소스

RFC 919에서 인용 한 단락과 소스 주소 사이의 관계를 이해하지 못합니다. 패킷의 브로드 캐스트 / 유니 캐스트 특성에 관계없이 다른 인터페이스의 소스 주소가있는 인터페이스에서 IP 패킷을 보내는 것은 항상 잘못된 것 같습니다 . 물론 "소스 IP 주소는 브로드 캐스트와 관련이 없습니다"라고 합리적으로 말할 수 없습니다. 누가 방송을 보냈는지 애플리케이션이 어떻게 알 수 있습니까?

— Etienne Dechamps

또한 919 년에는 방송을 위해 특정 물리적 인터페이스를 선택해야한다고 언급했다. 어디? "주소 255.255.255.255는 로컬 하드웨어 네트워크에서의 브로드 캐스트를 나타냅니다"(RFC919 7)? 이 경우 나는 정중하게 동의하지 않습니다. 네트워크 수준이 아닌 호스트 수준에서 브로드 캐스트로 수행 할 작업에 대해 논의하고 있습니다. 게다가, 바로 아래에서 호스트는 "255.255.255.255를 사용하여 모든 인접 이웃에게 브로드 캐스트 할 수있다"고합니다. 모든 즉각적인 이웃. "특정 네트워크 인터페이스의 모든 이웃"이 아닙니다.

— Etienne Dechamps

"응용 프로그램은 어떤 인터페이스가 브로드 캐스트를 보냈는지 상관하지 않습니다. 응답 만하면됩니다." 응 ... 그들은 방송을 보내야만한다. LAN 게임 서버 브라우저의 경우를 고려하십시오. 네트워크에서 게임 서버를 발견하기 위해 브로드 캐스트 패킷을 보냅니다. 브로드 캐스트 패킷이 모든 인터페이스로 전송되지 않으면 게임 서버 브라우저는 이러한 인터페이스를 통해 도달 할 수있는 게임 서버를 표시하지 않습니다. 즉, 서사시가 실패합니다.

— Etienne Dechamps

"확실하지는 않지만 OS가 255.255.255.255 요청을보고 모든 인터페이스에서 요청을 보내야한다고 생각하지만 (인접한 모든 이웃을 찾기 위해) 특정 응용 프로그램에서 요청한 것으로 간주합니다. 특정 IP (메트릭에 따라 기본값이 될 수 있음) " 동의한다. 그렇다고 옳은 일이 아닙니다. 내 의견으로는 그것은 모든 인터페이스의 모든 사람에게 패킷을 보낼 것으로 기대하는 응용 프로그램 개발자의 관점에서 볼 때 가장 놀랄만 한 원칙을 완전히 위반합니다.

— Etienne Dechamps

중복의 의미가 확실하지 않습니다. RFC는 특히 브로드 캐스트 패킷의 전달을 금지합니다. 하나의 패킷 만 보내야하는데, 이것이 우리 토론의 핵심이라고 생각합니다. OS가 당신이 말한대로해야한다면 IP 계층은 별도의 소스 IP로 3 개의 패킷을 생성해야하기 때문에 실제로는 9 개의 총 패킷 (각 인터페이스 당 3 개)을 생성해야합니다 (레이어 3의 각 NIC에 대해 하나씩) 각 NIC는 이더넷 (레이어 2)으로 보내야합니다. 네트워크 사이에 경로가 있다면 3 개의 응답을받습니다. 어느 것이 옳습니까?

— Scott Lundberg

마지막으로 프로그래밍 방식으로 해결했습니다. 브로드 캐스트 프레임을 모든 인터페이스에 릴레이하는 WinIPBroadcast 라는 매우 작은 소프트웨어를 작성했습니다 .

흥미로운 사실을 사용하여 작동합니다. 루프백 주소 (127.0.0.1)에서 수신 할 때 로컬로 생성 된 글로벌 브로드 캐스트 패킷을 수신 할 수 있습니다. WinIPBroadcast는 RAW 소켓을 사용하여 모든 브로드 캐스트에 대해 로컬 주소를 수신 한 다음 각 브로드 캐스트 패킷에 대해 선호하는 인터페이스를 제외한 모든 인터페이스로 릴레이합니다.

— 에티엔 느 챔프
소스

Windows 스택은 BSD 스택의 포크이므로 BSD가 동일한 동작을 나타내는 지 궁금합니다.

— x0n

소프트웨어가 작동하지 않습니다. The program can't start becuase api-ms-win-core-rtlsupport-l1-2-0.dll is missing from your computer.. .dllGoogle에서 찾은 행운을 빕니다 .

— Alex G

@ AlexG : 이상합니다 .github.com / dechamps / WinIPBroadcast / commit /…을 통해 그 문제를 해결했다고 생각 했습니다 . 마지막 버전 (1.6)을 실행 중입니까? github.com/dechamps/WinIPBroadcast/issues 에서 버그를 자유롭게 제출 하면 살펴 보겠습니다.

— Etienne Dechamps