Почему правило ip не соблюдается на моем linux VPS?

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

У меня есть два 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, как это предполагается вашим правилом.

Практическое применение

Теперь посмотрим на возможные причины и решения данной проблемы:

  1. Корректность Правил Маршрутизации:

    • Внимательно проверьте, соответствуют ли правила вашему замыслу. В вашей конфигурации используются метки маршрутизации. Убедитесь, что пакеты правильно маркируются и проверяются. Например, для проверки используйте:
      iptables -t mangle -L -v

      Также проверьте, действительно ли пакеты получают метку 10 и корректно ли сохраняется метка соединения.

  2. Проблемы с Таблицами Маршрутизации:

    • Проверьте таблицы маршрутизации с помощью ip route show table eth0. Убедитесь, что правила маршрутизации установлены именно так, как вы этого ожидали.
    • Возможно, потребуется поменять приоритеты маршрутов или добавить фиксированные маршруты для состояния established,related.
  3. Media type-specific issues:

    • Обратите внимание на пакетную фильтрацию для UDP. Как правило, UDP-трафик ведет себя по-разному из-за своей безсостоятельной природы и, возможно, пропускаются некоторые состояния соединений. Подтвердите с помощью conntrack-tools, что соответствующие соединения исправно отслеживаются.
  4. Ошибки в firewalld настройках:

    • Убедитесь в том, что правила firewalld сохраняются корректно после перезапуска. Необычный прирост номера правила (32761, 32762) может указывать на доменные конфликты или ошибки при установке маршрутов через firewalld.
  5. Логика Применения Правил:

    • Позаботьтесь о порядке применения правил. Правила маршрутизации проверяются в заданном порядке, и первое подходящее правило будет применено. Убедитесь, что правила, которые более специализированы, установлены до более общих.
  6. Технический Debugging:

    • Попробуйте временно отключить дополнительные средства безопасности и оптимизации, чтобы понять, влияет ли какое-то из них на выполнение ваших правил.
    • Используя команду tcpdump, запишите и проанализируйте реальный трафик, который выходит через tunnel1, и удостоверьтесь, что он правильно обрабатывается до применения маршрутизации.

Заключение

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

Для окончательного решения мониторьте выполнение правил и схемы маршрутизации с помощью встроенных сетевых инструментов. Надеюсь, представленные рекомендации помогут вам выявить и устранить ваше сетевое затруднение.

Оцените материал
Добавить комментарий

Капча загружается...