LINUX.ORG.RU
ФорумAdmin

два канала и ICQ


0

0

Есть два канала. В нормальном режиме использубтся оба. Основной - для всего основного трафика, а на резервный всякие мелочи повешены типа vpn, rdp... Нагрузка на последний небольшая. Вот. Если рубится основной канал, то просто переключается дефолтовый шлюз по типу:

ip route add default via $P2

ip route flush cache

Ну, это так, главное. Но при таком раскладе перестаёт работать аська (наверно и с внешним джаббером тоже кердык, но пока проверить не могу). Причём, это как-то странно происходит - аська коннектится, всё как бы хорошо, но сообщения не приходят, не отсылаются (хотя последнее под вопросом).

Каких-то особых правил для IM нет ни у iptables'a, ни у ip route'a. Всё остальное работает, разницы нет. Может кто сталкивался, подскажет в какую сторону копать?

Ах да, tcptraceroute login.oscar.aol.com 5190 проходит в таком режиме:

12 dar2-dtc-s3-1-0.atdn.net (66.185.152.115) 197.279 ms 198.321 ms 197.580 ms
13 ow2-dtc-gx-x.net.aol.com (66.185.135.166) 312.570 ms 288.445 ms 246.923 ms
14 * * *
15 ibucp-vip-d.blue.aol.com (205.188.179.233) [open] 313.439 ms 279.779 ms 326.282 ms

в общем, соединение проходит, но сообщения...

★★★★★

в общем, если с внутреннего джаббера писать на внешний, сообщения приходят. Но если отвечать на них, то ответы просто теряются где-то :(

И фтп... если заливать на внешний фтп файл, то после некоторого тупления заливаетсяфайл "нулевой длины" :(

Команда: LIST
Ответ: 150 Here comes the directory listing.
Ответ: 226 Directory send OK.
Команда: PASV
Ответ: 227 Entering Passive Mode (**,**,**,**,160,40).
Команда: STOR x20.jpg
Ответ: 150 Ok to send data.
Ошибка: Превышено время ожидания соединения
Ответ: 421 Timeout.
Ошибка: Соединение закрыто сервером

vovans ★★★★★
() автор топика
Ответ на: комментарий от vovans

при смене маршрута помимо чистки кеша роутинга, чисть conntrack

либо командой conntrack -F

либо удаляя и возврящая модуль ядра и правила iptables

(все это справедливо если у тебя есть NAT)

zhiltsov
()

при изменении роутов рвуться tcp-сессии т.к. твой внешний ип меняется. Поэтому надо принудительно рвать все соединения типа отправкой rst или icmp-шки хостам чтобы они знали что соединение порвалось. По типу того как работает китайский фаервол.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

И как же его принудительно рвать? Кстати, фтп-клиентом я подключаюсь уже после переключения на другой IP.....

vovans ★★★★★
() автор топика
Ответ на: комментарий от zhiltsov

# sysctl net.ipv4.route.flush=1
net.ipv4.route.flush = 1

# sysctl net.ipv4.route.flush=1
net.ipv4.route.flush = 1

# conntrack -F
Operation failed: invalid parameters

vovans ★★★★★
() автор топика
Ответ на: комментарий от vovans

ой, точнее ещё это:

# sysctl -a | grep execve
error: permission denied on key 'net.ipv4.route.flush'

vovans ★★★★★
() автор топика

Я создал ещё две таблицы и управляю с помощью iptables:
iptables -t mangle -A PREROUTING -s 192.168.1.51 -i eth3 -j MARK --set-mark 100

для теста только что поменял:
iptables -t mangle -R PREROUTING -s 192.168.1.51 -i eth3 -j MARK --set-mark 101

две минуты и icq пошло по второму каналу.

SlavikSS ★★
()
Ответ на: комментарий от vovans

echo "200 table1" >> /etc/iproute2/rt_tables
echo "201 table2" >> /etc/iproute2/rt_tables

ip rule add from 192.168.1.0/24 fwmark 100 lookup table1
ip rule add from 192.168.1.0/24 fwmark 101 lookup table2
ip rule add from 192.168.2.1 lookup table1
ip rule add from 192.168.3.1 lookup table2

ip route add default via 192.168.2.2 table table1
ip route add default via 192.168.3.2 table table2

iptables -t mangle -A PREROUTING -s 192.168.1.30 ! -d 192.168.1.100 -i $INDEV0 -j MARK --set-mark 100
iptables -t mangle -A PREROUTING -s 192.168.1.50 ! -d 192.168.1.100 -i $INDEV0 -j MARK --set-mark 102
iptables -t mangle -A PREROUTING -s 192.168.1.51 ! -d 192.168.1.100 -i $INDEV0 -j MARK --set-mark 101
iptables -t mangle -A PREROUTING -s 192.168.1.52 ! -d 192.168.1.100 -i $INDEV0 -j MARK --set-mark 102

Пакеты помечаемые --set-mark 102 будут попадать в основную таблицу маршрутизации.

SlavikSS ★★
()

таки интересно было бы узнать, почему у меня не работает `conntrack -F` и как принудительно все сессии обрывать? :(

vovans ★★★★★
() автор топика
Ответ на: комментарий от vovans

Много лет я искал тулзу чтобы убивать соединения и, наконец, нашёл :) tcpkill из пакета dsniff. Тока эта зараза не выходит после прибития соединения а остаётся висеть и дальше снифать трафик.

Был так же cutter, но он не работает на современных ядрах.

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.