UDP пересылка не всегда работает
У меня есть udp перенаправление на VM с правилом
iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 42000:42020 -j DNAT --to-destination 192.168.1.2
iptables -t nat -A POSTROUTING -s 192.168.1.2/32 -j MASQUERADE
iptables -A FORWARD -d 192.168.1.2 -p udp --dport 42000:42020 -j ACCEPT
iptables -A FORWARD -s 192.168.1.2 -j ACCEPT
На VM есть openvpn серверы, слушающие на этих портах.
Теперь у меня странная проблема с пересылкой на хосте: некоторые пакеты маршрутизируются между интерфейсами, а некоторые нет, без четкой схемы почему.
- Одно VPN соединение работает нормально. tcpdump показывает пакеты на
eth0иvmnetна хосте и внутри ВМ. - Три VPN соединения получают пакеты peer на
eth0, которые не направляются наvmnetи пакеты vm наvmnet, которые не направляются наeth0. - UDP-пакеты с тем же портом источника и длиной пакета, что и у одного из неудачных соединений, отправленные через netcat, регистрируются на
eth0,vmnetи внутри виртуальной машины просто отлично.
Что я могу попробовать, чтобы найти, почему пакеты не маршрутизируются на другой интерфейс?
Проблема состоит из двух частей:
Сначала libvirt вставила правило брандмауэра с
- j MASQUERADE --to-port 1024-65535
, которое изменило исходные порты, которые не соответствуют другим правилам и вызывают ошибки в openvpn.
сложная часть, почему это не сработало. И там таблица conntrack сохраняла информацию об исходном порте. Я предполагаю, что пакеты от однорангового узла, которые все еще пытались повторно подключиться, обновили запись в таблице.
Когда я запустил conntrack -D (будьте осторожны, все отслеживаемые соединения будут отключены) , пакеты начали иметь правильный порт источника.
Обратите внимание, что conntrack не может гарантировать исходный порт, но, если он доступен, пытается использовать исходный порт, если не используется параметр - to-ports .