IPROUTE2 + 2 провайдера

[badfiles]

я хочу завернуть опоеделенный трафик на определеный gw. В последнем случае https трафик направить через другой gw.
Исходные данные в другой ветке, просто мы плавно переехали сюда, мой косяк.

Да, попробую половить пакеты с флагом RST, Спасибо за подсказку.
Скрипты все 100 раз опубликованы в этой ветке, просто цифры мои. Не думал, что скрипты более информативны,  чем выводы таблиц.

[fhieos]

badfiles, я бы посоветовал вспомнить главный критерий успеха - keep it simple.
Попробуйте максимально упростить правила файрволла, оставив *абсолютный* минимум.
В моем случае с 2-мя провайдерами я использую всего 1 доп.таблицу маршрутизации, несмотря на кучу howto, настаивающих на отдельной таблице для каждого интерфейса.
Пользователь решил продолжить мысль 15 Ноября 2009, 23:18:19:Вы это не находили?
https://help.ubuntu.com/community/InternetAndNetworking/DualHomedGatewayDHCP

[badfiles]

Ну да, я тоже думал сделать одну доп. таблицу, но неужели именно это является проблемой?
Пользователь решил продолжить мысль 15 Ноября 2009, 23:54:05:В мане по вашей ссылке не нашел ничего, чего не было бы в этой теме.

[Nesmit]

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

[fhieos]

Nesmit, я привел ссылку исключительно "для сведения".
Во-первых, ссылка в тему - в ней речь именно об Убунте.
Во-вторых, вариант минималистический и при этом, на мой взгляд, рабочий, хотя в описанной конфигурации не хватает настроек для полноценной работы (доступа извне) по любому из каналов как с самим шлюзом, так и с любой машиной внутри сети.

[badfiles]

Ничего необычного в моих конфах нет.

cat ipt

(Нажмите, чтобы показать/скрыть)

#!/bin/bash

iptables -t mangle --flush
iptables -t nat --flush

MARK="222"

iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 443 -j MARK --set-mark $MARK
iptables -t nat -A POSTROUTING -m mark --mark $MARK -j SNAT --to-source $1

exit 0

cat rt

(Нажмите, чтобы показать/скрыть)

#!/bin/sh

IP_INET1="172.22.22.22"
IP_INET2="$1"

IF_INET1="eth0"
IF_INET2="ppp0"

NET_INET1="172.22.22.0/24"
NET_INET2="10.64.64.64/32"

GW1="172.22.22.2"
GW2="10.64.64.64"

        ip route flush table T1         
        ip route flush table T2         

        ip rule delete table T1      
        ip rule delete table T2      
        ip rule delete table T1      
        ip rule delete table T2      

        ip route add $NET_INET1 dev $IF_INET1 src $IP_INET1 table T1
        ip route add $NET_INET2 dev $IF_INET2  src $IP_INET2 table T1   
        ip route add 127.0.0.0/8 dev lo   table T1         
        ip route add default via $GW1 dev $IF_INET1 table T1         

        ip route add $NET_INET1 dev $IF_INET1 src $IP_INET1 table T2   
        ip route add $NET_INET2 dev $IF_INET2  src $IP_INET2 table T2   
        ip route add 127.0.0.0/8 dev lo   table T2         
        ip route add default via $GW2 dev $IF_INET2 table T2          
      
        ip rule add from $IP_INET1 table T1
        ip rule add from $IP_INET2 table T2   

        ip rule add fwmark 111 table T1   
        ip rule add fwmark 222 table T2   

        ip route flush cache      

exit 0

Скрипты специальные, тестовые. Поскольку на боевом сервере маршрутизация по  этой схеме не заработала по причине невозможности получения обратного пакета, я решил проверить на клиенте, подключив второй канал (gprs). После подключения канала запускаются по очереди эти 2 скрипта с полученным от gprs ip в параметре и делается telnet на 443 порт сервера. Задача -- получить обратный пакет, вообще установить соединене через альтеративный шлюз.
Выводы скриптов я приводил, у меня только один главный вопрос, почему не устанавливается соединение?

ip route list table main

(Нажмите, чтобы показать/скрыть)

10.64.64.64 dev ppp0  proto kernel  scope link  src 172.19.106.144
172.22.22.0/24 dev eth0  proto kernel  scope link  src 172.22.22.22
default via 172.22.22.2 dev eth0

ip route list table T1

(Нажмите, чтобы показать/скрыть)

10.64.64.64 dev ppp0  scope link  src 172.19.106.144
172.22.22.0/24 dev eth0  scope link  src 172.22.22.22
127.0.0.0/8 dev lo  scope link
default via 172.22.22.2 dev eth0

ip route list table T2

(Нажмите, чтобы показать/скрыть)

10.64.64.64 dev ppp0  scope link  src 172.19.106.144
172.22.22.0/24 dev eth0  scope link  src 172.22.22.22
127.0.0.0/8 dev lo  scope link
default via 10.64.64.64 dev ppp0

ip rule list

(Нажмите, чтобы показать/скрыть)

0:   from all lookup local
32762:   from all fwmark 0xde lookup T2
32763:   from all fwmark 0x6f lookup T1
32764:   from 172.19.106.144 lookup T2
32765:   from 172.22.22.22 lookup T1
32766:   from all lookup main
32767:   from all lookup default

таблица mangle

(Нажмите, чтобы показать/скрыть)

Chain OUTPUT (policy ACCEPT 29379 packets, 1773K bytes)
 pkts bytes target     prot opt in     out     source               destination        
    9   540 MARK       tcp  --  any    any     anywhere             anywhere            tcp dpt:https MARK xset 0xde/0xffffffff

таблица nat

(Нажмите, чтобы показать/скрыть)

Chain POSTROUTING (policy ACCEPT 106 packets, 6440 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    5   300 SNAT       all  --  any    any     anywhere             anywhere            mark match 0xde to:172.19.106.144

все остальное в акцепт.


8   20.997404   172.19.106.144   94.25.208.252   TCP   39729 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=984384 TSER=0 WS=6
9   21.809393   94.25.208.252   172.19.106.144   TCP   https > 39729 [SYN, ACK] Seq=4164072487 Ack=1 Win=8190 Len=0 MSS=1380
и на этом финиш, все начинается с начала

Почему я не получаю обратный пакет, а?

PS.
Так выглядят пакеты, если поменять в схеме ТОЛЬКО дефолт роут в таблице main на 10.64.64.64

(Нажмите, чтобы показать/скрыть)

14   1722.582111   172.19.106.144   94.25.208.252   TCP   57112 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=1409780 TSER=0 WS=6
15   1723.141393   94.25.208.252   172.19.106.144   TCP   https > 57112 [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1380
16   1723.141426   172.19.106.144   94.25.208.252   TCP   57112 > https [ACK] Seq=1 Ack=1 Win=5840 Len=0
17   1762.553447   172.19.106.144   94.25.208.252   SSL   Continuation Data
18   1765.553405   172.19.106.144   94.25.208.252   SSL   [TCP Retransmission] Continuation Data
19   1766.121389   94.25.208.252   172.19.106.144   TCP   https > 57112 [RST] Seq=1 Win=9838 Len=0

[Nesmit]

Вообщем все так же. Кроме этих строк заполняющих main таблицу. Не знаю делают ли они погоду.

Код: [Выделить]

ip route add $NET_INET1 dev $IF_INET1 src $IP_INET1      #заполняем основную таблицу адресов. сеть на первого провайдера
ip route add $NET_INET2 dev $IF_INET2 src $IP_INET2      #заполняем основную таблицу адресов. сеть на второго провайдераПравда проверял по 80 порту, так проще было определить с какого ip вышел в инет.
А если маскарадить интерфейс ppp?

И потом. ты метишь на ВЫХОДЕ. iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 443 -j MARK --set-mark $MARK
а где то в середине, ищешь метку iptables -t nat -A POSTROUTING -m mark --mark $MARK -j SNAT --to-source $1
Ясен перец метки еще несуществует, а ты уже натишь.

Вот мой вариант 100% рабочий.

Код: [Выделить]

iptables -t nat -A POSTROUTING -s 192.168.161.0/24 -p tcp --dport 80 -j SNAT --to-source 192.168.3.8
iptables -t mangle -A PREROUTING -s 192.168.161.0/24 -p tcp --dport 80 -j MARK --set-mark 12можешь тупо убрать  -s 192.168.161.0/24 и применить.
Пользователь решил продолжить мысль 16 Ноября 2009, 09:56:07:вообще непонятно откуда ты взял OUTPUT.
http://www.opennet.ru/docs/RUS/iptables/#MARKTARGET

[badfiles]

Nesmit, мне кажется, ты неправ. Во первых, задача маршрутизации транзитных пакетов через другой gw более не стоит, поскольку на боевом сервере обламывается с тем же результатом -- отсутствие обратного пакета на нужный интерфейс. Поэтому я теперь пытаюсь разобраться с локальными пакетами на максимально свободной от всего лишнего конфигурации. Правила iptables для такой задачи работают оба, что подтверждает tcpdump. (смотри пост с выводом таблиц).

Маскарадить я тоже пробовал, результат тот же.

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


Пользователь решил продолжить мысль 16 Ноября 2009, 06:58:47:Есть подозрение, что я неосмотрительно проигнорировал заполнение таблицы main, поскольку там уже есть эти записи. Щас попробую организовать транзит.
Пользователь решил продолжить мысль 16 Ноября 2009, 09:09:28:Как и следовало ожидать, добавление в таблицу main существующих там маршрутов ни к чему не привело.

RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists

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

Пользователь решил продолжить мысль 16 Ноября 2009, 12:42:38:А не БАГ ли это?

[Nesmit]

Nesmit, мне кажется, ты неправ. Во первых, задача маршрутизации транзитных пакетов через другой gw более не стоит, поскольку на боевом сервере обламывается с тем же результатом -- отсутствие обратного пакета на нужный интерфейс. Поэтому я теперь пытаюсь разобраться с локальными пакетами на максимально свободной от всего лишнего конфигурации. Правила iptables для такой задачи работают оба, что подтверждает tcpdump. (смотри пост с выводом таблиц).

Возможно. Но мне непонятно почему ты метку ставишь на выходе?
Почему тогда в моем случае все работает как часы? Если правило меток слизал из man'ов по iptables.
Вот схема прохождения пакета.

Код: [Выделить]

iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 443 -j MARK --set-mark $MARK
iptables -t nat -A POSTROUTING -m mark --mark $MARK -j SNAT --to-source $1
Видишь, по схеме твой пакет метится ПОСЛЕ того как производится маршрутизация. Я не прав? так каким боком он должен идти по твоему gw2? Т.е. в твоем случае получается. Что пакету дают маршрут по умолчанию, потом ты его метишь и следом натишь. На выходе ты получаешь что пакет пошел по не тому интерфейсу и не стем ip адресом. Логично что он дохнет. Его GW1 провайдера не пустит.

RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists

Это говорит о том что маршрут не принят по причине уже существующего. Можно предварительно убить то что по умолчанию и создать уже по своему. Во втором варианте так и поступил.

[badfiles]

По поводу схемы прошу сюда https://forum.ubuntu.ru/index.php?topic=74275

Маршруты пробовал убить и вписать свои -- не помогло.

Еще раз тонко намекаю на то, что не работает у меня и ваш вариант для транзитного пакета по той же причине.
Какое в вас ядро?

[Nesmit]

8.04.3 обновленная
Почему не работает, если у меня работает?

[badfiles]

Поэтому и спросил.
Думаю, что у меня не работает, потому что это баг последнего ядра. У меня просто нет больше вариантов.

[fhieos]

badfiles, давайте определимся, для кого Вы routing decision настраиваете:
1. только для самой машины-шлюза с двумя линками и ее локальных процессов
2. только для клиентов в лок сети шлющих машине-шлюзу пакеты
3. первое и второе

Вы привели конфиги для варианта 1. по моему мнению.
Кстати можно было бы уже давно разобрать полный вывод tcpdump - Вы делали или нет?

[badfiles]

Сначала задача стояла 1+2=3, но поскольку она натолкнулась наполный разброд как теории, так и практических реализаций, то я решил сделать на кленте с gprs модемом хотябы 1, а на боевом сервере хотябы 2. С одинаковым результатом.

Сейчас как раз колдую с tcpdump.

[fhieos]

И еще
что именно делает вот это правило

Код: [Выделить]

iptables -t nat -A POSTROUTING -m mark --mark $MARK -j SNAT --to-source $1и вот это

Код: [Выделить]

ip rule add fwmark 111 table T1 если это не опечатка (111 != 1), то явная попытка сделать одно и то же одновременно 2-мя способами
Если опечатка, то "SNAT --to-source $1" просто никогда не должно работать, т.к. метка "1" нигде не ставится