Как заставить win устанавливать smb-соединение только по одному из двух возможных маршрутов?

Question

[Ziptar]

Дано: две машины с win сервер с двумя возможными путями коммуникации
1) напрямую кабелем с подсетью 192.168.99.0/24
2) через маршрутизатор с подсетью 172.16.1.0/24

Когда одна машина пытается подключиться к другой через smb по адресу в сети 192.168.99.0/24 - на самом деле устанавливается и соединение в сети 172.16.1.0/24.
Обе машины в домене, netbios полностью отключен, DNS ничего не знает о сети 192.168.99.0/24.
В net stat следующая картина:
TCP 172.16.1.17:49224 %servername%:microsoft-ds ESTABLISHED
TCP 172.16.1.17:49225 %servername%:microsoft-ds ESTABLISHED
TCP 172.16.1.17:49226 %servername%:microsoft-ds ESTABLISHED
TCP 192.168.99.3:49219 192.168.99.1:microsoft-ds ESTABLISHED
TCP 192.168.99.3:49220 192.168.99.1:microsoft-ds ESTABLISHED
TCP 192.168.99.3:49221 192.168.99.1:microsoft-ds ESTABLISHED
TCP 192.168.99.3:49222 192.168.99.1:microsoft-ds ESTABLISHED

Почему win так делает, и как этого избежать?

UPD:
%servername% резольвится, разумеется, как адрес из сети 172.16.1.0/24.
Все соединения имеют вид 172.16.1.0/24 -> 172.16.1.0/24 и 192.168.99.0/24 -> 192.168.99.0/24; соединений вида 172.16.1.0/24 -> 192.168.99.0/24 или в обратную сторону нет. То есть тут не проблемы маршрутизации.
Win каким-то образом определяет, что целевой сервер доступен ещё и по другому адресу, нежели тот, что прямо указывается как целевой адрес smb-соединения. Каким образом?

Answer 1

[Rsa97]

Смотрите маршрутизацию.
netstat -rn

Comments

[Ziptar]

С маршрутами проблем нет, запросы в сеть 192.168.99.0/24 через соответствующий интерфейс, все остальные через шлюз в сети 172.16.1.0/24.

Answer 2

[ТыжСисАдмин]

Ваши два сервера ничего не знают о друг друга (netbios off), всё что они знают так это то что отдаёт им DNS сервер а как я понял отдаёт он им 172ю подсесть.
Используйте для smb заместь имён, конкретные адреса 192й подсети или указатель в hosts явную привязку к адресам из 192й подсети.

А вообще не понятно к чему такой изврат.

Comments

[Ziptar]

Обращение к конечному серверу идёт напрямую по адресу из сети 192.168.99.0/24. По идее они имен друг друга вообще знать не должны.

[АртемЪ]

Константин Антонов, Почему это они не должны знать имен?

[Ziptar]

АртемЪ,
Откуда, собственно?

[АртемЪ]

Константин Антонов, Ну как правило DNS, WINS.

Answer 3

[АртемЪ]

Если вы обратитесь к SBM серверу по адресу из подсети в которой вы сами находитесь, то трафик пойдет напрямую.
Если он идет не напрямую значит вы вероятно обращаетесь по имени, а имя выдает другой IP адрес, в итоге трафик идет через дефолтный маршрут на маршрутизатор.
Вывод - ходите по IP адресу, либо следите за сопоставлением имен и адресов - кто там у вас этим занимается DNS или WINS

Comments

[Ziptar]

Ещё раз повторяю: обращение идёт напрямую по ip, а трафик идёт по обоим каналам одновременно.

[АртемЪ]

Константин Антонов, Почему вы так решили?

Вы же привели -

TCP 172.16.1.17:49224 %servername%:microsoft-ds ESTABLISHED

Было обращение к servername, сервер имен выдал адрес 172.16.1.17, соединение установлено.
Поскольку этот адрес лежит в другой подсети, то трафик пойдет через роутер.

TCP 192.168.99.3:49219 192.168.99.1:microsoft-ds ESTABLISHED

Соединение с ip адресом 192.168.99.3 установлено.

В итоге обращатесь по имени - трафик идет через роутер, обращаетесь напрямую - трафик идет напрямую.
В чем проблема то?

[АртемЪ]

Win каким-то образом определяет, что целевой сервер доступен ещё и по другому адресу

Ну разумеется, если этот адрес находится в той же подсети.
У вас же там маскарадинга на роутере нет.

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

[Ziptar]

АртемЪ,
Будьте любезны, читайте написанное полностью, а не урывками.

Было обращение к servername, сервер имен выдал адрес 172.16.1.17, соединение установлено.
Поскольку этот адрес лежит в другой подсети, то трафик пойдет через роутер.

Было обращение только к 192.168.99.1; инициативная венда самовольно установила параллельные соединения к %servername%.

Ну разумеется, если этот адрес находится в той же подсети.

192.168.99.1 находится в подсети 172.16.1.0/24? Брейкинг ньюс.

[АртемЪ]

Константин Антонов, Подключаетесь к шаре вы как? Строку подключения приведите? По имени?

Ну разумеется, если этот адрес находится в той же подсети.

В той же подсети, что и клиент.

Я не могу понять что вам не нравиться?

• Что трафик идет через роутер, по адресу 172.16.1.0/24 - тогда обращайтесь напрямую и проблема исчезнет.
  
• Что трафик идет напрямую - тогда запретите серверу работать на этом адресе
  

[Ziptar]

АртемЪ,

тогда обращайтесь напрямую и проблема исчезнет.

Повторяю в очередной раз: обращение идёт напрямую.

[АртемЪ]

Константин Антонов,

Повторяю в очередной раз: обращение идёт напрямую.

Если вы обращаетесь напрямую, значит строка подключение к шаре у вас \\192.168.99.3\ так?

Тогда я просто не понимаю как у вас трафик при этом может пойти на 172.16.1.17 - это уже фантастика какая, то.

[Ziptar]

АртемЪ,
\\192.168.99.1 если быть предельно точным.

это уже фантастика какая, то.

Так а я об чём?
Сам голову ломаю.

[АртемЪ]

Константин Антонов, А адрес клиента какой?
И как настроен сервер, на котором шара?
Какие там маршруты?

[Ziptar]

А адрес клиента какой?

192.168.99.3 =/

И как настроен сервер, на котором шара?

На входящие соединения открыт только 445/TCP; netbios отключён на всех интерфейсах; LLMNR отключен через политики.

Какие там маршруты?

Шлюз на 172.16.1.1, 192.168.99.0/24 на соответствующий интерфейс.

Вопрос не в том, что трафик неправильно идёт - вопрос в том, каким образом клиент узнаёт вообще о наличии второго адреса у сервера.

Вообще у меня появилась пара мыслишек... Клиент представляется серверу c учётной записью компьютера в домене. Надо будет проверить как он проводит аутентификацию - через керберос (хотя не должен), или через ntlm; если первое - попробовать отключить.
И попробовать банально обмануть клиент, подсунув в hosts левый hostname, и попытаться подключиться по нему.