두 인터페이스 사이의 모든 트래픽(이더넷 프레임)이 탭에 연결된 애플리케이션을 통과하도록 두 물리적 인터페이스 사이에 탭(또는 두 개가 필요한 경우 여러 개의 탭)을 생성할 수 있습니까?
이것이 가능하다면 구성 관점에서 어떻게 달성됩니까?
저는 애플리케이션에서 Tap 인터페이스를 읽고 쓰는 데 익숙합니다. 애플리케이션이 양방향으로 트래픽을 읽고 쓸 수 있도록 설정하는 방법을 찾고 있습니다. Linux 장치는 본질적으로 보이지 않는 이더넷 브리지가 됩니다.
내 목표는 애플리케이션이 다음 두 가지 작업을 수행하도록 하는 것입니다.
단방향: 대상 MAC을 기준으로 특정 프레임을 필터링합니다.이더넷 0도착하다이더넷 101:01:01:01:01:01 또는 ff:ff:ff:ff:ff:ff와 일치하지 않는 항목은 삭제됩니다.
다른 방향: 일부 프레임을 지연합니다.이더넷 1도착하다이더넷 0버퍼링된 다음 Y 주기 동안 X 주기마다 한 번만 전송됩니다.
이것이 불가능하거나 가능하더라도 이를 달성할 수 있는 더 좋은 방법이 있습니까?
편집: @dirkt가 답변에서 언급한 접근 방식을 따릅니다.
예. 두 개의 tuntap 인터페이스 tap0과 tap1을 사용하여 애플리케이션을 만든 다음 > tap0을 eth0과 연결하고 tap1을 eth1과 연결합니다.
애플리케이션 계층에서 둘(eth0/tap0 및 eth1/tap1) 사이의 브리지를 구현하는 방법에 대한 적절한 의사 코드/올바른 아이디어입니까?
counter = 0
//eth0 is bridged to tap0
tap0 = open ("tap0")
//eth1 is bridged to tap1
tap1 = open ("tap1")
forever {
//buffer all packets received by eth1 (tap1) - do I need to buffer them constantly or will they wait at the file pointer until I read them (within reason)
packet_buffer[] = read(tap1)
//every 100 cycles (for simplicity)
if (counter == 100) {
//reset counter
counter = 0
//write all buffered packets from eth1 (tap1) to eth0 (tap0)
foreach (packet_buffer as packet){
write(tap0, packet)
}
//empty packet buffer so we can start filling it again (yes very simplified - would likely use a ring buffer)
packet_buffer = []
}
//if eth0 (tap0) gets a packet
if ( packet = read(tap0) ) {
//forward to eth1 (tap1) if the destination is 01:01:01:01:01:01 or ff:ff:ff:ff:ff:ff
if(packet.dest == 01:01:01:01:01:01 OR packet.dest == ff:ff:ff:ff:ff:ff ){
write(tap1, packet)
}
}
//increment counter
counter++
}
답변1
두 인터페이스 사이의 모든 트래픽(이더넷 프레임)이 탭에 연결된 애플리케이션을 통과하도록 두 물리적 인터페이스 사이에 탭(또는 두 개가 필요한 경우 여러 개의 탭)을 생성할 수 있습니까?
예. 두 개의 tuntap 인터페이스를 사용하여 tap0
애플리케이션을 만든 tap1
다음 및 tap0
으로 브리지합니다 .eth0
tap1
eth1
두 개의 브리지된 물리적 인터페이스 간 분할
eth0
및가 이미 브리지된 경우 eth1
아무런 효과가 없습니다. ebtables
브리지 내의 이러한 인터페이스 사이에서 패킷을 "훔쳐" 다른 곳으로 보내야 합니다 .
단방향: 대상 MAC을 기반으로 특정 프레임 필터링
를 사용하여 직접 이 작업을 수행할 수 있습니다 ebtables
.
다른 방향: 일부 프레임 지연
당신은 다음과 같은 것을 사용할 수 있습니다
tc qdisc add dev tap0 root netem delay 100ms
인터페이스에 지연을 추가하지만 한 방향의 "특정 프레임"에 대해 이를 수행하는 것이 실제로 애플리케이션에서 더 쉬울 수 있습니다.