forum.opennet.ru - "мистика с маршрутизацией" (22)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"мистика с маршрутизацией"

Форумы OpenNET: Виртуальная конференция (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"мистика с маршрутизацией"		+/–
Сообщение от deadlock (ok) on 06-Июл-09, 23:26
есть вот такая сеть http://pic.ipicture.ru/uploads/090706/st2rFfmQOW.png дубль: http://pic4.ru/images/d3ceb2b80655675de2b87e7b61e6dcea.png проблема состоит в следующем с клиентской машины внутренние пакеты ходят по всей сети вообще без проблем тоесть с клиентской машины (10.9.0.6) могу пинговать сервер B (10.3.0.1) и всё пингуется так же как и с сервера B пингуется клиентская машина мистика начинается когда с клиента пытаюсь пинговать чтото внешнее пакет доходит до сервера B, там отлично идет до нужной цели и возвращается на B, идет на А и вот тут самое интересное, он доходит только до tun5 и теряется, на tun0 он не попадает (хотя в таблице main маршрут нужный есть), соответственно к клиенту тоже не попадает :( тоесть при пинге чегото внешнего вот такое наблюдаю на tun5 (A, B) одинаково listening on tun5, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 13:46:31.511369 IP 10.9.0.6 > gw-in-f100.google.com: ICMP echo request, id 1536, seq 13353, length 40 13:46:31.623199 IP gw-in-f100.google.com > 10.9.0.6: ICMP echo reply, id 1536, seq 13353, length 40 на tun0 (A) listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 17:48:25.880952 IP 10.9.0.6 > gw-in-f100.google.com: ICMP echo request, id 1536, seq 13609, length 40 ================= Server A ================================ ip rule show: 0: from all lookup 255 32765: from all fwmark 0x41 lookup vpn 32766: from all lookup main 32767: from all lookup default ip route show table vpn: default via 10.3.0.1 dev tun5 ip route show table main: 10.3.0.1 dev tun5 proto kernel scope link src 10.3.0.2 10.9.0.2 dev tun0 proto kernel scope link src 10.9.0.1 10.9.0.0/24 via 10.9.0.2 dev tun0 192.0.2.0/24 dev venet0 scope host 169.254.0.0/16 dev venet0 scope link default via 192.0.2.1 dev venet0 iptables -L -t mangle Chain PREROUTING (policy ACCEPT) target prot opt source destination MARK all -- 10.9.0.0/24 anywhere MARK set 0x41 ================= Server B ================================ iptables -L -t nat Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 10.9.0.0/24 anywhere ip route show: 10.9.0.0/24 via 10.3.0.2 dev tun5 почему такое происходит ? у меня идеи уже совсем закончилиcь ;( мистика да и только...
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

мистика с маршрутизацией, shadow_alone, 02:08 , 07-Июл-09, (1)

мистика с маршрутизацией, deadlock, 03:02 , 07-Июл-09, (2)

мистика с маршрутизацией, shadow_alone, 03:08 , 07-Июл-09, (3)

мистика с маршрутизацией, deadlock, 04:55 , 07-Июл-09, (4)

мистика с маршрутизацией, shadow_alone, 08:26 , 07-Июл-09, (5)

мистика с маршрутизацией, deadlock, 18:49 , 07-Июл-09, (6)

мистика с маршрутизацией, ALex_hha, 19:53 , 07-Июл-09, (7)

мистика с маршрутизацией, deadlock, 19:06 , 08-Июл-09, (8)

мистика с маршрутизацией, ALex_hha, 19:21 , 08-Июл-09, (9)

мистика с маршрутизацией, deadlock, 19:29 , 08-Июл-09, (10)

мистика с маршрутизацией, shadow_alone, 19:41 , 08-Июл-09, (11)

мистика с маршрутизацией, deadlock, 19:48 , 08-Июл-09, (12)

мистика с маршрутизацией, reader, 20:45 , 08-Июл-09, (13)

мистика с маршрутизацией, deadlock, 21:01 , 08-Июл-09, (14)

мистика с маршрутизацией, reader, 21:45 , 08-Июл-09, (15)

мистика с маршрутизацией, deadlock, 22:33 , 08-Июл-09, (16)

мистика с маршрутизацией, reader, 23:03 , 08-Июл-09, (17)

мистика с маршрутизацией, deadlock, 02:49 , 09-Июл-09, (18)
мистика с маршрутизацией, deadlock, 05:43 , 09-Июл-09, (19)
мистика с маршрутизацией, shadow_alone, 05:50 , 09-Июл-09, (20)
мистика с маршрутизацией, deadlock, 07:27 , 09-Июл-09, (21)
мистика с маршрутизацией, ALex_hha, 13:33 , 09-Июл-09, (22)

Сообщения по теме [Сортировка по времени | RSS]

1. "мистика с маршрутизацией" +/–

Сообщение от shadow_alone (ok) on 07-Июл-09, 02:08

а не пробывали  Destination тож маркировать?
-d 10.9.0.0/24 -j MARK  etc
Я не сильно уверен, сильно не вник, бегло прошелся по схеме.
уверен, не в этом дело.

и непонятно еще , зачем маршрут на всю сеть 10.9.0.0/24 via 10.9.0.2 dev tun0 , если для каждого клиента свой туннель поднимается.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 07-Июл-09, 03:02

>а не пробывали  Destination тож маркировать?
>-d 10.9.0.0/24 -j MARK  etc
пробовал сделать так, вторую таблицу сделал и в ней
ip rule add fwmark 60 table vpn2
ip route add default via 10.9.0.2 dev tun0 table vpn2
iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -i tun5 -j MARK --set-mark 60
не помогло...
>Я не сильно уверен, сильно не вник, бегло прошелся по схеме.
>уверен, не в этом дело.
>
>и непонятно еще , зачем маршрут на всю сеть 10.9.0.0/24 via 10.9.0.2
>dev tun0 , если для каждого клиента свой туннель поднимается.
это маршрут дефолтный создает openvpn демон
он же не для каждого юзера свой tun девайс создает, он у него всего один, вот тот, что на схеме нарисован, а демон я так понимаю сам рнутри себя всё от юзеров роутит на этот единственный tun0

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "мистика с маршрутизацией" +/–

Сообщение от shadow_alone (ok) on 07-Июл-09, 03:08

ну с туннелью понятно - допустим она одна на всех,
но почему же 10.9.0.0/24 via 10.9.0.2 , вот это не понять никак., тогда уж via dev tun0, без 10.9.0.2
попробуйте убрать в опенвпн, чтоб не создавал маршрут, или удалите после создания и создайте свой.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 07-Июл-09, 04:55

>ну с туннелью понятно - допустим она одна на всех,
>но почему же 10.9.0.0/24 via 10.9.0.2 , вот это не понять никак.,
>тогда уж via dev tun0, без 10.9.0.2
>
>попробуйте убрать в опенвпн, чтоб не создавал маршрут, или удалите после создания
>и создайте свой.
не совсем понимаю как так может быть, маршрут без указания IP :)
девайс там как раз присутствует
маршрут то выглядит так если руками прописывать
ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0
тоесть тут всё гуд как раз
мне кажется копать надо кудато, из за чего могут нормально роутится внутренние IP и не роутится внешние
я честно говоря не настолько хорошо знаю тонкости роутинга в линухах, чтоб знать такие вещи, что может влиять на такое поведение роутинга
уже какие то глюки в работе с сетью openvz или openvpn в голову лезут :(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "мистика с маршрутизацией" +/–

Сообщение от shadow_alone (ok) on 07-Июл-09, 08:26

>
>не совсем понимаю как так может быть, маршрут без указания IP :)
ну например ipip  тоесть, есть одна сторона и есть другая, никогда не пробовали на тунеле в циско ip unnumbered?
ну это так, к слову.
>
>девайс там как раз присутствует
>маршрут то выглядит так если руками прописывать
>
>ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0
>тоесть тут всё гуд как раз
А помоему копать надо именно тут. Как вы себе представляете такое:
ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0 # первый клиент
ip route add 10.9.0.0/24 via 10.9.0.4 dev tun0 # второй клиент
и т.д.
?????????????????????
>
>мне кажется копать надо кудато, из за чего могут нормально роутится внутренние
>IP и не роутится внешние
Еще смущает последний маскарадинг. Я правда никогда не пытался так делать, но кажется странным, вы ж должны свою сеть маскарадить, вот поэтому imho, он и не доходит.
Попробуйте на сервере А тож маскарадинг, а если надо и рутить, то !маскарадить только в свои сети.

>я честно говоря не настолько хорошо знаю тонкости роутинга в линухах, чтоб
>знать такие вещи, что может влиять на такое поведение роутинга
>уже какие то глюки в работе с сетью openvz или openvpn в
>голову лезут :(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 07-Июл-09, 18:49

>[оверквотинг удален]
>>маршрут то выглядит так если руками прописывать
>>
>>ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0
>>тоесть тут всё гуд как раз
>
>А помоему копать надо именно тут. Как вы себе представляете такое:
>ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0 # первый клиент
>ip route add 10.9.0.0/24 via 10.9.0.4 dev tun0 # второй клиент
>и т.д.
>?????????????????????
на сервере всегда прописан только один маршрут, сколько бы клиентов не законнектилось на впн
10.9.0.0/24 via 10.9.0.2
всё остальное, я так понимаю, впн сервер сам разруливает внутри себя
тоесть то, что на картинке у меня у клиента IP 10.9.0.6 gw 10.9.0.5 это реальная ситуация, гейт с IP 10.9.0.5 на сервере нигде не прописан, он ток внутри впн демона фигурирует и роутится внутри
на сервере висит только tun0 с одним IP и одним маршрутом всегда
>>мне кажется копать надо кудато, из за чего могут нормально роутится внутренние
>>IP и не роутится внешние
>
>Еще смущает последний маскарадинг. Я правда никогда не пытался так делать, но
>кажется странным, вы ж должны свою сеть маскарадить, вот поэтому imho,
>он и не доходит.
>Попробуйте на сервере А тож маскарадинг, а если надо и рутить, то
>!маскарадить только в свои сети.
с маскарадингом всё ОК
даже судя по тому что пакеты с сервера А нормально ходят на сервер B и оттуда на удаленные хосты и возвращаются обратно на A через B с верными src и dst адресами
на А маскарадинг я пробовал поднимать, но толи не так чтото сделал, толи он просто не нужен там (к чему я больше склоняюсь, так как смысла не вижу в нем на А)... вообщем лучше не стало
былоб интересно отследить по каким то логам что пытается сделать система с пришедшим на tun5 (A) пакетом, но я не знаю где это можно увидеть, на tcpdump вижу только наличие пакетов, но этой инфы маловато чтоб понять всё
>>я честно говоря не настолько хорошо знаю тонкости роутинга в линухах, чтоб
>>знать такие вещи, что может влиять на такое поведение роутинга
>>уже какие то глюки в работе с сетью openvz или openvpn в
>>голову лезут :(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "мистика с маршрутизацией" +/–

Сообщение от ALex_hha (ok) on 07-Июл-09, 19:53

Мне кажется на сервере А надо явно задать маршрут для подсети 10.9.0.0/24 через отдельную таблицу
что то типа
# ip route add default via 10.9.0.2 dev tun0 table VPN2
# ip rule add fwmark 64 table VPN2
# iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -j MARK --set-mark 64
> пробовал сделать так, вторую таблицу сделал и в ней
> ip rule add fwmark 60 table vpn2
> ip route add default via 10.9.0.2 dev tun0 table vpn2
> iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -i tun5 -j MARK --set-mark 60
разве здесь не -o tun5 должно быть вместо -i tun5 ? Ведь через tun5 пакет исходит. Если я правильно понял рисунок сети

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 08-Июл-09, 19:06

>Мне кажется на сервере А надо явно задать маршрут для подсети 10.9.0.0/24
>через отдельную таблицу
>
>что то типа
>
># ip route add default via 10.9.0.2 dev tun0 table VPN2
># ip rule add fwmark 64 table VPN2
># iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -j MARK --set-mark 64
так я ведь это и пробовал, только с указанием интерфейса
>> пробовал сделать так, вторую таблицу сделал и в ней
>> ip rule add fwmark 60 table vpn2
>> ip route add default via 10.9.0.2 dev tun0 table vpn2
>> iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -i tun5 -j MARK --set-mark 60
>
>разве здесь не -o tun5 должно быть вместо -i tun5 ? Ведь
>через tun5 пакет исходит. Если я правильно понял рисунок сети
-i tun5 потому что мне надо на сервере А ловить пакеты которые из tun5 идут с сервера B
так что вроде всё верно, именно -i, разьве нет ?

-i, --in-interface
Интерфейс, с которого был получен пакет. Использование этого критерия допускается только в
цепочках INPUT, FORWARD и PREROUTING, в любых других случаях будет вызывать сообщение об
ошибке. При отсутствии этого критерия предполагается любой интерфейс, что равносильно
использованию критерия -i +. Как и прежде, символ ! инвертирует результат совпадения. Если имя
интерфейса завершается символом +, то критерий задает все интерфейсы, начинающиеся с заданной
строки, например -i PPP+ обозначает любой PPP интерфейс, а запись -i ! eth+ -- любой интерфейс,
кроме любого eth.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "мистика с маршрутизацией" +/–

Сообщение от ALex_hha (ok) on 08-Июл-09, 19:21

>так что вроде всё верно, именно -i, разьве нет ?
согласен
тогда смотри tcpdump на каком интерфейсе на Server A у тебя пытаются уйти ответы

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 08-Июл-09, 19:29

>>так что вроде всё верно, именно -i, разьве нет ?
>
>согласен
>
>тогда смотри tcpdump на каком интерфейсе на Server A у тебя пытаются
>уйти ответы
это всё смотрел, всё в норме
тоесть идет так
client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> Internet -> tun5 (B) -> tun5 (A) -> обрыв
всёб ничего, если бы локальные пакеты так же не доходили ;) но ходят куда угодно и возвращаются куда надо
client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> tun5 (A) -> tun0 (A) -> client
вот поэтому я в ступоре полном уже от того че происходит, первый раз такое поведение наблюдаю

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "мистика с маршрутизацией" +/–

Сообщение от shadow_alone (ok) on 08-Июл-09, 19:41

>это всё смотрел, всё в норме
>тоесть идет так
>client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> Internet -> tun5 (B) -> tun5 (A) -> обрыв
>
>всёб ничего, если бы локальные пакеты так же не доходили ;) но
>ходят куда угодно и возвращаются куда надо
>client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> tun5 (A) -> tun0 (A) -> client
>вот поэтому я в ступоре полном уже от того че происходит, первый
>раз такое поведение наблюдаю
Я всё-таки думаю, дело в маскарадинге.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 08-Июл-09, 19:48

>[оверквотинг удален]
>>тоесть идет так
>>client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> Internet -> tun5 (B) -> tun5 (A) -> обрыв
>>
>>всёб ничего, если бы локальные пакеты так же не доходили ;) но
>>ходят куда угодно и возвращаются куда надо
>>client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> tun5 (A) -> tun0 (A) -> client
>>вот поэтому я в ступоре полном уже от того че происходит, первый
>>раз такое поведение наблюдаю
>
>Я всё-таки думаю, дело в маскарадинге.
ну тогда я это просто не могу объяснить ;)
пакет то таки доходит до сервера A после маскарадинга на B
значит он всёж срабатывает, src, dst адреса верные у пакетов, что может для счастья то не хватать ? уже перепробовал всё что знал :) еще конечно можно попробовать вместо vtun на сервер B тунель через openvpn прокинуть... изначально так было, но тогда чето не срослось с роутингом и даже локальные пакеты не ходили и в процессе борьбы с роутингом тунель заменили на более простой vtun

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "мистика с маршрутизацией" +/–

Сообщение от reader (ok) on 08-Июл-09, 20:45

>[оверквотинг удален]
>>Я всё-таки думаю, дело в маскарадинге.
>
>ну тогда я это просто не могу объяснить ;)
>пакет то таки доходит до сервера A после маскарадинга на B
>значит он всёж срабатывает, src, dst адреса верные у пакетов, что может
>для счастья то не хватать ? уже перепробовал всё что знал
>:) еще конечно можно попробовать вместо vtun на сервер B тунель
>через openvpn прокинуть... изначально так было, но тогда чето не срослось
>с роутингом и даже локальные пакеты не ходили и в процессе
>борьбы с роутингом тунель заменили на более простой vtun
а с firewall все нормально, вроде не заметил что бы его обсуждали? может iptables-save c Server A покажите

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 08-Июл-09, 21:01

>[оверквотинг удален]
>>пакет то таки доходит до сервера A после маскарадинга на B
>>значит он всёж срабатывает, src, dst адреса верные у пакетов, что может
>>для счастья то не хватать ? уже перепробовал всё что знал
>>:) еще конечно можно попробовать вместо vtun на сервер B тунель
>>через openvpn прокинуть... изначально так было, но тогда чето не срослось
>>с роутингом и даже локальные пакеты не ходили и в процессе
>>борьбы с роутингом тунель заменили на более простой vtun
>
>а с firewall все нормально, вроде не заметил что бы его обсуждали?
>может iptables-save c Server A покажите
да там смотреть вообщем то неначто :)
# Generated by iptables-save v1.3.5 on Wed Jul  8 20:59:50 2009
*mangle
:PREROUTING ACCEPT [169477:18400981]
:INPUT ACCEPT [168697:18346334]
:FORWARD ACCEPT [555:37928]
:OUTPUT ACCEPT [188273:25109375]
:POSTROUTING ACCEPT [188828:25147303]
-A PREROUTING -s 10.9.0.0/255.255.255.0 -i tun0 -j MARK --set-mark 0x41
COMMIT
# Completed on Wed Jul  8 20:59:50 2009
# Generated by iptables-save v1.3.5 on Wed Jul  8 20:59:50 2009
*filter
:INPUT ACCEPT [168697:18346334]
:FORWARD ACCEPT [551:37688]
:OUTPUT ACCEPT [188273:25109375]
COMMIT
# Completed on Wed Jul  8 20:59:50 2009
# Generated by iptables-save v1.3.5 on Wed Jul  8 20:59:50 2009
*nat
:PREROUTING ACCEPT [14362:827959]
:POSTROUTING ACCEPT [16483:1179687]
:OUTPUT ACCEPT [16181:1159718]
COMMIT
# Completed on Wed Jul  8 20:59:50 2009

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "мистика с маршрутизацией" +/–

Сообщение от reader (ok) on 08-Июл-09, 21:45

>[оверквотинг удален]
>COMMIT
># Completed on Wed Jul  8 20:59:50 2009
># Generated by iptables-save v1.3.5 on Wed Jul  8 20:59:50 2009
>
>*nat
>:PREROUTING ACCEPT [14362:827959]
>:POSTROUTING ACCEPT [16483:1179687]
>:OUTPUT ACCEPT [16181:1159718]
>COMMIT
># Completed on Wed Jul  8 20:59:50 2009
да уж :)
а если пинговать но с адресом отправителя 10.9.0.2 ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 08-Июл-09, 22:33

>[оверквотинг удален]
>>*nat
>>:PREROUTING ACCEPT [14362:827959]
>>:POSTROUTING ACCEPT [16483:1179687]
>>:OUTPUT ACCEPT [16181:1159718]
>>COMMIT
>># Completed on Wed Jul  8 20:59:50 2009
>
>да уж :)
>
>а если пинговать но с адресом отправителя 10.9.0.2 ?
хм
с клиента не могу попробовать, там винда и у пинга нет такой опции
с сервера попробовал - пинги никуда не идут
правда с отправителем 10.9.0.2 не получилось пинговать вообще
ping -I 10.9.0.2 10.3.0.1
bind: Cannot assign requested address
с отправителем 10.9.0.1  получилось, но пакеты никуда не ходят вообще и по локалке тоже
ну я вообщем другого не ждал

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "мистика с маршрутизацией" +/–

Сообщение от reader (ok) on 08-Июл-09, 23:03

>[оверквотинг удален]
>>а если пинговать но с адресом отправителя 10.9.0.2 ?
>
>хм
>с клиента не могу попробовать, там винда и у пинга нет такой
>опции
>с сервера попробовал - пинги никуда не идут
>правда с отправителем 10.9.0.2 не получилось пинговать вообще
>ping -I 10.9.0.2 10.3.0.1
>bind: Cannot assign requested address
>
c Server A?
>с отправителем 10.9.0.1  получилось, но пакеты никуда не ходят вообще и
>по локалке тоже
>ну я вообщем другого не ждал
возможно потому что не маркируются.
глянуть бы tcpdump c Server A отдельно на tun0 и tun5 , когда пингуете инет и 100.1.2.3
может громкость логике и здравому смыслу поубавить ( раз локально ходят ) и попробовать для клиента и для tun0 использовать не пересекающиеся подсети и может модулей по подгружать типа nf_conntrack_*

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 09-Июл-09, 02:49

>[оверквотинг удален]
>
>c Server A?
>>с отправителем 10.9.0.1  получилось, но пакеты никуда не ходят вообще и
>>по локалке тоже
>>ну я вообщем другого не ждал
>
>возможно потому что не маркируются.
>
>глянуть бы tcpdump c Server A отдельно на tun0 и tun5 ,
>когда пингуете инет и 100.1.2.3
в моем первом посте tcpdump пинга к гуглу на разных интерфейсах
вот так же выглядит пинг к 100.1.2.3
тоесть тож самое на tun5 сервера А обратный пакет пропадает
>может громкость логике и здравому смыслу поубавить ( раз локально ходят )
>и попробовать для клиента и для tun0 использовать не пересекающиеся подсети
>и может модулей по подгружать типа nf_conntrack_*
насчет не пересекающихся сетей не уверен что можно так
посмотрю что в конфиг опенвпн можно прописать, ип раздает он, так же как и роутит их внетри себя
nf_conntrack_* никогда не использовал, почитаю что оно умеет

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 09-Июл-09, 05:43

ВСЁ ! ОНО ЗАРАБОТАЛО !
вообщем перевел все интерфейсы на полноценный ethernet, тоесть tap вместо tun (хотя думаю это не требовалось)
но возвращать обратно уже лень, достало меня это всё изрядно
перелопатил кучу мануалов по настройкам роутинга и в частности всему что находится в
/proc/sys/net/ipv4/conf/*
и нашел интересную штуку по имени rp_filter
оно было включено

Включает/выключает reverse path filter ("проверка обратного адреса" -- хотя это слишком вольный
перевод термина, но мне он кажется наиболее близким по смыслу. прим. перев.) для заданного
интерфейса. Смысл этой переменной достаточно прост -- все что поступает к нам проходит
проверку на соответствие исходящего адреса с нашей таблицей маршрутизации и такая проверка
считается успешной, если принятый пакет предполагает передачу ответа через тот же самый интерфейс.
Если вы используете расширенную маршрутизацию тем или иным образом, то вам следует всерьез
задуматься о выключении этой переменной, поскольку она может послужить причиной потери
пакетов. Например, в случае, когда входящий трафик идет через один маршрутизатор, а исходящий
-- через другой. Так, WEB-сервер, подключенный через один сетевой интерфейс к входному
роутеру, а через другой -- к выходному (в случае, когда включен rp_filter), будет просто
"терять" входящий трафик, поскольку обратный маршрут, в таблице маршрутизации, задан через
другой интерфейс.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "мистика с маршрутизацией" +/–

Сообщение от shadow_alone (ok) on 09-Июл-09, 05:50

а ведь всё было СОВСЕМ рядом - http://www.opennet.me/tips/info/347.shtml

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "мистика с маршрутизацией" +/–

Сообщение от deadlock (ok) on 09-Июл-09, 07:27

>а ведь всё было СОВСЕМ рядом - http://www.opennet.me/tips/info/347.shtml
всё кажется простым, когда уже точно знаешь причину :)
ктоб раньше об этой опции подумал ...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "мистика с маршрутизацией" +/–

Сообщение от ALex_hha (ok) on 09-Июл-09, 13:33

>>а ведь всё было СОВСЕМ рядом - http://www.opennet.me/tips/info/347.shtml
>
>всё кажется простым, когда уже точно знаешь причину :)
>ктоб раньше об этой опции подумал ...
Я почему то был уверен, что у тебя задано с помощью iproute, что пакеты должны уходить через тот же интерфейс, через который они пришли :)
По сути это является более правильным. Но тогда надо прописывать все маршруты. У самого сейчас такая же проблема. 3 провайдера + 2 vpn сервера + транспорт между офисами в которых по 2-3 подсети. Скажу вам не легкое это дело :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "мистика с маршрутизацией"		+/–
Сообщение от shadow_alone (ok) on 07-Июл-09, 02:08
а не пробывали Destination тож маркировать? -d 10.9.0.0/24 -j MARK etc Я не сильно уверен, сильно не вник, бегло прошелся по схеме. уверен, не в этом дело. и непонятно еще , зачем маршрут на всю сеть 10.9.0.0/24 via 10.9.0.2 dev tun0 , если для каждого клиента свой туннель поднимается.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 07-Июл-09, 03:02
	>а не пробывали Destination тож маркировать? >-d 10.9.0.0/24 -j MARK etc пробовал сделать так, вторую таблицу сделал и в ней ip rule add fwmark 60 table vpn2 ip route add default via 10.9.0.2 dev tun0 table vpn2 iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -i tun5 -j MARK --set-mark 60 не помогло... >Я не сильно уверен, сильно не вник, бегло прошелся по схеме. >уверен, не в этом дело. > >и непонятно еще , зачем маршрут на всю сеть 10.9.0.0/24 via 10.9.0.2 >dev tun0 , если для каждого клиента свой туннель поднимается. это маршрут дефолтный создает openvpn демон он же не для каждого юзера свой tun девайс создает, он у него всего один, вот тот, что на схеме нарисован, а демон я так понимаю сам рнутри себя всё от юзеров роутит на этот единственный tun0
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "мистика с маршрутизацией"		+/–
	Сообщение от shadow_alone (ok) on 07-Июл-09, 03:08
	ну с туннелью понятно - допустим она одна на всех, но почему же 10.9.0.0/24 via 10.9.0.2 , вот это не понять никак., тогда уж via dev tun0, без 10.9.0.2 попробуйте убрать в опенвпн, чтоб не создавал маршрут, или удалите после создания и создайте свой.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 07-Июл-09, 04:55
	>ну с туннелью понятно - допустим она одна на всех, >но почему же 10.9.0.0/24 via 10.9.0.2 , вот это не понять никак., >тогда уж via dev tun0, без 10.9.0.2 > >попробуйте убрать в опенвпн, чтоб не создавал маршрут, или удалите после создания >и создайте свой. не совсем понимаю как так может быть, маршрут без указания IP :) девайс там как раз присутствует маршрут то выглядит так если руками прописывать ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0 тоесть тут всё гуд как раз мне кажется копать надо кудато, из за чего могут нормально роутится внутренние IP и не роутится внешние я честно говоря не настолько хорошо знаю тонкости роутинга в линухах, чтоб знать такие вещи, что может влиять на такое поведение роутинга уже какие то глюки в работе с сетью openvz или openvpn в голову лезут :(
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "мистика с маршрутизацией"		+/–
	Сообщение от shadow_alone (ok) on 07-Июл-09, 08:26
	> >не совсем понимаю как так может быть, маршрут без указания IP :) ну например ipip тоесть, есть одна сторона и есть другая, никогда не пробовали на тунеле в циско ip unnumbered? ну это так, к слову. > >девайс там как раз присутствует >маршрут то выглядит так если руками прописывать > >ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0 >тоесть тут всё гуд как раз А помоему копать надо именно тут. Как вы себе представляете такое: ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0 # первый клиент ip route add 10.9.0.0/24 via 10.9.0.4 dev tun0 # второй клиент и т.д. ????????????????????? > >мне кажется копать надо кудато, из за чего могут нормально роутится внутренние >IP и не роутится внешние Еще смущает последний маскарадинг. Я правда никогда не пытался так делать, но кажется странным, вы ж должны свою сеть маскарадить, вот поэтому imho, он и не доходит. Попробуйте на сервере А тож маскарадинг, а если надо и рутить, то !маскарадить только в свои сети. >я честно говоря не настолько хорошо знаю тонкости роутинга в линухах, чтоб >знать такие вещи, что может влиять на такое поведение роутинга >уже какие то глюки в работе с сетью openvz или openvpn в >голову лезут :(
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 07-Июл-09, 18:49
	>[оверквотинг удален] >>маршрут то выглядит так если руками прописывать >> >>ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0 >>тоесть тут всё гуд как раз > >А помоему копать надо именно тут. Как вы себе представляете такое: >ip route add 10.9.0.0/24 via 10.9.0.2 dev tun0 # первый клиент >ip route add 10.9.0.0/24 via 10.9.0.4 dev tun0 # второй клиент >и т.д. >????????????????????? на сервере всегда прописан только один маршрут, сколько бы клиентов не законнектилось на впн 10.9.0.0/24 via 10.9.0.2 всё остальное, я так понимаю, впн сервер сам разруливает внутри себя тоесть то, что на картинке у меня у клиента IP 10.9.0.6 gw 10.9.0.5 это реальная ситуация, гейт с IP 10.9.0.5 на сервере нигде не прописан, он ток внутри впн демона фигурирует и роутится внутри на сервере висит только tun0 с одним IP и одним маршрутом всегда >>мне кажется копать надо кудато, из за чего могут нормально роутится внутренние >>IP и не роутится внешние > >Еще смущает последний маскарадинг. Я правда никогда не пытался так делать, но >кажется странным, вы ж должны свою сеть маскарадить, вот поэтому imho, >он и не доходит. >Попробуйте на сервере А тож маскарадинг, а если надо и рутить, то >!маскарадить только в свои сети. с маскарадингом всё ОК даже судя по тому что пакеты с сервера А нормально ходят на сервер B и оттуда на удаленные хосты и возвращаются обратно на A через B с верными src и dst адресами на А маскарадинг я пробовал поднимать, но толи не так чтото сделал, толи он просто не нужен там (к чему я больше склоняюсь, так как смысла не вижу в нем на А)... вообщем лучше не стало былоб интересно отследить по каким то логам что пытается сделать система с пришедшим на tun5 (A) пакетом, но я не знаю где это можно увидеть, на tcpdump вижу только наличие пакетов, но этой инфы маловато чтоб понять всё >>я честно говоря не настолько хорошо знаю тонкости роутинга в линухах, чтоб >>знать такие вещи, что может влиять на такое поведение роутинга >>уже какие то глюки в работе с сетью openvz или openvpn в >>голову лезут :(
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

7. "мистика с маршрутизацией"		+/–
Сообщение от ALex_hha (ok) on 07-Июл-09, 19:53
Мне кажется на сервере А надо явно задать маршрут для подсети 10.9.0.0/24 через отдельную таблицу что то типа # ip route add default via 10.9.0.2 dev tun0 table VPN2 # ip rule add fwmark 64 table VPN2 # iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -j MARK --set-mark 64 > пробовал сделать так, вторую таблицу сделал и в ней > ip rule add fwmark 60 table vpn2 > ip route add default via 10.9.0.2 dev tun0 table vpn2 > iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -i tun5 -j MARK --set-mark 60 разве здесь не -o tun5 должно быть вместо -i tun5 ? Ведь через tun5 пакет исходит. Если я правильно понял рисунок сети
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 08-Июл-09, 19:06
	>Мне кажется на сервере А надо явно задать маршрут для подсети 10.9.0.0/24 >через отдельную таблицу > >что то типа > ># ip route add default via 10.9.0.2 dev tun0 table VPN2 ># ip rule add fwmark 64 table VPN2 ># iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -j MARK --set-mark 64 так я ведь это и пробовал, только с указанием интерфейса >> пробовал сделать так, вторую таблицу сделал и в ней >> ip rule add fwmark 60 table vpn2 >> ip route add default via 10.9.0.2 dev tun0 table vpn2 >> iptables -t mangle -A PREROUTING -d 10.9.0.0/24 -i tun5 -j MARK --set-mark 60 > >разве здесь не -o tun5 должно быть вместо -i tun5 ? Ведь >через tun5 пакет исходит. Если я правильно понял рисунок сети -i tun5 потому что мне надо на сервере А ловить пакеты которые из tun5 идут с сервера B так что вроде всё верно, именно -i, разьве нет ? -i, --in-interface Интерфейс, с которого был получен пакет. Использование этого критерия допускается только в цепочках INPUT, FORWARD и PREROUTING, в любых других случаях будет вызывать сообщение об ошибке. При отсутствии этого критерия предполагается любой интерфейс, что равносильно использованию критерия -i +. Как и прежде, символ ! инвертирует результат совпадения. Если имя интерфейса завершается символом +, то критерий задает все интерфейсы, начинающиеся с заданной строки, например -i PPP+ обозначает любой PPP интерфейс, а запись -i ! eth+ -- любой интерфейс, кроме любого eth.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "мистика с маршрутизацией"		+/–
	Сообщение от ALex_hha (ok) on 08-Июл-09, 19:21
	>так что вроде всё верно, именно -i, разьве нет ? согласен тогда смотри tcpdump на каком интерфейсе на Server A у тебя пытаются уйти ответы
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 08-Июл-09, 19:29
	>>так что вроде всё верно, именно -i, разьве нет ? > >согласен > >тогда смотри tcpdump на каком интерфейсе на Server A у тебя пытаются >уйти ответы это всё смотрел, всё в норме тоесть идет так client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> Internet -> tun5 (B) -> tun5 (A) -> обрыв всёб ничего, если бы локальные пакеты так же не доходили ;) но ходят куда угодно и возвращаются куда надо client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> tun5 (A) -> tun0 (A) -> client вот поэтому я в ступоре полном уже от того че происходит, первый раз такое поведение наблюдаю
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "мистика с маршрутизацией"		+/–
	Сообщение от shadow_alone (ok) on 08-Июл-09, 19:41
	>это всё смотрел, всё в норме >тоесть идет так >client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> Internet -> tun5 (B) -> tun5 (A) -> обрыв > >всёб ничего, если бы локальные пакеты так же не доходили ;) но >ходят куда угодно и возвращаются куда надо >client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> tun5 (A) -> tun0 (A) -> client >вот поэтому я в ступоре полном уже от того че происходит, первый >раз такое поведение наблюдаю Я всё-таки думаю, дело в маскарадинге.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 08-Июл-09, 19:48
	>[оверквотинг удален] >>тоесть идет так >>client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> Internet -> tun5 (B) -> tun5 (A) -> обрыв >> >>всёб ничего, если бы локальные пакеты так же не доходили ;) но >>ходят куда угодно и возвращаются куда надо >>client -> tun0 (A) -> tun5 (A) -> tun5 (B) -> tun5 (A) -> tun0 (A) -> client >>вот поэтому я в ступоре полном уже от того че происходит, первый >>раз такое поведение наблюдаю > >Я всё-таки думаю, дело в маскарадинге. ну тогда я это просто не могу объяснить ;) пакет то таки доходит до сервера A после маскарадинга на B значит он всёж срабатывает, src, dst адреса верные у пакетов, что может для счастья то не хватать ? уже перепробовал всё что знал :) еще конечно можно попробовать вместо vtun на сервер B тунель через openvpn прокинуть... изначально так было, но тогда чето не срослось с роутингом и даже локальные пакеты не ходили и в процессе борьбы с роутингом тунель заменили на более простой vtun
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "мистика с маршрутизацией"		+/–
	Сообщение от reader (ok) on 08-Июл-09, 20:45
	>[оверквотинг удален] >>Я всё-таки думаю, дело в маскарадинге. > >ну тогда я это просто не могу объяснить ;) >пакет то таки доходит до сервера A после маскарадинга на B >значит он всёж срабатывает, src, dst адреса верные у пакетов, что может >для счастья то не хватать ? уже перепробовал всё что знал >:) еще конечно можно попробовать вместо vtun на сервер B тунель >через openvpn прокинуть... изначально так было, но тогда чето не срослось >с роутингом и даже локальные пакеты не ходили и в процессе >борьбы с роутингом тунель заменили на более простой vtun а с firewall все нормально, вроде не заметил что бы его обсуждали? может iptables-save c Server A покажите
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 08-Июл-09, 21:01
	>[оверквотинг удален] >>пакет то таки доходит до сервера A после маскарадинга на B >>значит он всёж срабатывает, src, dst адреса верные у пакетов, что может >>для счастья то не хватать ? уже перепробовал всё что знал >>:) еще конечно можно попробовать вместо vtun на сервер B тунель >>через openvpn прокинуть... изначально так было, но тогда чето не срослось >>с роутингом и даже локальные пакеты не ходили и в процессе >>борьбы с роутингом тунель заменили на более простой vtun > >а с firewall все нормально, вроде не заметил что бы его обсуждали? >может iptables-save c Server A покажите да там смотреть вообщем то неначто :) # Generated by iptables-save v1.3.5 on Wed Jul 8 20:59:50 2009 mangle :PREROUTING ACCEPT [169477:18400981] :INPUT ACCEPT [168697:18346334] :FORWARD ACCEPT [555:37928] :OUTPUT ACCEPT [188273:25109375] :POSTROUTING ACCEPT [188828:25147303] -A PREROUTING -s 10.9.0.0/255.255.255.0 -i tun0 -j MARK --set-mark 0x41 COMMIT # Completed on Wed Jul 8 20:59:50 2009 # Generated by iptables-save v1.3.5 on Wed Jul 8 20:59:50 2009 filter :INPUT ACCEPT [168697:18346334] :FORWARD ACCEPT [551:37688] :OUTPUT ACCEPT [188273:25109375] COMMIT # Completed on Wed Jul 8 20:59:50 2009 # Generated by iptables-save v1.3.5 on Wed Jul 8 20:59:50 2009 *nat :PREROUTING ACCEPT [14362:827959] :POSTROUTING ACCEPT [16483:1179687] :OUTPUT ACCEPT [16181:1159718] COMMIT # Completed on Wed Jul 8 20:59:50 2009
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "мистика с маршрутизацией"		+/–
	Сообщение от reader (ok) on 08-Июл-09, 21:45
	>[оверквотинг удален] >COMMIT ># Completed on Wed Jul 8 20:59:50 2009 ># Generated by iptables-save v1.3.5 on Wed Jul 8 20:59:50 2009 > >*nat >:PREROUTING ACCEPT [14362:827959] >:POSTROUTING ACCEPT [16483:1179687] >:OUTPUT ACCEPT [16181:1159718] >COMMIT ># Completed on Wed Jul 8 20:59:50 2009 да уж :) а если пинговать но с адресом отправителя 10.9.0.2 ?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 08-Июл-09, 22:33
	>[оверквотинг удален] >>*nat >>:PREROUTING ACCEPT [14362:827959] >>:POSTROUTING ACCEPT [16483:1179687] >>:OUTPUT ACCEPT [16181:1159718] >>COMMIT >># Completed on Wed Jul 8 20:59:50 2009 > >да уж :) > >а если пинговать но с адресом отправителя 10.9.0.2 ? хм с клиента не могу попробовать, там винда и у пинга нет такой опции с сервера попробовал - пинги никуда не идут правда с отправителем 10.9.0.2 не получилось пинговать вообще ping -I 10.9.0.2 10.3.0.1 bind: Cannot assign requested address с отправителем 10.9.0.1 получилось, но пакеты никуда не ходят вообще и по локалке тоже ну я вообщем другого не ждал
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "мистика с маршрутизацией"		+/–
	Сообщение от reader (ok) on 08-Июл-09, 23:03
	>[оверквотинг удален] >>а если пинговать но с адресом отправителя 10.9.0.2 ? > >хм >с клиента не могу попробовать, там винда и у пинга нет такой >опции >с сервера попробовал - пинги никуда не идут >правда с отправителем 10.9.0.2 не получилось пинговать вообще >ping -I 10.9.0.2 10.3.0.1 >bind: Cannot assign requested address > c Server A? >с отправителем 10.9.0.1 получилось, но пакеты никуда не ходят вообще и >по локалке тоже >ну я вообщем другого не ждал возможно потому что не маркируются. глянуть бы tcpdump c Server A отдельно на tun0 и tun5 , когда пингуете инет и 100.1.2.3 может громкость логике и здравому смыслу поубавить ( раз локально ходят ) и попробовать для клиента и для tun0 использовать не пересекающиеся подсети и может модулей по подгружать типа nf_conntrack_*
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 09-Июл-09, 02:49
	>[оверквотинг удален] > >c Server A? >>с отправителем 10.9.0.1 получилось, но пакеты никуда не ходят вообще и >>по локалке тоже >>ну я вообщем другого не ждал > >возможно потому что не маркируются. > >глянуть бы tcpdump c Server A отдельно на tun0 и tun5 , >когда пингуете инет и 100.1.2.3 в моем первом посте tcpdump пинга к гуглу на разных интерфейсах вот так же выглядит пинг к 100.1.2.3 тоесть тож самое на tun5 сервера А обратный пакет пропадает >может громкость логике и здравому смыслу поубавить ( раз локально ходят ) >и попробовать для клиента и для tun0 использовать не пересекающиеся подсети >и может модулей по подгружать типа nf_conntrack_* насчет не пересекающихся сетей не уверен что можно так посмотрю что в конфиг опенвпн можно прописать, ип раздает он, так же как и роутит их внетри себя nf_conntrack_* никогда не использовал, почитаю что оно умеет
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 09-Июл-09, 05:43
	ВСЁ ! ОНО ЗАРАБОТАЛО ! вообщем перевел все интерфейсы на полноценный ethernet, тоесть tap вместо tun (хотя думаю это не требовалось) но возвращать обратно уже лень, достало меня это всё изрядно перелопатил кучу мануалов по настройкам роутинга и в частности всему что находится в /proc/sys/net/ipv4/conf/* и нашел интересную штуку по имени rp_filter оно было включено Включает/выключает reverse path filter ("проверка обратного адреса" -- хотя это слишком вольный перевод термина, но мне он кажется наиболее близким по смыслу. прим. перев.) для заданного интерфейса. Смысл этой переменной достаточно прост -- все что поступает к нам проходит проверку на соответствие исходящего адреса с нашей таблицей маршрутизации и такая проверка считается успешной, если принятый пакет предполагает передачу ответа через тот же самый интерфейс. Если вы используете расширенную маршрутизацию тем или иным образом, то вам следует всерьез задуматься о выключении этой переменной, поскольку она может послужить причиной потери пакетов. Например, в случае, когда входящий трафик идет через один маршрутизатор, а исходящий -- через другой. Так, WEB-сервер, подключенный через один сетевой интерфейс к входному роутеру, а через другой -- к выходному (в случае, когда включен rp_filter), будет просто "терять" входящий трафик, поскольку обратный маршрут, в таблице маршрутизации, задан через другой интерфейс. вообщем выключил и пакеты забегали как надо не совсем понимаю почему локальные ходили правда и почему в одну сторону и не локальные ходили как надо, но уже не важно всем спасибо, кто пытался помочь, но к сожалению мы все копали не туда :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "мистика с маршрутизацией"		+/–
	Сообщение от shadow_alone (ok) on 09-Июл-09, 05:50
	а ведь всё было СОВСЕМ рядом - http://www.opennet.me/tips/info/347.shtml
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "мистика с маршрутизацией"		+/–
	Сообщение от deadlock (ok) on 09-Июл-09, 07:27
	>а ведь всё было СОВСЕМ рядом - http://www.opennet.me/tips/info/347.shtml всё кажется простым, когда уже точно знаешь причину :) ктоб раньше об этой опции подумал ...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "мистика с маршрутизацией"		+/–
	Сообщение от ALex_hha (ok) on 09-Июл-09, 13:33
	>>а ведь всё было СОВСЕМ рядом - http://www.opennet.me/tips/info/347.shtml > >всё кажется простым, когда уже точно знаешь причину :) >ктоб раньше об этой опции подумал ... Я почему то был уверен, что у тебя задано с помощью iproute, что пакеты должны уходить через тот же интерфейс, через который они пришли :) По сути это является более правильным. Но тогда надо прописывать все маршруты. У самого сейчас такая же проблема. 3 провайдера + 2 vpn сервера + транспорт между офисами в которых по 2-3 подсети. Скажу вам не легкое это дело :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору