2016-12-08 24 views
0

GRE 터널 tun0을 통해 tc의 도움으로 하나의 인터페이스에서 "모든"네트워크 트래픽을 미러링하려고합니다. GRE 터널은 정상적으로 작동하며 핑 (ping)을 통해 아무런 문제없이 패킷을 보낼 수 있습니다. 나는 다음과 같은 명령을 사용하여 tc-qdisctc-filter 추가 :이 TutorialGRE 터널을 통한 tc로 트래픽 미러링은 들어오는 트래픽 만 수신합니다.

문제에

tc qdisc add dev ens5 ingress 

tc filter add dev ens5 parent ffff: \ 
protocol all \ 
u32 match u8 0 0 \ 
action mirred egress mirror dev tun0 

tc qdisc add dev ens5 handle 1: root prio 

tc filter add dev ens5 parent 1: \ 
protocol all \ 
u32 match u8 0 0 \ 
action mirred egress mirror dev tun0 

등이

에만 문제가 유입 트래픽이오고 있다는 것입니다 GRE 터널을 통해. 인터페이스 ens5을 통해 다른 컴퓨터에 ping을 수행 할 때 tun0 인터페이스를 통해서만 icmp echo replies을 얻습니다. 내가 뭘 잘못 했니?

디버그

[email protected]:~$ tcpdump -i tun0 icmp 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 
10:23:28.952197 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 1, length 64 
10:23:29.954454 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 2, length 64 
10:23:30.952864 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 3, length 64 
10:23:31.953207 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 4, length 64 
10:23:32.955350 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 5, length 64 
10:23:33.957000 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 6, length 64 
10:23:34.956313 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 7, length 64 

답변

2

혼자서 문제가 해결되었습니다.

TC는 이더넷 헤더 GRE 터널은 IP-패킷을 기대하지 않고 송신 트래픽을와 이더넷 헤더 및 유입 트래픽 을 반영, 그래서 헤더 불일치가 발생했습니다. GRE 대신 VXLAN을 사용하는 경우 정상적으로 작동합니다.

+0

터널을 통해 미러링 된 트래픽을 어떻게 처리 했습니까? GRE 또는 VXLAN 터널에 egress 스 니펫을 적용 할 때마다 Linux 호스트가 잠 깁니다. 내부 스 니펫이 정상적으로 작동합니다. 몇 가지 다른 배포판을 사용해보십시오. – Astron

+1

VXLAN을 생성하여 터널 인터페이스 tun0을 추가했습니다. 그런 다음 위와 같이 정확한 명령을 사용했습니다. 예 : IP 링크 추가 vxlan0 유형 vxlan id 42 그룹 1.1.1.1 dev eth0' – Florian

+0

이상한, 장치 이름에 대해 vxlan42와 같은 tun0 verse를 지정하면 충돌이 발생했습니다. – Astron

0

내가 GRE - 터널과 협력,하지만 당신이 게시 된 튜토리얼 링크를 기반 결코, 그것은 다리 인터페이스를 함께 할 수있는 뭔가가? 현재 저는 브리지 인터페이스에서 Linux Traffic Control (tc)을 사용하고 있습니다. 제 경우에는 Docker가 만든 브리지이며 트래픽을 조작해야합니다 (리디렉션 만하는 것은 아닙니다).

내 경험에 비추어 볼 때, tc 클래스/필터를 브리지 인터페이스에 추가 할 때 tc가 예상대로 작동하지 않는다고 말할 수 있습니다. 대부분 브리지에 대한 입구 및 출구 트래픽의 정의를 기반으로하며, 이는 (나를 위해) 매우 혼란 스럽습니다. 또한 ICMP-Ping 기능으로 tc 구성을 테스트했으며 ICMP 응답 만 조작 할 수있었습니다.

필자의 가정은 tc가 ICMP 요청에 반응하지 않는다는 것입니다. 제 경우처럼 브리지 포트 사이에서만 전환되었고 라우팅되지 않았습니다. 나는 ebtables (http://ebtables.netfilter.org)를 사용하여 tc로 ICMP 요청을 처리 할 수 ​​있었고 따라서 브리지 포트 사이를 전환하는 대신 라우트되도록했습니다.

아직도 GRE 터널이 작동하는 방법이나 구현 방법을 잘 모르기 때문에 이것이 문제의 해결책이 될지 확실하지 않습니다.

+0

답장을 보내 주셔서 감사합니다. 조금 더 깊이 파고 들었습니다. 문제는 tc 필터가 이더넷 헤더가있는 패키지를 미러링하고 있다는 것입니다. 예상되는 IP 헤더 대신 이더넷 헤더가 있기 때문에 누락 된 모든 패킷이 손상되었습니다. – Florian