|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Igor Suvorov 2:5020/400 08 Feb 2003 21:56:01
To : Aleksey Barabanov
Subject : Re: pass stream over separate interface
--------------------------------------------------------------------------------
Aleksey Barabanov <alekseybb@mtu-net.ru> writes:
> > Собственно, в том числе и эксперименты со сквидом позволяют сделать
> > дополнительный вывод о том, что пакеты сбрасывает именно обработчик.
> >
> > Т..к. tcpdump на обработчике пакеты видит, но access.log сквида при
> Tcpdump видит пакеты в сети.
Там свитч и на интерфейсах разные vlan'ы. Сервер со сквидом стоит в своем
собственном vlan, где никого больше нет. Если tcpdump эти пакеты видит,
значит они ушли в соответствующий порт, как и предполагалось.
> А в стеке обработчика их пожно поймать только через логи iptables. Hо раз
> вы пишите, что пакеты проходят через форвард, значит и через стек. И если
> добавление транзитного интерфейса решает проблему, значит на приемном конце
> вашего линуксбокса все ОК. Добавление интерфейса меняет таблицу роутинга
> внутри линуксбокса. И именно где-то там пакеты и тераются в отсутствие
> транзитного интерфейса.
В каком смысле? Что именно понимается под транзитным интерфейсом? Пакеты в
любом случае возвращаются через тот же самый интерфейс и на машине со
сквидом ничего кроме адреса шлюза не изменяется. Разница лишь в том, куда
именно направляются обратные пакеты.
> > этом девственно чистый. Если сквид запущен, на eth2 должен вернуться
> > уже его запрос. Ан нет.
> Сейчас выходной, и я бессилен что-то проверить ;( Hо мне кажется надо
> поймать потеряные пакеты на счетчиках интерфейсов и таблиц netfilter.
> Ситуация упростится, если вы на рутере перенаправите не tcp to 80 на
> линуксбокс а icmp. Тогда можно будет точнее просчитать прохождение пакетов
> по счетчикам, да и ответ при дропаньи можно будет получить.
Да в общем, я тоже сейчас не особенно способен что-то проверять. Вся
схема разумеется на работе. Меня больше интересовало, сталкивался ли
кто нибудь с подобной проблемой, либо обратно работает ли у кого нибудь
подобная схема.
Если посмотреть в Linux 2.4 Advanced Routing HowTo на то, как там
предлагается строить Transparent Caching, то возникает нездоровое ощущение,
что в свое время там возникли ровно те же самые проблемы. Иначе я слабо
понимаю, зачем для netfilter выделена отдельная машина, только снижающая
отказоустойчивость всей схемы.
--
Igor
--- ifmail v.2.15dev5
* Origin: no gnus is bad news (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
