Понимаю маршруты…

Хм, давайте в этот раз не усложнять настройку с кучей роутеров. У меня один роутер, eth1 - local1 - 10.0.0.1, eth2 - local2 - 10.0.1.1, eth3 - public - 10.5.1.1. Самый простой способ пропинговать с local1 на local2 - использовать маскарадинг на исходящем интерфейсе = eth3 = public. Просто пингуется. Но давайте забудем про маскарадинг. Хочу узнать простые маршруты, которые нужно добавить, чтобы пинговать с local1 на local2 и обратно. Кстати, что значит, когда добавленный статический маршрут отображается красным цветом в WinBox? Это значит, что он недействителен? Спасибо, Петр.

Ок, правило красного маршрута — понятно. Попробую использовать гейтвеи Я просто подумал, что для того, чтобы local1 и local2 могли взаимодействовать друг с другом, нужно как-то определять пункт назначения и предпочтительный источник. Поэкспериментирую с маршрутизацией и NAT, как только получу следующую RB, потому что сейчас у нас всё установлено, и не хочется ничего ломать в текущей сети. Всего доброго, Петр.

Удаленный роутер не знает, где твой ПК – думаю, если ты попробуешь пинговать свой ПК с этого удаленного роутера, то получишь "no route to host". Добавь правильный маршрут к удаленному роутеру!

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

Для напрямую подключенных сетей MT автоматически создает информацию о маршрутизации и помечает её как "D" в таблице маршрутизации. Например, когда вы добавляете адрес 10.0.0.1/24 к eth1, MT автоматически добавляет запись в таблицу маршрутизации, чтобы любые пакеты с адресом назначения от 10.0.0.1 до 10.0.0.255 отправлялись через интерфейс eth1.

С маршрутом по умолчанию вы даете роутеру имя хоста, куда отправлять пакеты, когда у него нет другой информации для адреса назначения пакета. Например, скажем, у нас есть другой роутер с адресом 10.0.1.1/24, подключенный к интерфейсу MT eth2, который может выйти в интернет. Мы устанавливаем маршрут по умолчанию на 10.0.1.1, и тогда пакеты с любым адресом назначения, отличным от 10.0.0.0/24 или 10.0.1.0/24, отправляются на 10.0.1.1 через eth2. Надеюсь, это поможет.

Да, это немного помогает. У всех наших машин ОС — только MT. Поэтому мне нужен обратный подход: я хочу, чтобы клиенты из сети 10.0.0.0/24, которые проходят через 10.0.0.254 (интерфейс wlan1 MT), могли пинговать 10.0.5.2 на удалённом MT-боксе, который подключен к нашей машине к интерфейсу wlan2 10.0.5.1.

MT-remote-node[wlan-remote-cl(10.0.5.2)] <—> MT-main-router[wlan2-AP (10.0.5.1), wlan1-AP(10.0.0.254)] <—> [Клиенты ПК(10.0.0.x, шлюз установлен на 10.0.0.254) - пинг 10.0.5.2 здесь… Я могу пинговать только до 10.0.5.1, но не дальше]

Надеюсь, теперь я близка к определению статического маршрута. Я пыталась определить его так: destination=10.0.5.0/24, gateway=10.0.0.254, это было принято, у него была метка S, он был синего цвета, но интерфейс отображался как неизвестный. Шлюз 10.0.0.254 на самом деле мост двух 2,4-х WLAN-радио.

Петр

Ну ладно. Просто на удалённом компьютере (10.0.5.2) шлюз по умолчанию (GW) установлен на 10.0.5.1, так что пакет хотя бы должен вернуться на 10.0.5.1… Ладно, попробую (забываем пока про синтаксис, в консоли не очень работает): на MT-main-router-box: /ip route add dst-address=10.0.5.0/24 gateway=10.0.0.254 на MT-remote-node-box: /ip route add dst-address=10.0.0.0/24 gateway=10.0.0.5.1 (или 10.0.0.5.2?)? Кстати, для чего нужно поле preferred source? -pekr-