Зеркальное отображение трафика с tc через GRE Tunnel только получает входной трафик

Я пытаюсь отразить "весь" сетевой трафик с одного интерфейса с помощью tc через GRE-туннель tun0, GRE-Tunnel работает нормально, я могу пинговать и отправлять пакеты через него без каких-либо проблем. Я добавил tc-qdisc а также tc-filter с помощью следующих команд:

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 чем я только получаю icmp echo replies сквозь tun0 интерфейс. Что я делаю неправильно?

отлаживать

ubuntu@switch:~$ 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 отражает исходящий трафик с помощью заголовка Ethernet и входящий трафик без заголовка Ethernet. Туннель GRE ожидает только IP-пакеты, поэтому имелось несоответствие заголовка. Если я использую VXLAN вместо GRE, он работает нормально.

Источник

Я никогда не работал с GRE-Tunnels, но, исходя из ссылки на Учебник, которую вы разместили, это как-то связано с мостовыми интерфейсами? В настоящее время я также работаю с Linux Traffic Control (tc) на мостовом интерфейсе - в моем случае это мост, созданный Docker, и мне приходится манипулировать трафиком (а не только перенаправлять его).

Исходя из моего опыта, я могу сказать, что tc не работает так, как ожидалось, когда вы добавляете tc классы / фильтры в интерфейс моста. Это в основном основано на определении входного и выходного трафика на мосту, что (для меня) очень запутанно. Я также проверил свою конфигурацию tc с помощью функции ICMP-Ping, и, как и вы, я также мог манипулировать только ответом ICMP.

Я предположил, что tc не реагирует на запрос ICMP, так как в моем случае он был переключен только между портами моста и не маршрутизировался. Я смог обработать ICMP-запрос с помощью tc, отбросив его с помощью ebtables ( http://ebtables.netfilter.org/) и, следовательно, принудительно направил его вместо переключения между портами моста.

Тем не менее, я не уверен, будет ли это решением вашей проблемы, поскольку я не уверен, как работают GRE-туннели или как они реализованы.

Источник
Другие вопросы по тегам