Назад | Перейти на главную страницу

conntrack отслеживает частные сеансы TCP между виртуальными машинами

У нас есть пара виртуальных машин, работающих как виртуальные маршрутизаторы, и пиринг BGP / TCP между двумя виртуальными маршрутизаторами (работающий через QEMU / KVM). Каждая виртуальная машина имеет интерфейс ответвления, который подключен к мосту Linux, участниками которого являются только два ответвителя.

Все работает отлично, за исключением того, что мы видим, что conntrack, похоже, сообщает о сеансах TCP между этими двумя виртуальными машинами. Первоначально мы думали, что сеансы TCP протекают и что это дыра в безопасности, но netstat ничего не сообщает. Похоже, что мы не выделяем TCB для этого в ОС хоста (что правильно); уф. Трафик гостевой ОС должен быть прозрачным для ОС хоста, каковым кажется; в основном.

Причина, по которой такое поведение conntrack является проблемой, заключается в том, что если обе виртуальные машины сбрасываются одновременно, то не остается ни одной работающей, чтобы отправлять какой-либо трафик в гостевых сеансах TCP, чтобы вызвать сброс TCP; таким образом, мы получаем "утечку" conntrack в ОС хоста. Со временем это нарастает, и в конечном итоге у ОС хоста заканчиваются ресурсы. В этом тесте много сеансов BGP. Кажется, это способ для гостевой ОС сделать DoS на хост-ОС ...

Это допустимое поведение для conntrack? Это частный обмен данными между виртуальными машинами через мост L2. Почему Linux должен отслеживать и записывать такие сеансы TCP? Это ошибка или особенность?

Большинство подходов, кажется, используют iptables, чтобы остановить это; мы действительно не хотим просить об этом клиента. Есть другие предложения?

Да, такое поведение ожидается, хотя я не уверен, что это та проблема, которую вы ожидаете. И TCP, и UDP-соединения в таблице conntrack истекают со временем сами по себе. Вы можете увидеть значения тайм-аута в /proc/sys/net/netfilter/*timeout* и отрегулируйте эти значения с помощью /proc или sysctl. Обратите внимание, это может быть иначе в старых ядрах, возможно /proc/sys/net/ipv4/netfilter/.

Если это не поможет, и вы не удовлетворены решением iptables -t raw -j NOTRACK, вы можете отключить обработку iptables мостовых соединений, установив

sysctl -w net.bridge.bridge-nf-call-arptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0
sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-filter-vlan-tagged=0

или установив те же параметры в /etc/sysctl.conf. Оба они отключат передачу мостового трафика до iptables, что должно иметь эффект обхода conntrack.

В качестве альтернативы вы можете полностью отключить ip_conntrack, если вы его не используете, занеся модуль в черный список или отключив его иным образом в своем ядре.