☰

브리지에서 캡처된 패킷에 대한 원시 장치(물리적 장치) 정보 가져오기

tag-icon • tag-icon linux bridge socket vlan
브리지에서 캡처된 패킷에 대한 원시 장치(물리적 장치) 정보 가져오기

아래에 내 프레임워크가 통과하려는 네트워크 장치 세트가 있다고 가정해 보겠습니다.

eth0(1) -> bond0(2) -> 브리지(3) -> vlan100(4). >>>(숫자)는 각 네트워크 장치의 ifindex입니다.

나는 원시 소켓(인터페이스에 바인딩되지 않음)을 만들고 특정 패킷 세트만 캡처하기 위해 소켓 필터를 연결했습니다.

각 네트워크 장치에서 캡처된 프레임의 복사본을 얻습니다. 이것이 예상되는가?

캡처된 각 패킷에 대해 from.sll_ifindex를 인쇄합니다.

frame trapped from eth0 has from.sll_ifindex=1 
frame trapped from bond0 has from.sll_ifindex=2 
frame trapped from bridge has from.sll_ifindex=3 
frame trapped from vlan100 has from.sll_ifindex=4

이제 다음 소켓 옵션 PACKET_ORIGDEV를 설정하고 다음 결과를 얻습니다.

frame trapped from eth0 has from.sll_ifindex=1
frame trapped from bond0 has from.sll_ifindex=1   >> acceptable since the originating device is eth0 whose ifindex is 1.
frame trapped from bridge has from.sll_ifindex=3  >> why is this not set to 1?
frame trapped from vlan100 has from.sll_ifindex=3 >> why is this not set to 1?

위 시나리오에서 PACKET_ORIGDEV 소켓 옵션이 수행하는 역할을 이해하는 데 도움을 줄 수 있는 사람이 있습니까?

답변1

bond0프레임이 코어 내에서 코어 내로 변환되는 방식은 bridge다른 두 변환과 다릅니다. 반복하는 대신another_round내부적으로 __netif_receive_skb_core()프레임은 내부적으로 전달됩니다 br_handle_frame_finish(). orig_dev이 호출 경로는 이 정보를 유지하지 않습니다. 나는 입력 포트가 브리지 계열의 일부 netfilter 후크에서 사용할 수 있을 만큼만 기록된다고 생각합니다. 사용자 공간에서는 사용할 수 없습니다.

PACKET_ORIGDEV,소개되면, 캡슐화 사례를 다루기 위한 것입니다. 교량에도 적용해야 한다고 주장할 수도 있지만, 내 생각에는 이는 쉽게 구현할 수 있는 변화는 아니다. 관련된 기능 중 일부는 수신 경로에서 중요합니다.

관련 정보