Для разгрузки основного интернет-канала было решено часть пользователей в тестовом режиме пересадить на кабель другого провайдера, для этого приобрели Trendnet TW100-BRF114 (его возможностей на первый взгляд было достаточно). Внутри своей подсети эти пользователи работают прекрасно, вопросов нет, но связи с другой подсетью (основной), подключенной в один из LAN-портов TW100-BRF114 (конкретно — в четвёртый) нет.
Настройки сети следующие:
— основная подсеть 192.168.62.0/24, шлюз — 192.168.62.1 — её трогать нельзя, всё настроено и работает, изменения в конфигурации крайне нежелательны,
— WAN роутера второго провайдера — статический IP,
— NAT роутера второго провайдера — 192.168.65.0/24, шлюз — 192.168.65.1
— прописанные маршруты TW100-BRF114 второго провайдера — 192.168.62.0/24 со шлюзом 192.168.65.1.
Возможность обеспечить такую связь у роутера, по-идее, есть (присутствует возможность прописать статические маршруты в другие сети), но де-факто проброса пакетов нет. После долгого-долгого ожидания таки удалось дозвониться до техподдержки Trendnet, где с 80% уверенностью в голосе мне сказали, что поддержки такой нет.
Вопрос: правильно ли я вообще сформулировал вариант решения вопроса и каким образом с наименьшими затратами можно решить поставленную задачу? Спасибо заранее.
P.S. Описанный маршрутизатор был возвращён продавцу, поэтому приветствуется вообще любое работающее решение; желательно, конечно, доступное с минимальными затратами.
То есть при использовании RouterOS я могу без особых проблем настроить проброс пакетов из одной [под]сети (моей 192.168.65.0/24) в стороннюю [под]сеть (192.168.62.0/24) и проброс ответы обратно при том, что один из LAN-портов будет сконфигурирован, как WAN со статическими настройками? Коллизий никаких не будет происходить? Уточняю, потому что покупка второго оборудования, не отвечающего требованиям для решения задачи, будет некрасиво выглядеть…
Да там на порту линукс и можно сделать маршрутизацию любой сложности, включая динамическую. Возможно и на указанной вами железяке это сделать можно, но я с ней дел не имел. Вообще для линукса два WAN решается очень просто
Разбиваем шлюзы по таблицам (для удобства номер таблицы соответствует третьему откету)
ip route add default via ХХ.НН.105.1 table 105
ip route add default via ZZ.TT.107.1 table 107
Добавляем правила, пускаем каждую сеть через свой интерфейс
ip rule add from сеть1 table 107
ip rule add from сеть2 table 105
В принципе практически любой роутер потянет эту задачу, если есть доступ к его операционке. Там вариантов решения вагон, можно фаирволом, можно множественные таблицы маршрутизации использовать, можно разный нат для разных подсетей. Вообще мой совет, если фря уже есть на данный момент тупо сделать на ней и не парится. Туда подключаем обоих провайдеров (можно виланом через свич и в одну сетевую даже) выход в тот же свич в другом вилане, туда же клиентов. А там уже самое простое или через setfib или через nat решить кого куда.
В организации не будет даже мало-мальски серьёзного трафика по этим направлениям, поэтому даже RB750 с его 10/100 хватит. За ссылку — спасибо, почитаю.
Смотрите не на скорость портов, а на скорость процессора.
800мгц в rb750g мне хватало на 35мбпс нат+шейпинг+нетфлоу для 60-70 клиентов онлайн.
У рб750 процессор вдвое медленнее.
На этом Микротике будет сидеть человек 20 от силы, скорее всего — даже не больше 15ти, при этом из сервисов будет активен только NAT. Но всё равно приятно видеть такую заинтересованность в развёртывании полной картины для вопрошающего, чёрт побери! :)
А что это за маршрут такой: «192.168.62.0/24 со шлюзом 192.168.65.1» если 192.168.65.1 это адрес на этом же роутре?
Вообще на втором роутере нужно прописать ip из 192.168.62.0/24. А маршрут делать на превом роутере в сеть 192.168.65.0/24
Интересное решение, спасибо, но мне не подходит. Основной провайдер заводится через ADSL на машину с FreeBSD, которая древняя настолько, что настраивать там что-то я не возьмусь (мопед вообще не мой — всего лишь помогаю по мере возможностей, сам Фрю уже лет 10 как не трогал, да и тогда был не особо любитель), а спецов нанимать никто не будет и экспериментировать никто не даст. Плюс, кабель второго провайдера заходит и заканчивается в другом конце здания, и законнектить его в «сервер» с имеющимися условиями физически невозможно.
А что это за маршрут такой: «192.168.62.0/24 со шлюзом 192.168.65.1» если 192.168.65.1 это адрес на этом же роутре?
Это такая система написания маршрутизации в роутерах Trendnet — роутить в 192.168.62.0/24 через 192.168.65.1, в хелпе вебморды прямо так и сказано, перевод: «В поле ШЛЮЗ указывайте IP-адрес текущего маршрутизатора (не того, который обслуживает сеть, куда производится маршрутизация)»
Вообще на втором роутере нужно прописать ip из 192.168.62.0/24. А маршрут делать на превом роутере в сеть 192.168.65.0/24
На какой интерфейс 2-го прописать IP из x.x.62.0/24? Первый «роутер» — FreeBSD, там обязательно что-то настраивать? Как я понимаю, х.х.62.0/24 приходит кабелем во второй роутер, как в обычный свич, FreeBSD должно быть всё равно, от кого конкретно на той стороне пришёл запрос — это обрабатывает именно коммутатор на месте (иначе не работало бы ветвление сети обычными свичами). То есть уметь пробрасывать пакеты в стороннюю сеть и пробрасывать ответы обратно — это, в моём случае, всецело задача второго роутера. Я неправ?
Странный синтаксис, интересно как это работает?
Разберем по порядку:
1. Комп из сети 192.168.65/24 хочет попасть в сеть 192.168.62/24. Это не его сеть, значит он отправляет пакет на мак адрес шлюза, при этом в заголовках у него адреса назначения из сети 62, а источник из 65.
2. Шлюз (это наш Trendnet) получает такой пакет и смотрит в заголовки. Видит там 62ю сеть. В обычной конфигурации он направляет ее по дефолтному маршруту. Те в сеть провайдера.
3. Сеть провайдера дропает пакет.
Нам нужно чтобы на шаге 2 роутер знал где живет 62я сеть. Указав маршрут в 192.168.62.0/24 через 192.168.65.1 мы ему как бы говорим, чтобы направить пакет в сеть 62 тебе нужно послать ARP запрос для 192.168.65.1 и подставить полученый мак в L2 заголовок и отправить пакет. Очевидно, что это не работает (Может техподдержка прокоментирует почему они хотят видеть в этой строчке именно IP текущего маршрутизатора)
Я же предлагаю, если есть такая возможность повесить secondary IP на тот же интерфейс где висит 65.1. Тогда на втором шаге роутер будет знать, что 62я сеть подключена к нему и отправлять пакеты по назначению. Маршрут же на фрибсд нужен для ответных пакетов. Т.к клиент из 62ой сети получив пакет из 65ой сети ответит так же на шлюз (см п1), и фрибсд должна знать через какой ip ей добраться до 65 сети. И скорее всего она пошлет клиенту ICMP redirect ;)
Понял, любопытно :)
Но факт остаётся фактом — они хотят видеть ситуацию в описанном выше свете. Звонить в Тренднет уже нет ни малейшего желания, т.к. дозвониться до них я смог только на 4-ю неделю кряду, а на письмо, отправленное на второй день после осознания проблемы, не ответили вообще. Естественно, что я не названивал 24/7, но и их АТС не давала мне висеть дольше ~2 минут: сообщала о занятости, предлагала перезвонить попозже и бросала трубку. Однако после того, как я всё-таки дозвонился, мне сообщили, что уже видели моё письмо в поддержку (где ответ, спрашивается?)
Короче, дозваниваться до них мне откровенно лень.
Решил пойти по пути Микротика, занятная всё-таки железяка :)
Простой
