Я использую прокси-сервер SIP, который должен иметь возможность перенаправлять весь трафик RTP между двумя клиентами, которые не могут связаться друг с другом. Чтобы реализовать это, я решил манипулировать согласованными адресами в сообщениях SIP / SDP и использовать правила iptables для перенаправления трафика RTP.
Проблема возникает, если источник, отправляющий пакеты RTP, изменяется. В этом случае iptables требуется 30 секунд, чтобы начать перенаправление трафика из нового источника.
Чтобы подробно объяснить, что я пытаюсь сделать, предположим, что у меня есть два SIP-клиента и мой прокси:
Боб вызывает Алису, сообщая в ее сообщении SIP / SDP, что он будет прослушивать трафик RTP по адресу 192.168.1.1:8000. Затем прокси изменяет этот адрес на 192.168.3.1:15000 и пересылает новое сообщение SIP / SDP Алисе. Теперь весь RTP-трафик от Алисы будет отправлен на прокси. Чтобы перенаправить этот трафик обратно Бобу, прокси-сервер добавляет в iptables следующие правила:
iptables -t nat -A OUTPUT -d 192.168.3.1 -p UDP --dport 15000 -j DNAT --to 192.168.1.1:8000
iptables -t nat -A PREROUTING -d 192.168.3.1 -p UDP --dport 15000 -j DNAT --to 192.168.1.1:8000
iptables -t nat -A POSTROUTING -d 192.168.1.1 -p UDP --dport 8000 -j SNAT --to 192.168.3.1:15000
Теперь предположим, что исходный поток RTP изменился. По какой-то причине теперь машина, на которой работает прокси, генерирует трафик RTP вместо Алисы.
Правила iptables изменять не нужно. Iptables должен иметь возможность перенаправлять этот новый трафик RTP, используя правило OUTPUT, указанное выше. Но для того, чтобы iptables начал перенаправлять трафик Бобу, требуется 30 секунд.
После некоторого исследования я обнаружил, что эта проблема может быть вызвана таблицей conntrack, которая должна дождаться истечения срока действия своей записи «Алиса-> Боб», прежде чем добавить новую запись «Прокси-> Боб». И я мог подтвердить это, когда посмотрел на / proc / net / ip_conntrack.
В моих правилах не указывается источник, потому что он у меня не всегда есть, и он может динамически меняться, не сообщая прокси. Итак, я не могу удалить записи conntrack вручную с помощью conntrack-tools, как я читал в других сообщениях.
Есть идеи, как решить эту проблему?
NAT'ing SIP + RTP - непростая задача. (вдвойне, когда меняются IP-адреса источника / назначения) Необходимо настроить гораздо больше, чем просто адрес источника и назначения. В самом фактическом сеансе SIP есть биты, которые также необходимо изменить (что и делает модуль conntrack). SIP используется для согласования источника и назначения, к которым должен подключиться каждый одноранговый узел для обмена данными RTP. Поскольку весь трафик является UDP (без соединения), модуль conntrack должен дождаться тайм-аута или завершения вызова, прежде чем соединение будет считаться мертвым и удалено из таблицы.
Чтобы решить вашу проблему, вам нужен правильный sip-прокси ... не iptables. В этом случае телефоны будут подключаться к прокси, прокси будет подключаться к прокси удаленного узла, а удаленный прокси будет подключаться к удаленному узлу. В этом примере будет 3 отдельных подключения, и если у одного из маршрутизаторов есть изменение IP, он просто повторно приглашает удаленный прокси-сервер, и соединение восстанавливается. Вам также больше не потребуется iptables для искажения пакетов.