вопрос по маршрутизации и NETBIOS

[DesKV]

Есть два компьютера в разных подсетях. 192.168.2.5 и 192.168.3.5 и два маршрутизатора, которые смотрят оба в две сети (на рисунке).
Комп 192.168.2.5 имеет шлюз по умолчанию 192.168.2.1, а комп 192.168.3.5 имеет шлюз по умолчанию 192.168.3.2

То есть при трассировке пакеты от 2.5 к 3.5 идут по красной линии. А обратно уже по синей. Пинг работает, сеть как бы функциональна.
Но когда пытаешься найти комп по поиску - то получаем болт, пока не настроим сеть так, что обратно пакет идёт по тому же пути, по которому пришёл.
В чём может быть проблема?

в логах wireshark установленного на 192.168.2.5 имеем только вот что:
192.168.2.5 192.168.3.5 SMB Negotiate Protocol Request
192.168.2.5 192.168.3.5 SMB [TCP Retransmission] Negotiate Protocol Request

почему-то не приходит SMB negotiate protocol response... Буду изучать дальше, смотреть с той стороны, но может кто сразу подскажет, почему нетбиос не любит вот такую схему маршрутизации, ведь броадкастов нет нигде (я ж не по имени ищу)

 

[EricX]

DesKV, у вас используется WINS сервер(ы)? Если нет, то внедрение такового, полностью снимает проблемы поиска компов по именам NETBIOS. А ещё лучше полностью отказаться от NETBIOS и использовать чистый TCP/IP + DNS и обращаться к ресурсам как \\comp.domain.org\Resourse .

 

[DesKV]

к сожалению, wins не используется. Тут даже дело не в том, как избежать этой траблы (решить можно просто направив трафик в две стороны "одинаково"). Тут засада в том, что я наступил на грабли, получил по лбу и не пойму откуда... Хочется второй раз не наступить на них, с другим протоколом. Это получится, только выяснив в чём же дело тут обстоит.

 

[EricX]

Но когда пытаешься найти комп по поиску - то получаем болт, пока не настроим сеть так, что обратно пакет идёт по тому же пути, по которому пришёл.

Возможно в этом особенность виндового поиска по именам NETBIOS.

У меня другой вопрос? Зачем вам вообще нужен такой поиск?
Абстрагируйтесь от него.
Стоит задача получить на компе клиенте набор ресурсов от компов серверов.
Вместо того чтоб искать, браузить по сетевому окружению, может оказаться удобнее смонтировать(присоединить) ресурсы зарание (например при загрузке компа или при входе пользователя в систему) вручную перманентно или скриптом(батником)/групповой политикой динамически.

 

[Я]

а вариант все пустить через один шлюз и указать 2 ip на 1 сетевой?
Пример реализации на моем компьютере

Описание . . . . . . . . . . . . : VIA PCI 10/100Mb Fast Ethernet адап
тер
Физический адрес. . . . . . . . . : хх-хх-хх-хх-хх-хх
Dhcp включен. . . . . . . . . . . : нет
IP-адрес . . . . . . . . . . . . : 192.168.254.2
Маска подсети . . . . . . . . . . : 255.255.255.0
IP-адрес . . . . . . . . . . . . : 10.0.96.1
Маска подсети . . . . . . . . . . : 255.0.0.0
Основной шлюз . . . . . . . . . . : 192.168.254.1
DNS-серверы . . . . . . . . . . . : 10.0.0.1
192.168.254.1

Сетевая карта смотрит в сеть, где есть IP 10.x.x.x и 192.168.254.x
Основной шлюз это ADSL-модем и локальная сеть прописана через роуты

 

[EricX]

PEOPLEnet, ты рассуждаешь о маршрутизации IP пакетов. Всё верно, но тут идёт речь о маршрутизации NETBIOS дейтаграмм, которые работают поверх TCP/IP.

 

[DesKV]

Я просто не пойму какая разница для NetBios в случае симметричной или несимметричной маршрутизации. Даже на уровне TCP не должно быть видно (TTL же на уровне IP "отсчитывается"). Подозреваю один из шлюзов что-то "химичит".

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

 

[DesKV]

Как оказалось, дело было в керио. Конкретно причина в антиспуфинге.
Та же проблема возникла при маршрутизации, когда трафик принимается со спутника, а передаётся через модем. Отключение антиспуфинга помогло (или совпало, тогда время покажет).

 

[EricX]

DesKV, рекомендую всё же полностью отказаться от нетбиоса в сети, а обращаться а сети по хост именам. Не будет поиска, но если задействовать DNS, а ещё лучше сразу Active Directory - проблема будет решена, а дальше приимущества превзойдут недостатки.

 

[DesKV]

Согласен абсолютно.
Керио рубило даже rdp и rpс, а icmp каким-то чудным образом пропускало. Не пойму я это керио, загадочный винроут. У него еще есть "хитрости" в виде нерабочего nat ftp, при отключённой traffic policy. Поэтому, чтоб работал фтп на винроуте, нужно для ftp трафик полиси включать таки отдельно. (удивительно и странно).

 

[Alex Falcon]

DesKV, Странно... я создал специальное правило для rdp, работает. И, что подразумеваешь под "для ftp трафик полиси включать таки отдельно. (удивительно и странно)"???