원하는 행동
응용 프로그램이 글로벌 브로드 캐스트 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)에서 한 번에 변경하고 싶습니다. 물론 더 좋은 방법은 일종의 지원되는 구성 변경 (레지스트리 해킹 또는 이와 유사한 것)을 갖는 것이지만 모든 제안에 개방적입니다.
어떤 아이디어?
답변
내가 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 로 직접 브로드 캐스트를 보내도록 권장합니다 . 링크
답변
마지막으로 프로그래밍 방식으로 해결했습니다. 브로드 캐스트 프레임을 모든 인터페이스에 릴레이하는 WinIPBroadcast 라는 매우 작은 소프트웨어를 작성했습니다 .
흥미로운 사실을 사용하여 작동합니다. 루프백 주소 (127.0.0.1)에서 수신 할 때 로컬로 생성 된 글로벌 브로드 캐스트 패킷을 수신 할 수 있습니다. WinIPBroadcast는 RAW 소켓을 사용하여 모든 브로드 캐스트에 대해 로컬 주소를 수신 한 다음 각 브로드 캐스트 패킷에 대해 선호하는 인터페이스를 제외한 모든 인터페이스로 릴레이합니다.
