Почему моя игра, работающая на сервере Linux, не использует правильный маршрут? [закрыт]

Вопрос или проблема

firewall-cmd --add-masquerade --zone=public  --permanent
firewall-cmd --add-interface=tunnel1 --zone=trusted --permanent
firewall-cmd --zone=public --add-port=32011/udp --permanent
firewall-cmd --permanent --direct --add-rule ipv4 nat PREROUTING 0 -p udp -i eth0 --dport 16261:16262 -j DNAT --to-destination 192.168.1.2
firewall-cmd --permanent --direct --add-rule ipv4 nat PREROUTING 0 -p tcp -i eth0 --dport 16261:16262 -j DNAT --to-destination 192.168.1.2
modprobe fou
modprobe ipip
sysctl -w net.ipv4.ip_forward=1
ip fou add port 32011 ipproto 4
ip link add name tunnel1 type ipip remote <remot vps public ip> local <current vps public ip> ttl 225 encap fou encap-sport 32011 encap-dport 32011
ip addr add 192.168.1.1/30 dev tunnel1
ip link set tunnel1 up

firewall-cmd --add-interface=tunnel1 --zone=trusted --permanent
firewall-cmd --zone=public --add-port=32011/udp --permanent
firewall-cmd --permanent --direct --add-rule ipv4 mangle PREROUTING 0 -i eth0 -m conntrack --ctstate NEW -j MARK --set-mark 1
firewall-cmd --permanent --direct --add-rule ipv4 mangle PREROUTING 1 -m mark --mark 0x1 -j CONNMARK --save-mark
firewall-cmd --permanent --direct --add-rule ipv4 mangle OUTPUT 0 -j CONNMARK --restore-mark
modprobe fou
modprobe ipip
ip link add name tunnel1 type ipip remote <remot vps public ip> local <current vps public ip> ttl 225 encap fou encap-sport 32011 encap-dport 32011
ip addr add 192.168.1.2/30 dev tunnel1
ip link set tunnel1 up
ip route add default via <vps gateway> dev eth0 table eth0
ip rule add fwmark 1 table eth0
ip rule add to <proxy public ip>/32 table eth0
ip route replace default via 192.168.1.2 dev tunnel1

Ответ или решение

Сообщения об ошибках и неправильная маршрутизация трафика игры на сервере Linux могут быть довольно сложной задачей для диагностики, особенно когда речь идет об использовании UDP и сложных настройках, таких как туннелирование через Firewall-offload Using (FOU). Давайте подробно разберем возможные причины проблемы и шаги, которые вы можете предпринять, чтобы исправить ситуацию.

Теория

Для начала, важно понять, как происходит маршрутизация в Linux, особенно в контексте использования туннелей и преобразования сетевых пакетов. При использовании UDP, один из основных вызовов заключается в том, что этот протокол является безсессионным, что делает его отслеживание сложным по сравнению с TCP. Это означает, что многие методы маркирования пакетов, которые работают с TCP, могут не работать ожидаемым образом с UDP, если они построены на основе концепций последовательности и состояния соединения.

При настройке прокси-сервера и игрового сервера, обеспечивая их взаимодействие через туннель, вы сообщили, что трафик происходит через интерфейс tunnel1, который настроен с использованием FOU и IPIP. При этом команда firewall-cmd и внесение различных правок в маршрутизацию могут создать сложные сетевые сценарии, которые требуют точной конфигурации.

Пример

Вы настроили несколько правил, используя команду firewall-cmd. Эти правила, в частности, включают masquerade, добавление интерфейсов в доверенные зоны, а также установки для перенаправления трафика. Ниже приведены несколько деталей вашей текущей конфигурации:

• Использование masquerade на прокси-сервере для подмены исходного IP адреса пакетов.
• Установка постоянных правил NAT PREROUTING, которые перенаправляют трафик UDP и TCP на заданный IP 192.168.1.2.
• Настройка FOU (Firewall-offload Using) и IPIP, чтобы создать туннель между двумя серверами.

На стороне игрового сервера у вас также добавлены сложные правила маршрутизации и управления трафиком с использованием firewall-cmd и утилит по работе с туннельными интерфейсами и состояниями соединений.

Применение

Исходя из вашей конфигурации и проблемы, с которой вы столкнулись, основная гипотеза заключается в том, что ваши правила коннтрек и маркировки фреймворка для UDP-пакетов не функционируют должным образом. Это может быть вызвано несколькими причинами, включая неверную конфигурацию маршрутизации или неправильно настроенные таблицы маршрутизации и правила.

Вот несколько шагов, которые могут помочь вам решить вашу проблему:

1. Проверка соответствия правил и маршрутизации: Убедитесь, что все правила маршрутизации и обработки пакетов (включая маркеры) установлены корректно и соответствуют ожидаемому потоку данных.

2. Учет правил IPTables и Firewalld: Проверьте, нет ли конфликтов между вашим firewall-cmd и другими ранее установленными правилами iptables. В случае необходимости пересмотрите конфигурацию, чтобы устранить возможные противоречия.

3. Обратите внимание на MTU (Maximum Transmission Unit): Неправильные значения MTU могут привести к неэффективности туннеля, особенно при передаче пакетов через различные сети, что часто приводит к неправильной маршрутизации или потере пакетов.

4. Запуск утилит анализа трафика: Использование инструментов анализа сетевого трафика, таких как tcpdump или wireshark, чтобы понять, какие пакеты получаются и откуда они исходят, может значительно помочь в выявлении маршрутизации или других сетевых проблем.

5. Протестируйте отдельно каждую часть цепочки: Вместо комплексного подхода, попытайтесь определить, как трафик проходит через каждый узел, начиная с отправной точки и заканчивая предполагаемым пунктом назначения.

6. Упрощение конфигурации (если возможно): Если какая-то часть вашей конфигурации может быть упрощена, начните с удаления ненужных правил и протестируйте маршрутировку в их отсутствие.

7. Логи и диагностика системы: Проверка системных логов может дать подсказку о наличии ошибок или предупреждений, которые остались незамеченными в ходе первоначальной настройки.

При работе с подобными сценариями, рекомендуем регулярно проверять и документировать каждый шаг изменения конфигурации, чтобы иметь возможность быстро откатиться к рабочей версии в случае возникновения непредвиденных проблем.