[Comm] У кого нибудь работает ip_conntrack_sip ip_nat_sip

Сб Ноя 17 22:49:21 MSK 2012

On Sat, Nov 17, 2012 at 12:06:34PM +0400, altconf на gmail.com wrote:
> Есть
> ALT Linux 6.0.0 Centaurus  (Cheiron)
> Linux srv.localdomain 2.6.32-el-smp-alt27 #1 SMP Tue Sep 20 19:35:51 UTC 
> 2011 i686 GNU/Linux
> Есть sip провайдер к которому ципляюсь из локальной сети sip телефоны.
> Сейчас разрешен трафик по UDP для определенных локальных IP адресов, но 
> хотелось бы сделать по правильному.
> 
> В iptables прописал строки как здесь написано
> http://wiki.sipfoundry.org/display/sipXecs/Configure+iptables

К сожалению, команды для загрузки модулей на этой странице
неправильные - возможно, поэтому ничего и не работает.

> modprobe ip_conntrack_sip ip_nat_sip

В одном вызове modprobe может быть указано только одно имя модуля, за
которым следуют параметры этого модуля; в том виде, как это написано
здесь, modprobe попытается загрузить модуль ip_conntrack_sip с
параметром ip_nat_sip, и в результате будет получена ошибка из-за
неизвестного параметра, модуль при этом не будет загружен.

К тому же имена модулей устарели - теперь эти модули называются
nf_conntrack_sip и nf_nat_sip (впрочем, старые имена ещё можно
использовать в вызовах modprobe из-за встроенных алиасов).

> modprobe ip_conntrack_sip ports=5060

Эта команда сработает, только следует учитывать, что в случае, если
модуль по каким-то причинам уже оказался загружен ранее, указанные в
командной строке параметры будут проигнорированы.  Обычно лучше
помещать параметры для модулей в файлы /etc/modprobe.d/*.conf (лучше
не редактировать существующие файлы, а добавить новый файл, чтобы не
пришлось потом вносить изменения после обновления пакета, добавившего
туда изменённый впоследствии файл):

  options nf_conntrack_sip ports=5060

Параметры из /etc/modprobe.d/*.conf будут применены как при загрузке
модуля явной командой modprobe nf_conntrack_sip, так и при неявной
загрузке для удовлетворения зависимостей других модулей (например, при
выполнении команды modprobe nf_nat_sip по зависимостям будет загружен
и модуль nf_conntrack_sip).

Впрочем, значение ports=5060 можно не указывать вообще - этот порт
используется по умолчанию, если параметр модуля не указан.

А вот модуль nf_nat_sip после выполнения только указанных команд
загружен не будет.  В принципе достаточно загрузить только этот
модуль, хотя от ручной загрузки nf_conntrack_sip ничего плохого тоже
не случится:

  modprobe nf_conntrack_sip
  modprobe nf_nat_sip

> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Это правило разрешает только ответные пакеты для трафика,
инициированного самим шлюзом, но не влияет на передачу пакетов между
маршрутизируемыми сетями (несмотря на то, что на внешнем интерфейсе
благодаря использованию NAT оба вида пакетов имеют одинаковый IP-адрес
назначения).  Вообще в таблице filter весь трафик виден уже со снятым
NAT (обработка пакетов в том виде, как они вошли в интерфейс, возможна
в таблице raw):

  http://en.wikipedia.org/wiki/File:Netfilter-packet-flow.svg

(трансляция адресов для входящих пакетов, относящихся к уже известным
соединениям, выполняется на этапе "conntrack"; через таблицу nat
проходят только первые пакеты устанавливаемых соединений).  Хотя эта
схема тоже не совсем полная...

Для разрешения передачи ответного трафика во внутреннюю сеть
аналогичное правило должно быть добавлено в таблицу FORWARD (обычно
для повышения производительности его ставят одним из первых, хотя
перед ним могут размещаться правила для учёта трафика):

  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

А вот в начало цепочки INPUT хорошо бы добавить явное отбрасывание
пакетов со статусом INVALID:

  iptables -A INPUT -m state --state INVALID -j DROP

Пакеты со статусом INVALID могут появляться в случае, если для них по
каким-то причинам не сработал conntrack; в результате они начинают
обрабатываться шлюзом как предназначенные для самого шлюза, что может
вызывать загадочные проблемы - например, такие:

  http://serverfault.com/questions/309691/why-is-our-firewall-ubuntu-8-04-rejecting-the-final-packet-fin-ack-psh-wit/

> iptables -A INPUT -p udp --dport 5060 -j ACCEPT

Это правило нужно только в том случае, если на самом шлюзе запущен
какой-либо сервер, принимающий UDP-пакеты на порт 5060.  Если
требуется только обмен с серверами во внешней сети, достаточно правил
в таблице FORWARD.

> iptables -A FORWARD -p udp --dport 5060 -j ACCEPT

Это правило, вероятнее всего, слишком широкое - необходимо проверять,
что пакет пришёл с одного из интерфейсов, соответствующих внутренней
сети, иначе, несмотря на использование NAT, кто-либо из того же
сегмента внешней сети (до следующего маршрутизатора) сможет передавать
такие пакеты во внутреннюю сеть, если ему известен диапазон адресов
внутренней сети и пакеты с такими адресами не фильтруются
коммутаторами внешнего сегмента, либо установить внешний IP вашего
шлюза себе в качестве шлюза по умолчанию и выходить в Internet через
ваш внешний IP (это правило даст доступ к SIP-серверам; возможно, есть
и другие написанные столь же неаккуратно правила).

Обычно проще всего создать несколько цепочек по входному интерфейсу:

  iptables -N forward_lan
  iptables -N forward_wan
  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -A FORWARD -m state --state INVALID -j DROP
  iptables -A FORWARD -i eth0 -j forward_wan
  iptables -A FORWARD -i eth1 -j forward_lan
  iptables -A FORWARD -j REJECT

а затем добавлять правила для разрешения соединений уже в цепочки для
конкретного источника:

  iptables -A forward_lan -o eth1 -j ACCEPT
  iptables -A forward_lan -p udp --dport 5060 -j ACCEPT

Первое правило, разрешающее прохождение пакетов из LAN обратно в LAN,
может быть нужно для NAT loopback - в ситуации, когда из внутренней
сети происходит обращение к внешнему IP-адресу шлюза, которое на самом
деле через DNAT перенаправляется на один из внутренних адресов;
учтите, что в этом случае на шлюзе придётся делать ещё и SNAT, и
сервер увидит вместо адреса клиента во внутренней сети адрес шлюза;
чтобы избежать этого, придётся выносить подобные сервера в отдельную
сеть (DMZ).

> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source $EXTERNAL_ADDRESS

Это в принципе правильно (более тонкую фильтрацию в таблице nat
проводить не нужно, для этого есть таблица filter).
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 198 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/community/attachments/20121117/26917376/attachment.bin>