Вопрос или проблема
У меня есть два VPS, один — это игровой сервер, а другой — прокси-сервер. Я соединил их вместе через туннель FOU IPIP. На игровом сервере я установил туннель в качестве шлюза по умолчанию, теперь трафик проходит через него. Я также хочу поддерживать прямое соединение с игровым сервером для использования разных сетевых каналов. Однако ip правило, которое я настроил, не соблюдается вообще.
Это моя настройка на прокси-сервере
firewall-cmd --add-interface=tunnel1 --zone=trusted --permanent
firewall-cmd --add-masquerade --zone=public --permanent
firewall-cmd --zone=public --add-port=42011/udp --permanent
firewall-cmd --zone=public --add-port=16261:16262/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
sysctl -w net.ipv4.ip_forward=1
modprobe fou
ip fou add port 42011 ipproto 4
modprobe ipip
ip link add name tunnel1 type ipip remote <remote VPS public IP> local <local VPS public IP> ttl 225 encap fou encap-sport 42011 encap-dport 42011
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=42011/udp --permanent
firewall-cmd --zone=public --add-port=16261:16262/udp --permanent
firewall-cmd --permanent --direct --add-rule ipv4 mangle PREROUTING 0 -i eth0 -m conntrack --ctstate NEW -j MARK --set-mark 10
firewall-cmd --permanent --direct --add-rule ipv4 mangle PREROUTING 1 -m mark --mark 10 -j CONNMARK --save-mark
firewall-cmd --permanent --direct --add-rule ipv4 mangle OUTPUT 0 -j CONNMARK --restore-mark
ip route add default via <local VPS public gateway> dev eth0 proto static metric 100 table eth0
ip rule add to <remote VPS public IP>/32 table eth0
ip rule add fwmark 10 table eth0
modprobe fou
ip fou add port 42011 ipproto 4
modprobe ipip
ip link add name tunnel1 type ipip remote <remote VPS public IP> local <local VPS public IP> ttl 225 encap fou encap-sport 42011 encap-dport 42011
ip addr add 192.168.1.2/30 dev tunnel1
ip link set tunnel1 up
ip route delete default via <local VPS public gateway>
ip route add default via 192.168.1.2 dev tunnel1 metric 100
Я проверил с помощью conntrack -L | grep <local VPS public IP>
и tcpdump -u -i any udp and host <my public IP>
. Я вижу, что мой клиентский UDP принят сервером, он также помечен как 10. Однако он выходит из tunnel1 вместо eth0, что указано в ip правило для метки 10. Почему?!
Это мое текущее правило IP на игровом сервере
0: from all lookup local
32761: from all fwmark 0xa lookup eth0
32762: from 192.168.1.2 lookup tunnel1
32764: from all to <proxy public ip> lookup eth0
32766: from all lookup main
32767: from all lookup default
Кстати, TCP не имеет такой проблемы, только UDP.
Ответ или решение
Ваш вопрос о том, почему правило IP, которое вы настроили, не влияет на трафик вашего game-сервера, заслуживает детального разбора и изучения. Постараемся подойти к решению проблемы методично и шаг за шагом.
Теория
Ваш game-сервер и proxy-сервер связаны через туннель FOU IPIP, который вы используете как основной шлюз для отправки трафика. Однако, вместе с этим, вам необходимо сохранить прямую связь с game-сервером, чтобы использовать различные сетевые пути. Это нуждается в применении отдельных правил маршрутизации и преобразовании маршрутов (марковке пакетов).
Использование стратегий маршрутизации (policy routing) и работы с маркировкой пакетов через iptables
– это стандартный подход для реализации таких задач. Сетевой стек Linux позволит вам настроить сложные схемы маршрутизации и заниматься разметкой соединений, чтобы направлять трафик по нужным путям сетей. Такие схемы особенно полезны для VPN, продвинутого разделения нагрузки и изоляции трафика.
Пример
В вашем случае, ваши правила ip были настроены таким образом, чтобы помечать пакеты, идущие на конкретные порты UDP, меткой 10
, после чего использовать эту метку для маршрутизации трафика через интерфейс eth0
. Тем не менее, текущая схема маршрутизации показывает, что это правило не работает должным образом для UDP-трафика, который уходит через tunnel1
, вместо того чтобы следовать через eth0
, как это предполагается вашим правилом.
Практическое применение
Теперь посмотрим на возможные причины и решения данной проблемы:
-
Корректность Правил Маршрутизации:
- Внимательно проверьте, соответствуют ли правила вашему замыслу. В вашей конфигурации используются метки маршрутизации. Убедитесь, что пакеты правильно маркируются и проверяются. Например, для проверки используйте:
iptables -t mangle -L -v
Также проверьте, действительно ли пакеты получают метку
10
и корректно ли сохраняется метка соединения.
- Внимательно проверьте, соответствуют ли правила вашему замыслу. В вашей конфигурации используются метки маршрутизации. Убедитесь, что пакеты правильно маркируются и проверяются. Например, для проверки используйте:
-
Проблемы с Таблицами Маршрутизации:
- Проверьте таблицы маршрутизации с помощью
ip route show table eth0
. Убедитесь, что правила маршрутизации установлены именно так, как вы этого ожидали. - Возможно, потребуется поменять приоритеты маршрутов или добавить фиксированные маршруты для состояния
established,related
.
- Проверьте таблицы маршрутизации с помощью
-
Media type-specific issues:
- Обратите внимание на пакетную фильтрацию для UDP. Как правило, UDP-трафик ведет себя по-разному из-за своей безсостоятельной природы и, возможно, пропускаются некоторые состояния соединений. Подтвердите с помощью
conntrack-tools
, что соответствующие соединения исправно отслеживаются.
- Обратите внимание на пакетную фильтрацию для UDP. Как правило, UDP-трафик ведет себя по-разному из-за своей безсостоятельной природы и, возможно, пропускаются некоторые состояния соединений. Подтвердите с помощью
-
Ошибки в
firewalld
настройках:- Убедитесь в том, что правила
firewalld
сохраняются корректно после перезапуска. Необычный прирост номера правила (32761
,32762
) может указывать на доменные конфликты или ошибки при установке маршрутов черезfirewalld
.
- Убедитесь в том, что правила
-
Логика Применения Правил:
- Позаботьтесь о порядке применения правил. Правила маршрутизации проверяются в заданном порядке, и первое подходящее правило будет применено. Убедитесь, что правила, которые более специализированы, установлены до более общих.
-
Технический Debugging:
- Попробуйте временно отключить дополнительные средства безопасности и оптимизации, чтобы понять, влияет ли какое-то из них на выполнение ваших правил.
- Используя команду
tcpdump
, запишите и проанализируйте реальный трафик, который выходит черезtunnel1
, и удостоверьтесь, что он правильно обрабатывается до применения маршрутизации.
Заключение
Проблема маршрутизации трафика через конкретные интерфейсы и туннели может зависеть как от конфигураций сетевой службы, так и от нежелательных конфликтов в правилах или маршрутах. Обеспечение прямого канала коммутации с eth0
в вашем случае включает углубленный анализ сетевых политик и установленных правил. Успех их работы может улучшиться с помощью продуманной диагностики, начиная от маршрутов и заканчивая сообществом UDP-пакетов, найденных в подводных камнях обработок iptables.
Для окончательного решения мониторьте выполнение правил и схемы маршрутизации с помощью встроенных сетевых инструментов. Надеюсь, представленные рекомендации помогут вам выявить и устранить ваше сетевое затруднение.