Адресация по именам - хорошая вещь, надо делать именно так. Но на данный момент это тоже означает перенастройку всей сети.
Через отдельный роутер - это доп. задержка, но пришлось делать именно так потому что решения с одним роутером не нашел.
Понятно что можно всех клиентов перевести в другую подсеть, но как раз этого хотелось избежать из-за необходимости изменения конфигуации как самого роутера, так и клиентов (например комп ходит на ноут, а теперь IP поменялся и т.д.)
Идею описывал в четвёртом комментарии под ответом @karabanov
Если так возможно сделать, то подскажите, пожалуйста, как этого достичь. Думал про VLAN-ы, я никогда не работал с ними, но это вроде не то.
Мой телефон будет в brigde_main, он будет внутри.
Вообще идея была такая - есть "внутренняя" сеть, там своя адресация (192.168.0.1 и др). Для этой сети есть какой-то default gateway, через который запросы идут на "внешннюю" сеть, где своя адресация (не важно какая, даже 192.168.0.1).
То есть иметь две непересекающихся сети, между которыми стоит NAT. И если сети не пересекаются то можно в разных сетях иметь одинаковые IP и благодаря NAT всё будет работать.
Во внутренней сети у телефона будет адрес 192.168.0.117, у роутера - 192.168.0.1. Во внешней сети у роутера будет тот IP, который мне выдаст роутер соседа, например 192.168.0.200, а у роутера соседа 192.168.0.1.
Соответственно если я внутри brigde_main хочу пойти на 192.168.0.117 то я иду внутри бриджа. Если я хочу пойти на 1.2.3.4, то иду на default gateway, прохожу через NAT во "внешнюю" сеть и иду уже на роутер соседа, который может иметь какой угодно адрес, даже 192.168.0.1, но так как это другая сеть, то она не пересекается с внутренней сетью, в которой мой телефон
Мне кажется это не поможет потому что адрес роутера соседа всё равно будет попадать в маску внутренней сети
Пока что временно сбросил роутер до умолчания и переделал адресацию внутренней сети, так всё работает без проблем.
Сделал как вы написали, не помогло.
Я так понимаю что когда роутер пытается найти адрес 192.168.0.1 чтобы завернуть туда трафик, то он идёт по роуту, который создан бриджем автоматически, с дистанцией 0, находит сам себя и дальше, на роут с дистанцией 1, созданный автоматически DHCP-клиентом (либо описанным вами способом), уже не идёт.
Я не могу поменять роут, созданный бриджем, а если создам ещё один роут, то он не будет иметь влияния потому что дистанция будет больше 0.
PS
спасибо за совет
стараюсь имена интерфейсов не менять, кроме wifi, потому что wlan2.4 и wlan5 имхо проще различать чем wlan1 и wlan2
Gregory, потому что благодаря VPN я попадаю во внутреннюю локальную сеть, из которой я могу получить доступ к нужному серверу только на порт SSH, остальные порты закрыты. Соответственно чтобы получить доступ к другим портам я сейчас через SSH захожу на сервер и подключаюсь к localhost:4321
Спасибо за ответ. Действительно, у mikrotik есть встроенный ssh client. Спасибо, не знал.
Даже получилось им подключится к моему серверу, правда пришлось пошаманить с сертификатами: сгенерированные маком не принимал, говорил что неверная passphrase. Нашел в интернете эту проблему, там советовали генерировать сертификат с -m PEM, помогло.
Но я не вижу в этом клиенте возможности создавать туннели. Среди параметров есть routing-table, но не могу найти по нему документации. Может вы что-то подскажете, в какую сторону смотреть?
Спасибо за ответ. Нет, сервер не RDP.
В статье предлагается интересное решение, но оно решает другую проблему.
Я хочу зайти на IP_РОУТЕРА:1234 и увидеть сервис на 192.168.1.2:4321, т.е. роутер должен это соединение сам "обернуть" в VPN и SSH-туннель.
Оборачивать соединения в VPN роутер уже умеет - я могу сделать ssh 192.168.1.2 и, так как я указал роутеру что gateway для этого IP это VPN, это соединение будет "обёрнуто" в VPN. Но SSH-туннель, видимо, на mikrotik сделать нельзя.
Stalker_RED: Согласен, всё меняется очень быстро, особенно фронтенд разработка. И хочется сегодня написать такое, за что не будет стыдно через пару лет. Поэтому и спрашиваю совета у умных людей.
yurygolikov: Вот и я об этом. Но не всё же теперь рендерить на клиенте. Вот вопрос в том, что нужно делать на серве, а что на клиенте? Вернее даже, что должен уметь сервер? Статика+API, или рендеринг шаблона HTML-страницы (для последующего до-рендера клиентом), или рендер страницы полностью? большинство (я в том числе) склоняются ко второму варианту, но нужно понять, что именно должен обрабатывать сервер, а что клиент?
yurygolikov: SSR не подходит, тк у меня сервер не на nodejs, а отдельно держать инстанс node для SSR, плюс настраивать взаимодействие с имеющимся сервером, мне кажется довольно проблемно.
По поводу SPA: погуглил и понял, что я уже делал такое приложение, там действительно была одна index-страница и набор template-ов для фрагментов страницы. Там и роутинг и авторизация была на клиенте. И я понимаю как можно сделать чтобы для неавторизованного пользователя не тянулся весь проект (как написал Иван Стройкин), а только нужная часть. Но вопрос в том, стоит ли делать именно так? Сейчас я делаю не одностраничное приложение, хотя основные части у каждой страницы будут похожи – тот же header, footer, набор скриптов будет отличаться одним-двумя. Вот в этом и вопрос: стоит ли всё это хранить как разные страницы на сервере, или всё же рендерить на клиенте?
Через отдельный роутер - это доп. задержка, но пришлось делать именно так потому что решения с одним роутером не нашел.