включен форвардинг на хосте - это верно, но что на виртуалках с таблицей маршрутизации? с форвардинга толку не будет, если виртуалки не шлют на хост пакеты.
брандмауер на виртуалках выключен?
nomaster, они связаны через сетевой мост роутера. грубо говоря, через коммутатор.
где настраиваете iptables? где находится dns-сервер? написали бы хоть.
VROOM, да как вам сказать. по идее вам достаточно одного роутера с поддержкой wi-fi, тогда и второй IP покупать не нужно. просто воткнули бы в него провайдера, ПК, подсоединили бы по wi-fi ноут да настроили на роутере привязку MAC к провайдерсому IP.
но сейчас задача немного другая же: у вас 2 IP. RouterOS микротика умеет в несколько IP на одном порту, это я точно помню. а вот умеет ли RouterOS в несколько MAC на порту (у вас же привязка к MAC) - честно говоря, не в курсе. наверное, да. и задачу заюзать 2 провайдерских IP микротик в таком случае решит. но вот советов по поводу того, как это сделать, я дать не могу, кроме общих слов: повесить на порт, к которому подключается провайдер, 2 IP и 2 MAC, настроить внутренние подсети и NAT для обоих провайдерских IP-адресов, разнести подсети по разным VLAN.
я бы предпочёл, чтобы по микротику вам дали совет те, кто ими чаще пользуются - им легче написать вам конкретику.
VROOM, точка доступа - это точка доступа. если ваш роутер может работать как точка доступа (т. е. коммутировать проводной ethernet с беспроводным без использования маршрутизации), то он подойдёт. а если роутер обязательно требует, чтобы проводная и беспроводная сети находились в разных подсетях - то нет.
можно к примеру найти инструкцию по роутеру и поискать в ней насчёт этого вопроса, можно погуглить прямым текстом "<модель моего роутера> режим точки доступа".
скажем так: если у вашего роутера есть отдельный wan-порт и если ваш роутер позволяет отключить dhcp-сервер на lan-портах и если при подключении кабеля от провайдера в lan-порт, а ноутбука по wi-fi и при отключенном на роутере dhcp-сервере у вас есть через него выход в интернет с ноутбука, то ваш роутер может работать как точка доступа.
Kenny00, а, ну да, WINS...
DHCP работает? пишите, что работает. дело не в бродкастах.
тогда проверяйте, в принципе ходит ли трафик с dest port 137 (UDP и TCP) из сети в сеть. конечно, провайдеру резать эти порты, предоставляя при этом услугу транзита трафика организации, дико, но, возможно, это просто накладка с их стороны.
облегчить сниффинг через wireshark должен тот факт, что IP-адрес WINS сервера вам известен. запускайте wireshark на клиентской машине сети Б и на сервере сети A, пробуйте запросить чьё-либо имя с клиентской машины у сервера WINS, останавливайте захват и сравнивайте оба дампа, чтобы понять, всё ли дошло на IP WINS-сервера и вернулось назад.
Алексей Тутубалин, конечно нет. у каждого из них только по одному оптическому порту. DMC-F20SC-BXD от DMC-F20SC-BXU отличаются только частотами, на которых идёт приём и передача: в одном из них используется свет с длиной волны 1310 нм для передачи и 1550 нм для приёма, в другом же - наоборот. таким образом это парные устройства.
если хочется обязательно воткнуть все три "ресивера" в один "трансмиттер", то в его роли должен выступать, например, сетевой коммутатор с нужным количеством свободных оптических портов.
lilikon, всякое может быть, небольшие провайдеры "местного разлива", возможно, пойдут на встречу в этом вопросе. вообще же ухудшение предоставляемого качества или объёма (как в вашем случае) услуг провайдером - с их стороны не самый верный поступок.
Donald_Duck, зайти в оснастку служб (services.msc) в папке администрирования, зайти в службу сфинкса и посмотреть, от какого пользователя запускается служба во вкладке "вход в систему". если там указано "с системной учётной записью" - это пользователь "СИСТЕМА".
права на папку - в свойствах папки во вкладке "безопасность".
Илья Прибиль, для того чтобы запрос от B мог дойти до E при указанных данных (а именно - наличие маршрутизатора 1 между ними), должен соблюдаться ряд условий: B и E должны иметь IP-адреса из разных подсетей; B и E должны иметь маршруты в эти подсети, для которых маршрутизатором назначен маршрутизатор 1; маршрутизатор 1 должен быть настроен для работы с пакетами из подсетей, в которых находятся B и E.
если предположить, что эти условия выполняются, тогда:
- B формирует пакет для E:
-- проверяется IP-адрес назначения (IP-адрес E) на предмет того, находится ли он в той же подсети, что и IP-адрес источника (IP-адрес B) - не находится.
-- проверяется, есть ли в B маршрут до подсети, в которой находится IP-адрес назначения - есть, с маршрутизатором 1.
-- выясняется MAC-адрес маршрутизатора 1:
--- проверяется наличие в ARP-таблице узла B записи с MAC-адресом маршрутизатора 1 - допустим, его нет.
--- тогда рассылается широковещательный ARP-запрос MAC-адреса узла, у которого IP-адрес маршрутизатора 1, а именно формируется пакет с MAC-адресом источника (MAC-адрес B), MAC-адресом назначения (поскольку MAC-адрес ещё неизвестен - используется широковещательный MAC-адрес FFFF-FFFF-FFFF) и содержимым в виде ARP-запроса "какой MAC-адрес у узла с IP-адресом маршрутизатора 1?":
---- пакет с ARP-запросом уходит с B и попадает в свитч 6. если в MAC-таблице свитча 6 ещё нет записи о том, на каком порту висит хост с MAC-адресом узла B, то эта запись теперь появляется. свитч 6 рассылает этот пакет дальше по всем портам, кроме исходного, потому что этот пакет широковещательный.
---- пакет попадает на все напрямую связанные со свитчом 6 устройства (хаб 5, A, C). компы его отбрасывают, потому что их IP-адрес не соответствует искомому IP-адресу в ARP-запросе из пакета, хаб рассылает на все порты, потому что таким вот он дурачком уродился.
---- пакет попадает на комп I, где отбрасывается по той же причине, что и пунктом выше, и на свитч 2. если в MAC-таблице свитча 2 ещё нет записи о том, на каком порту висит хост с MAC-адресом узла B, то эта запись теперь появляется. свитч 6 рассылает этот пакет дальше по всем портам, кроме исходного, потому что этот пакет широковещательный.
---- ... таким образом пакет доберётся до маршрутизатора 1. этот маршрутизатор отвечает на пакет ARP-ответным пакетом с MAC-адресом источника (MAC-адрес маршрутизатора 1), MAC-адресом назначения (MAC-адрес источника из пакета с ARP-запросом), в котором говориться, что "у узла с тем IP-адресом, который вас интересует, MAC-адрес маршрутизатора 1".
---- пакет возвращается обратно на B через хабы (они рассылают пакет на все порты, в том числе и компам, которые их отбрасывают, потому что MAC-адрес назначения - не их адрес) и коммутаторы (в них уже имеется MAC-запись, в которой для MAC-адреса назначения был назначен соответствующий порт, когда через них проходил пакет с ARP-запросом, поэтому пакет с ARP-ответом они будут направлять именно в тот порт, из которого приходил ARP-запрос).
--- B получает ARP-ответ, из которого узнаёт MAC-адрес маршрутизатора 1.
-- в пакет, который всё ещё формируется узлом B для узла E, вставляется MAC-адрес источника (MAC-адрес B), MAC-адрес назначения (MAC-адрес маршрутизатора 1), IP-адрес источника (IP-адрес B), IP-адрес назначения (IP-адрес E), пакет отправляется.
- ... пакет проходит через коммутаторы и хабы тем же образом, что и предыдущий. записи с MAC-адресом назначения в MAC-таблицах коммутаторов уже имеются (появились, когда проходил ARP-ответ), так что коммутаторы отправляют пакеты на порт, в которых этот адрес фигурирует; хабы как всегда шлют пакет всем, но всем всё-равно. пакет приходит на маршрутизатор 1.
- маршрутизатор 1 берёт из пакета IP-адреса источника и назначения и смотрит, есть ли у него в таблице маршрутизации правило, в соответствии с которым ему следует переслать этот пакет. по условиям задачи мы решили, что такое правило есть.
- маршрутизатор 1 меняет в пакете от B к E MAC-адрес источника на свой MAC-адрес.
- маршрутизатор 1 меняет в пакете MAC-адрес назначения на MAC-адрес E:
-- проверяется наличие в ARP-таблице маршрутизатора 1 записи с MAC-адресом узла E - допустим, её нет:
--- ... происходит то же самое, что и было в подобной ситуации при отправке пакета с узла B: формируется широковещательный ARP-запрос, на этот раз во вторую подсеть, ну и так далее...
- ... пакет отправляется через коммутаторы и хабы второй подсети (по факту - через коммутатор 3, он там один) на узел E.
прошла половина милисекунды. хотя, если на каком-то из хабов возникла коллизия, то не факт.
брандмауер на виртуалках выключен?