Здравствуйте


Есть компьютер centos 7
несколько сетевых адаптеров
inet 172.18.2.66 netmask 255.255.255.0 broadcast 172.18.2.255
inet 192.168.71.240 netmask 255.255.255.224 broadcast 192.168.71.255
inet 10.1.24.30 netmask 255.255.255.0 broadcast 10.1.24.255


Есть ли возможность при вызове

socket(...)
connect(...)

управлять адресом источника? или ядро само определит этот адрес в зависимости от таблицы маршрутизации и лезть туда не надо?

С уважением, Павел

Здравствуйте, Pavel515, Вы писали:

P>Есть компьютер centos 7
P>несколько сетевых адаптеров
P> inet 172.18.2.66 netmask 255.255.255.0 broadcast 172.18.2.255
P> inet 192.168.71.240 netmask 255.255.255.224 broadcast 192.168.71.255
P> inet 10.1.24.30 netmask 255.255.255.0 broadcast 10.1.24.255

P>Есть ли возможность при вызове

P>socket(...)
P>connect(...)

P>управлять адресом источника? или ядро само определит этот адрес в зависимости от таблицы маршрутизации и лезть туда не надо?

Обычно само и обычно не надо.
Если надо — есть функция bind(), которую надо звать до connect(). Если connect() вызван, звать bind() уже поздно — он вызовется внутри connect().

Есть, правда, специализированные случаи, когда надо переопределять адрес в зависимости от ремоты — вот тут уже надо хитрую логику приворачивать. Это, например, если на интерфейсе 2 адреса из одной подсети, по умолчанию берётся первый, а нужно выходить со второго, но только если исход через этот интерфейс.
Тогда можно спрашивать выходной интерфейс через `ip route get` или его APIшный аналог.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Pavel515, Вы писали:

P>>Есть компьютер centos 7
P>>несколько сетевых адаптеров
P>> inet 172.18.2.66 netmask 255.255.255.0 broadcast 172.18.2.255
P>> inet 192.168.71.240 netmask 255.255.255.224 broadcast 192.168.71.255
P>> inet 10.1.24.30 netmask 255.255.255.0 broadcast 10.1.24.255

P>>Есть ли возможность при вызове

P>>socket(...)
P>>connect(...)

P>>управлять адресом источника? или ядро само определит этот адрес в зависимости от таблицы маршрутизации и лезть туда не надо?

N>Обычно само и обычно не надо.
N>Если надо — есть функция bind(), которую надо звать до connect(). Если connect() вызван, звать bind() уже поздно — он вызовется внутри connect().

N>Есть, правда, специализированные случаи, когда надо переопределять адрес в зависимости от ремоты — вот тут уже надо хитрую логику приворачивать. Это, например, если на интерфейсе 2 адреса из одной подсети, по умолчанию берётся первый, а нужно выходить со второго, но только если исход через этот интерфейс.
N>Тогда можно спрашивать выходной интерфейс через `ip route get` или его APIшный аналог.

Спасибо
все просто

socket(...)
bind(...)
connect(...)

но применять такое, наверное есть необходимость действительно, когда на есть несколько адресов из одной подсети.

Ещё раз спасибо
С уважением, Павел

Здравствуйте, Pavel515, Вы писали:

P>Спасибо
P>все просто

P>socket(...)
P>bind(...)
P>connect(...)

В общем случае — всё очень непросто А в ряде случаев — ещё и невозможно:
https://en.wikipedia.org/wiki/Host_model

Здравствуйте, Mr.Delphist, Вы писали:

P>>Спасибо
P>>все просто

P>>socket(...)
P>>bind(...)
P>>connect(...)

MD>В общем случае — всё очень непросто А в ряде случаев — ещё и невозможно:
MD>https://en.wikipedia.org/wiki/Host_model

Статья какая-то странная.
"BSD defaults to the strong host model." — не знаю, про какие BSD речь, но с FreeBSD я работал много лет, и там такого не было. Если какой-нибудь fxp0 имеет 192.168.1.1/24, а xl0 — 192.168.3.1/24, то если 192.168.1.2 честно пытается связаться с 192.168.3.1, и запрос поступает через fxp0, то он удовлетворяется.
Уточню: это при включенном ip forwarding. Без него я такие штуки не проверял (ну не было нужно), и, наверно, тогда и не примет — я бы не удивился. Но в статье не указано — что принципиально проверять разрешение форвардинга.

Про конкретный случай у ТС — ну если у него не заработает, он увидит. Тут как раз сложнее, если есть частичная невидимость только у какой-то малой группы.