LINUX.ORG.RU
решено ФорумAdmin

Глупый вопрос по конфигурированию микротиков

 , ,


1

1

Пытаюсь решить одну маленькую (на самом деле, нет) проблему с маршрутизатором mikrotik. Конфигурация сети следующая: интернеты — некий маршрутизатор в режиме nat (контроля над ним нет) — мой микротик — локалка микротика. До микротика проброшен VPN, хочется получить доступ к устройствам в его локалке через этот VPN. К несчастью, (1) он настроен бриджом, (2) он далеко, физическое пристутствие не канает, и (3) я, очевидно, слабовато шарю в сетях. Как можно перенастроить его с бриджа в адекватный режим, т.е. routing?

Пробовал осуществить это в модельной сети рядом, но неизменно оканчивалось неудачей: как я понял, нужно одновременно вывести один из интерфейсов из бриджа и включить на нем dhcp-клиент (потом еще включить dhcp-сервер в локалке и srcnat, но это можно позже); при выполнении одного из действий микротик отваливался по VPN.

Модель RB750Gr3, если это важно.

EDIT: мое решение.

★★★

Последнее исправление: lu4nik (всего исправлений: 1)

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

AS ★★★★★
()

Использовать Safe Mode в винбоксе. Если ошибешься - он откатится обратно через несколько минут. Ну и учить матчасть.

На каком действии он отваливается?

digitaldark
()

хочется получить доступ к устройствам в его локалке
До микротика проброшен VPN,
он настроен бриджом,

Может, я что-то не понимаю, но разве недостаточно при такой конфигурации прописать маршрут в сеть микротика на противоположном конце VPN?

Serge10 ★★★★★
()
Ответ на: комментарий от digitaldark

Да, открыл для себя safe mode, экспериментирование ускорилось. Отваливается на отключении WAN-порта от бриджа, если делать последовательно (сначала dhcp-клиент включить не на самом мосту, конечно, не получается). Пробовал применить следующую команду (4 — это индекс первого, т.е. WAN, интерфейса в списке портов):

/interface bridge port remove 4 ; :delay 3 ; /ip dhcp-client add interface=ether1 disabled=no

Результат: сейфмод откатил, но маршрутизатор пришлось вручную ребутать, чтобы подцепился обратно (его не видно ни из локалки, ни снаружи). Сообщений об ошибках не видно. Видимо, я что-то забыл в этой команде.

lu4nik ★★★
() автор топика
Ответ на: комментарий от Serge10

Идея иметь контроль над подсеткой микротика. Другой (вышестоящий) маршрутизатор нет возможности как-то контролировать, а значит есть опасность, что после потери питания везде придется опять искать, какие же адреса были выданы.

Алсо, OpenVPN включен как Layer-3, а не Layer-2, поэтому просто маршрутом не обойтись.

lu4nik ★★★
() автор топика
Ответ на: комментарий от AS

Но это не приближает к решению никак :) Разве что после вываливания в сейфмод микротик не тупит с получением адреса по DHCP, а сразу оживает. Опять же, я не вижу вывода, так что без понятия, прошли ли в действительности эти команды или нет.

lu4nik ★★★
() автор топика
Ответ на: комментарий от lu4nik

Но это не приближает к решению никак :)

Почему же? Сделай всё на стенде, раз он есть у тебя, потом всю последовательность разом на дальнем микротике выполни. И в Safe Mode, чтобы откатилось, если что, раз он так умеет (я тоже не знал, кстати).

AS ★★★★★
()
Ответ на: комментарий от AS

Почему же?

Вообще-то я как раз пытаюсь найти работающую последовательность, пока безуспешно.

lu4nik ★★★
() автор топика

Похоже, проблема более-менее решена. Идея в том, чтобы создать отдельный бридж для единственного WAN интерфейса, переключить ether1 на него, отключить dhcp-client на LAN бридже, включить dhcp-client для WAN «бриджа». Мои команды (4 – это индекс внешнего интерфейса в выводе /interface bridge port print).

/interface bridge add name="wan_pseudo"
/ip dhcp-client add interface="wan_pseudo"
# The following SHOULD be executed as a one-liner
/interface bridge port set 4 bridge="wan_pseudo" ; /ip dhcp-client set 0 disabled=yes ; :delay 2 ; /ip dhcp-client set 1 disabled=no

Переконфигурирование не требует перезагрузки и не отваливает SSH сессию через VPN.

Правда, необходимость бриджа из одного интерфейса пахнет костылями, но у меня не получилось провернуть то же самое не с дополнительным бриджом, а непосредственно с ether1.

lu4nik ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.