Приложение не удалось получить пакет, IP таблицы перенаправлены

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

Я использую iptables на Debian. У меня есть 2 сервера, 1 для передачи трафика и 1 для хостинга моего приложения и приема трафика. Я настроил следующие правила на первом сервере –

Chain PREROUTING (policy ACCEPT 2476 packets, 102K bytes)
 pkts bytes target     prot opt in     out     source               destination
    6   328 DNAT       6    --  *      *       0.0.0.0/0            15.235.163.198       tcp dpt:6900 to:10.8.0.18:6900
    0     0 DNAT       6    --  *      *       0.0.0.0/0            15.235.163.198       tcp dpt:6900 to:10.8.0.18:6900
    0     0 DNAT       6    --  *      *       0.0.0.0/0            15.235.163.198       tcp dpt:6900 to:10.8.0.18:6900

Chain INPUT (policy ACCEPT 2474 packets, 101K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 12574 packets, 755K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 12612 packets, 757K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  0    --  *      ens3    10.8.0.0/24          0.0.0.0/0
    0     0 MASQUERADE  0    --  *      ens3    10.8.0.0/24          0.0.0.0/0
    0     0 MASQUERADE  0    --  *      ens3    10.8.0.0/24          0.0.0.0/0

Перенаправленные маршруты –

debian@2:~$ sudo iptables -L FORWARD -v -n
Chain FORWARD (policy ACCEPT 71 packets, 3708 bytes)
 pkts bytes target     prot opt in     out     source               destination
    4   208 ACCEPT     6    --  *      *       0.0.0.0/0            10.8.0.18            tcp dpt:6900 state NEW,RELATED,ESTABLISHED

Я получаю пакеты на втором сервере –

debian@debian:~/build/bin/Debug$ sudo tcpdump -i tun0 port 6900
tcpdump: подробный вывод подавлен, используйте -v[v]... для полного декодирования протокола
прослушивание на tun0, тип канала RAW (необработанный IP), длина снимка 262144 байта
12:11:20.080001 IP 49.47.2.38.42978 > 10.8.0.18.6900: Flags [S], seq 3431906189, win 64240, options [mss 1399,nop,wscale 8,nop,nop,sackOK], length 0
12:11:21.096123 IP 49.47.2.38.42978 > 10.8.0.18.6900: Flags [S], seq 3431906189, win 64240, options [mss 1399,nop,wscale 8,nop,nop,sackOK], length 0
12:11:23.109073 IP 49.47.2.38.42978 > 10.8.0.18.6900: Flags [S], seq 3431906189, win 64240, options [mss 1399,nop,wscale 8,nop,nop,sackOK], length 0
12:11:27.110487 IP 49.47.2.38.42978 > 10.8.0.18.6900: Flags [S], seq 3431906189, win 64240, options [mss 1399,nop,wscale 8,nop,nop,sackOK], length 0

но мое приложение не может их получить. Оно не показывает, что получило что-либо, и не выводит никаких логов о полученных пакетах на втором сервере. Как так получилось, что сервер получает трафик, но приложение не может его получить? Приложение привязано к правильному IP-адресу на порту 6900. В последний раз оно работало, когда я настраивал ту же систему. Может кто-то помочь мне? В чем может быть проблема?

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

Проблема: Приложение не получает пакеты, несмотря на настройку IP-тестов

Введение

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

Текущая конфигурация

На вашем сервере, который осуществляет пересылку трафика, присутствуют следующие правила iptables:

  1. PREROUTING:

    • Применяется DNAT для перенаправления трафика, поступающего на IP 15.235.163.198, порту 6900, на локальный IP 10.8.0.18, порт 6900.
  2. FORWARD:

    • Разрешен пересылаемый трафик на локальный сервер, исходящий от любой подсети, но с условием, что он в состоянии NEW, RELATED или ESTABLISHED.
  3. POSTROUTING:

    • Используется MASQUERADE для подсети 10.8.0.0/24, что позволяет скрывать внутренние IP-адреса.

Наблюдения и анализ

  1. Трафик поступает: Вы наблюдаете пакеты на интерфейсе tun0 второго сервера, что подтверждает, что трафик действительно приходит на сервер, но не достигает вашего приложения.

  2. Отсутствие ответов от приложения: Если приложение не отвечает на SYN-пакеты (с флагом [S]), это может указывать на проблемы ниже:

    • Приложение не запущено или неправильно настроено: Убедитесь, что приложение действительно запущено и слушает на правильном IP и порту. Используйте команды типа netstat -tuln для проверки.

    • Разрешения фаервола: Возможно, дополнительные фаерволы (например, UFW, Firewalld, или встроенные механизмы безопасности системы) блокируют соединения. Убедитесь, что они настроены на разрешение трафика.

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

    • Приложение отвечает на пакеты: Возможно, ваш сервер не может правильно обработать входящие SYN-пакеты. Если приложение требует дополнительной конфигурации, например, использование TLS или определенных заголовков, это также может привести к тому, что оно не будет обрабатывать эти запросы.

Рекомендации по устранению проблем

  1. Проверка состояния службы:
    Проверьте, запущено ли ваше приложение и активно ли оно слушает:

    netstat -tuln | grep 6900
  2. Отключение дополнительных фаерволов:
    Если есть фаервол кроме iptables, попробуйте временно его отключить, чтобы проверить, не он ли является причиной.

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

  4. Тестирование с помощью telnet или nc:
    Проверьте, можете ли вы вручную подключиться к приложению с помощью telnet или nc, чтобы увидеть, реагирует ли оно на входящие соединения.

  5. Анализ сетевых интерфейсов:
    Убедитесь, что настройки сетевого интерфейса на втором сервере корректны и у вас нет конфликтов IP-адресов или масок подсети.

Заключение

Ваша текущая конфигурация iptables на первый взгляд выглядит корректно настроенной. Однако отсутствие отклика от приложения может указывать на более глубокие проблемы с его конфигурацией или сетевыми настройками. Методично выполняйте описанные шаги, и, скорее всего, вы сможете обнаружить и устранить причину проблемы. Удачи!

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

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