iptables – почему порты STUN, TURN не работают, чтобы позволить конечным точкам получить доступ к серверу?

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

$ cat /etc/sysconfig/iptables
# Создано iptables-save v1.4.7 в Чт Ноя 21 10:21:41 2013
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp --dport 3478 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5349 -j ACCEPT
-A INPUT -p udp -m udp --dport 5349 -j ACCEPT
-A INPUT -p udp -m udp --dport 3478 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT
-A INPUT -p udp -m udp -m string --dport 5080 -j DROP  --string "friendly-scanner" --algo bm --to 65535 
-A INPUT -p udp -m udp -m string --dport 5060 -j DROP  --string "friendly-scanner" --algo bm --to 65535 
-A INPUT -p tcp -m tcp --dport 5081 -j ACCEPT
-A INPUT -p udp -m udp --dport 5081 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5080 -j ACCEPT
-A INPUT -p udp -m udp --dport 5080 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5061 -j ACCEPT
-A INPUT -p udp -m udp --dport 5061 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5060 -j ACCEPT
-A INPUT -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -p udp -m udp --dport 16000:42000 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 7007 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state -m tcp --dport 22 --state NEW -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A INPUT -s 178.162.205.224/32 -j DROP
-A INPUT -s 65.55.44.100/32 -j DROP
-A INPUT -s 178.162.205.224/32 -j DROP
-A INPUT -s 91.218.247.162/32 -j DROP
-A INPUT -s 85.25.78.58/32 -j DROP
-A INPUT -s 91.218.247.162/32 -j DROP

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

-A INPUT -j ACCEPT

COMMIT
# Завершено в Чт Ноя 21 10:21:41 2013
# Создано webmin
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Завершено
# Создано webmin
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Завершено

-A INPUT -s 178.162.205.224/32 -j DROP
-A INPUT -s 65.55.44.100/32 -j DROP
-A INPUT -s 178.162.205.224/32 -j DROP
-A INPUT -s 91.218.247.162/32 -j DROP
-A INPUT -s 85.25.78.58/32 -j DROP
-A INPUT -s 91.218.247.162/32 -j DROP

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

Причина, по которой порты STUN и TURN (3478 и 5349) могут не работать, когда у вас есть настроенные правила iptables, заключается в возможных конфигурационных ограничениях или неправильных правилах. Давайте тщательно разберем данную конфигурацию iptables и попробуем выявить возможные проблемы, следуя подходу TEA (Теория, Пример, Применение).

Теория

STUN (Session Traversal Utilities for NAT) и TURN (Traversal Using Relays around NAT) — это протоколы, которые помогают устройствам за NAT общаться друг с другом. Они обычно используют порты 3478 и 5349 для передачи трафика как по TCP, так и по UDP. STUN помогает определить внешний IP-адрес и природу сетевого подключения, в то время как TURN используется для ретрансляции медиа в случаях, когда P2P (peer-to-peer) соединение невозможно.

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

Пример

Посмотрим на ваш текущий набор правил iptables:

-A INPUT -p tcp -m tcp --dport 3478 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5349 -j ACCEPT
-A INPUT -p udp -m udp --dport 5349 -j ACCEPT
-A INPUT -p udp -m udp --dport 3478 -j ACCEPT
...
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited

По указанным правилам, порты 3478 и 5349 открыты для трафика TCP и UDP, что на первый взгляд кажется правильным. Однако, несмотря на открытие этих портов, связь может все равно блокироваться из-за других факторов.

Применение

1. Проверка применимости правил: Прежде всего, убедитесь, что данные правила действительно активны. Для этого вы можете использовать команду iptables -L -v -n для просмотра текущих правил. Если они отличаются от настроенных в файле /etc/sysconfig/iptables, примените конфигурацию с помощью iptables-restore.

2. Проверка на конфликтующие правила: Убедитесь, что нет других правил или политик, которые могут перезаписывать желаемые правила. Например, политика -A INPUT -j REJECT --reject-with icmp-host-prohibited должна быть ниже всех разрешающих правил.

3. Проверка заблокированных IP-адресов: Проверьте, чтобы IP-адреса, с которых клиенты пытаются подключиться, не попадали под блокировки:

-A INPUT -s 178.162.205.224/32 -j DROP

Если какие-либо потенциальные клиенты имеют эти IP, они будут автоматически заблокированы.

4. Логирование: Добавьте журналирование для входящих соединений с портами 3478 и 5349 для диагностики, добавив правило до REJECT:

-A INPUT -p tcp --dport 3478 -j LOG --log-prefix "STUN/TURN 3478 TCP: "
-A INPUT -p udp --dport 3478 -j LOG --log-prefix "STUN 3478 UDP: "
-A INPUT -p tcp --dport 5349 -j LOG --log-prefix "TURN 5349 TCP: "
-A INPUT -p udp --dport 5349 -j LOG --log-prefix "TURN 5349 UDP: "

5. Дополнительные порты: Иногда STUN и TURN серверы используют и другие порты. Убедитесь, что все необходимые порты и диапазоны открыты.

6. Другое ПО или сетевые устройства: Проверьте, не является ли проблема связанной с другим сетевым оборудованием (например, NAT или межсетевые экраны), которое может блокировать или ограничивать трафик на эти порты.

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