Re: привязка к ip для исходящих соединений
Hello!
On Tue, Nov 14, 2006 at 03:07:07PM +0200, Покотиленко Костик wrote:
> > Как правило, при создании исходящих соединений используется адрес,
> > который висит на eth0, если явно не было задано другое.
> > Но один раз напоролся на неприятную вещь: после
> > добавления очередного алиаса, некоторый софт (к примеру, ssh) стал
> > привязываться к другому адресу для исходящих tcp-сессий (к одному из
> > алиасов, а не основному, вищяему на eth0).
> > Недавно похожую штуку выкинул и postfix.
> >
> > Можно ли как-то жестко указать, что по умолчанию биндится _только_ на
> > адрес eth0 для исходящих коннекшнов?
> > Причем решить это на общесистемном уровне.
> >
> > Жестко прописывать outgoing address для каждой софтины отдельно - просьба не
> > предлагать, интересует именно какая-то глобальная опция.
> >
> > Есть такое?
> >
> > Заранее спасибо.
> >
> Я та понимаю, eth0 и eth0:1 это два разных (хоть и логически)
> интерфейса. Так что и работать с ними надо как например с eth0 и ppp0.
>
> default route пропиши только через eth0 и при коннекте на адреса не сети
> eth0 должен пойти через гейт.
Подсеть одна, все алиасы eth0:x тоже из этой же подсети, дефолтный гейт
тоже один. Проблема не в раутинге, а в том, что приложение, при
создании сокета иногда использует не первый (eth0) адрес, а рандомный в
к-ве ip-адреса исходящего соединения.
Возможно я не понятно объясняю? На примере, есть интерфейсы:
eth0
10.0.0.10/24
eth0:1
10.0.0.11/32
eth0:2
10.0.0.12/32
Допустим, я делаю исходящий коннект с сервера на адрес 1.2.3.4, порт 80,
тогда tcp-сессия будет выглядеть так:
10.0.0.10:56434 -> 1.2.3.4:80
Но, иногда, возникают ситуации, когда вместо 10.0.0.10 используется
10.0.0.12, к примеру, т.е. адрес алиаса.
Закономерности такого поведения я не выявил, это фича или баг поведения
библиотек tcp/ip стэка?
Если фича, то можно ли ее как-то настраивать, чтобы она так себя не
вела, т.е. для исходящих соединения по умолчанию всегда использовала
адрес первого интерфейса (если явно не указано другое).
--
WBR,
Alexander Burnos
Reply to: