Платежные системы. Не проходят платежи.

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (2)

просмотр истории страницы
Был пропущен порт, указанный в [основных настройках платежных систем|CarbonBilling:Основные настройки платежных систем]

h3. Возможно трафик блокирует rp_filter

Если прочие пункты инструкции Вы проверили и всё в порядке, возможно проблема в rp_filter.
попробуйте поправить настройку rp_filter на интерфейсе, куда приходит трафик от платёжной системы.

Допустим, это интерфейс eth0:

# Выполните следующую команду
{code}sysctl -w net.ipv4.conf.eth0.rp_filter=2{code}
# Попробуте повторить платёж

Если это решило проблему, добавьте настройку в {{/etc/sysctl.conf}}, чтобы она сохранилась при перезагрузках
{code}
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Для платёжных систем
net.ipv4.conf.eth0.rp_filter = 2
{code}

{note}{{rp_filter=2}} пропустит трафик, если хотя бы один интерфейс может ответить. Этого должно хватить. Если не поможет - можно совсем отключить  rp_filter: {{rp_filter=0}}{note}
{info}Проверить это можно добавив отладочные правила -j LOG в iptables для конкретного IP: одно в таблицу nat, цепочка asr_fiscal_preroutering, другое в таблицу mangle, цепочка INPUT. Если в nat/asr_fiscal_preroutering трафик попадает, а в mangle/INPUT уже нет - проблема в rp_filter.{info}
h1. Возможно запросы не проходят firewall

!port443.png|border=1!


h3. Возможно трафик блокирует rp_filter

Если прочие пункты инструкции Вы проверили и всё в порядке, возможно проблема в rp_filter.
Убедитесь, что ответ маршрут к IP платёжной системе ведёт через тот же интерфейс, на который она обращается.
Проверить это можнотак:
# С tcpdump посмотрите, на какой интерфейс приходит пакет
# Посмотрите, как пойдёт ответ с помощью {{ip r g to <IP>}}, где вместо <IP> подставьте адрес платёжки.
Интерфейсы должны совпадать.

Так же Вы можете включить логирование "марсианских" пакетов - такими ядро Linux считает пакеты, у которых трафик по scr адресу ожидается на другом интерфейсе
{code}echo 1 > /proc/sys/net/ipv4/conf/all/log_martians{code}
Пример, как диагностировать по логу:
{code}
# пришедший пакет в логе
[root@CarbonBillingServer ~]# tail -f /var/log/messages
May 23 16:43:42 CarbonBillingServer kernel: martian source 169.254.14.43 from 88.85.210.133, on dev eth0
May 23 16:43:42 CarbonBillingServer kernel: ll header: 0c:c4:7a:e5:a8:56:10:f3:11:14:a3:4a:08:00

# проверка маршрута к адресу источника пакета
[root@CarbonBillingServer ~]# ip r g to 88.85.210.133
88.85.210.133 via 172.22.0.1 dev eth1 src 172.22.0.222
cache mtu 1500 hoplimit 64
{code}
Видно, что пакет к адресу платёжных систем 169.254.14.43 пришел с адреса 88.85.210.133 на интерфейс eth0

h4. Как исправить

# Добавьте маршрут к адресу источника через нужный интерфейс. Для интерфейса eth0 это будет файл {{/etc/sysconfig/network-scripts/route-eth0}}
На лету это можно сделать отдельной командой:
{code}ip r add 88.85.210.133 via <GATEWAY_IP> dev eth0{code}
Где вместо <GATEWAY_IP> укажите IP шлюза на этом интерфейсе.
При этом в файл сохранить маршрут тоже нужно.
# Если у Вас нет возможность добавить маршрут, моэете настроить менее жесткую проверку rp_filter на интерфейсе, откуда куда приходит трафик от платёжной системы, или совсем его отключить.
Допустим, это интерфейс eth0, тогда выполните следующую команду
{code}sysctl -w net.ipv4.conf.eth0.rp_filter=2{code}
И попробуте повторить платёж.
Если это решило проблему, добавьте настройку в {{/etc/sysctl.conf}}, чтобы она сохранилась при перезагрузках
{code}
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Для платёжных систем
net.ipv4.conf.eth0.rp_filter = 2
{code}
{note}{{rp_filter=2}} пропустит трафик, если хотя бы один интерфейс может ответить. Этого должно хватить. Если не поможет - можно совсем отключить  rp_filter: {{rp_filter=0}}{note}


h2. Проверка логов платежной системы