Доброго времени всем! Появилась задачка, которую уже долгое время не могу решить - потому прошу помочь...

Имеется: два сетевых интерфейса с разными IP, масками, шлюзами и т.д. По обоим "приходит интернет" :)

Задача: программно "переключать" интерфейсы и через каждый из них послать GET-запрос (http) на внешний сервер.

с HTTP работаю, использую компонент idHTTP - с этим проблем нет. Запросы посылаются, ответы приходят, все ОК. Но все это дело проходит только по тому сетевому интерфейсу, который назначен в системе основным (метрика наименьшая). Менять метрику для всей системы не очень приятно.
Думаю, можно решить это дело локально, в контексте только моего приложения?

> По обоим "приходит интернет"


> Но все это дело проходит только по тому сетевому интерфейсу,
> который назначен в системе основным (метрика наименьшая)
> .

значит другой простаивает...

> значит другой простаивает...

Кэп, как мне Вас не хватало... =D

> можно решить это дело локально, в контексте только моего
> приложения?


У IdHTTP для этого есть св-во BoundIP

[2] я намекал на то, что если у тебя используется фактически только один интерфейс, зачем дергать за другой? или у Вас нагрузка распределяется по обоим?

> или у Вас нагрузка распределяется по обоим?

во время простоя одного из интерфейсов приложение должно проверять состояние его IP...

> Задача: программно "переключать" интерфейсы и через каждый
> из них послать GET-запрос (http) на внешний сервер.

точнее, через каждый интерфейс посылать запрос на внешку для определения IP, затем, если IP для одного из интерфейсов изменился - нужно переключить всю систему на этот интерфейс (например, с помощью вызова команды "route ..."). Определять приходится через внешку потому, что машина находится за роутерами.


> У IdHTTP для этого есть св-во BoundIP

Да, я это свойство опробовал. Обнаружил такую проблему:
Если в системе оба интерфейса с одинаковой метрикой, то использование BoundIP дает желаемый результат. Если же метрика одно из них ниже (т.е. приоритет выше), то использование свойства BoundIP не дает желаемого результата: запрос передается через интерфейс с более высоким приоритетом, но с адресом (в BoundIP) другого интерфейса, что приводит к невозможности подключения к внешнему хосту =(

> если IP для одного из интерфейсов изменился

так это может быть только в одном случае и имхо маршрут просле реконнекта меняется сам...

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

Описываю:

Первый интерфейс - сетевая карта. Машина за роутером, имеет свой статический локальный IP. На другой стороне роутера "приходит интернет" ))

Второй интерфейс - ADSL-модем (usb).

В итоге имеем два внешних IP (динамические) и один локальный (статический)

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

у Вас каша в голове... советую ознакомиться с основами tcp/ip сетей, многие вопросы отпадут...
зы. ip просто так не меняеются "находу"

У меня не каша в голове, а конкретная задача: произвести подключение к внешнему хосту через конкретный интерфейс, при этом менять метрику на интерфейсах, т.е. маршруты, для всей системы в целом крайне не желательно.

с основами ip-сетей прекрасно знаком, так что вопрос остается открытым...

p.s. Внешние IP присваиваются провайдером, меняются динамически примерно раз в сутки (иногда чаще)

удачи!

> удачи!

спасибо, именно это мне сейчас и необходимо...

> интерфейса с одинаковой метрикой


Метрика она вообще-то не у интерфейса, а у маршрута.

Если два маршрута к одной и той же целевой подсети/хосту проходят через два разных шлюза в одной и той же подсети источника, то иначе как расстановкой нужных приоритетов маршрутов (метрик) задача на прикладном уровне не решается.

Вот если источники в разных подсетях (соответственно и шлюзы в разных подсетях), то простой биндинг к нужному локальному адресу в нужной подсети источника с легкостью решает задачу.

И судя по

> два сетевых интерфейса с разными IP, масками, шлюзами и  т.д


биндинг к нужному "разному IP" обязан решить задачу.

При условии что интерфейсы по чьей-то неразумности или прихоти не сконфигурированы так что подсети пересекаются, например, так:

if1: 192.168.0.3/24 gw 192.168.0.1
if2: 192.168.0.4/16 gw 192.168.0.2

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

> Метрика она вообще-то не у интерфейса, а у маршрута.

да, эт я просто уже "задрыгался" с ручной настройкой маршрутов из командной строки - "интерфейсы", "метрика"...

1 канал: локалка, настроена банально: ip=192.168.1.10, шлюз=192.168.1.1, маска=255.255.255.0
за "локалкой" стоит роутер с выходом во внешку (пример автоматически получаемых настроек: ip=37.99.11.50, шлюз=37.99.11.50, маска=255.255.255.255)

2 канал: ADSL, получает настройки от DHCP автоматом (например, такие: ip=95.57.77.131, шлюз=95.57.77.131, маска=255.255.255.255)

Ну и ?
Биндишься к 192.168.1.10 - ходишь в Тырнет через 192.168.1.1 (а он, в свою очередь, через 37.99.11.50, если у него там на борту с маршрутами не понахреноверчено)

Биндишься к 95.57.77.131 - ходишь туда же, но уже через 95.57.77.131

ага, вот тут-то и начинается "магия"...

192.168.1.10 метрика=1, 95.57.77.131 метрика=10, idHTTP1.BoundIP:='95.57.77.131'
подключение неудачно

95.57.77.131 метрика=1, 192.168.1.10 метрика=10, idHTTP1.BoundIP:='192.168.1.10'
подключение неудачно

единственный случай, когда это "прокатывает" - если метрика выставлена одинаковая (например равная единице)

что может быть не так (с системой / с руками / с мозгом)?

> подключение неудачно

подключение происходит удачно, но через тот интерфейс, через который в системе прописан приоритетный маршрут (метрика=1)

приведи таблицу маршрутизации..

Насколько я понимаю, в винде, по крайней мере до ХР включительно, это так by design. Ну нету в ней source routing...

0.0.0.0          0.0.0.0     95.57.74.136    95.57.74.136       1 //<- по этому маршруту пойдут пакеты при биндинге только на 95.57.74.136
0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.10       10 //<- а по этому - при биндинге либо только на 192.168.1.10 либо на оба (или все активные)

0.0.0.0          0.0.0.0     95.57.74.136    95.57.74.136       1  // <- по этму маршруту идут все пакеты при любом биндинге
0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.10       10 //<- а по этому - ни один пакет не идет

> по этму маршруту идут все пакеты при любом биндинге


Как могут пойти во внешние сети пакеты от хоста 192.168.1.10 в подсети 192.168.1.0/24 через шлюз 95.57.74.136, находящийся совсем в другой подсети 95.57.74.136/32 ?

не знаю, я тоже не могу понять, что происходит, потому и задал этот вопрос...

А вот полюбуйся:

idhttp1.BoundIP := '127.0.0.2';

> А вот полюбуйся:
>
> idhttp1.BoundIP := '127.0.0.2';


"Socket error #10065
No route to host."

idhttp1.BoundIP := '127.0.0.1';

"Connect timed out"

Не будет оно работать.
Windows выбирает первый маршрут из списка.
Единственный выход делать свою реализацию стека TCP/IP а это уже не прикладной уровень. Но через WinPCap можно попробовать.

У меня вот появились такие мысли...
Выставил метрику=1 для обоих интерфейсов, но для достижения поставленной цели нужно сменить ОСНОВНОЙ ШЛЮЗ:

===========================================================================
Список интерфейсов
0x1 ........................... MS TCP Loopback interface
0x2 ...00 13 a9 c3 ae 48 ...... Marvell Yukon 88E8036 PCI-E Fast Ethernet Controller
0x40004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
        0.0.0.0          0.0.0.0     95.57.74.136    95.57.74.136       1
        0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.10       1
    95.57.42.16  255.255.255.255     95.57.74.136    95.57.74.136       1
   95.57.74.136  255.255.255.255        127.0.0.1       127.0.0.1       50
 95.255.255.255  255.255.255.255     95.57.74.136    95.57.74.136       50
      127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
    192.168.1.0    255.255.255.0     192.168.1.10    192.168.1.10       20
   192.168.1.10  255.255.255.255        127.0.0.1       127.0.0.1       20
  192.168.1.100  255.255.255.255        127.0.0.1       127.0.0.1       50
  192.168.1.255  255.255.255.255     192.168.1.10    192.168.1.10       20
      224.0.0.0        240.0.0.0     192.168.1.10    192.168.1.10       20
      224.0.0.0        240.0.0.0     95.57.74.136    95.57.74.136       1
255.255.255.255  255.255.255.255     95.57.74.136    95.57.74.136       1
255.255.255.255  255.255.255.255     192.168.1.10    192.168.1.10       1
Основной шлюз:        95.57.74.136
===========================================================================
Постоянные маршруты:
Отсутствует

Как это можно сделать? Тут уже вопрос даж не к кодерам, а просто к сетевикам... =) Знать бы, по какому принципу система выбирает себе этот "основной шлюз"... проблема в том, что винда умудряется время от времени переключать шлюзы самостоятельно... А вот как прописать тот или иной шлюз самостоятельно и чтоб он потом не сменился другим?...