Russian Users MikroTik | Форум пользователей MikroTik

Здравствуйте, уважаемые.
Пытаюсь найти самое надёжное и самое правильное решение для поставленной задачи.
Надо объединить 3 офиса которые работают с одним внешним сервером. Офисы маленькие, не больше 30 клиентов, по этому думаю адреса выдавать вообще из одного диапазона, пусть видят друг друга. То есть как я понимаю поднимается на сервере РРТР-сервер и к нему подключаются три микротика RB3011. Особенность офисов в том, что интернет везде дохлый, падает переодически, но как я понимаю линк будет подниматься обратно. Правильно ли я понимаю, что это решение одно из лучших, или у кого то есть опыт более крепкого решения?

Я выскажусь от себя: решение Ваше я бы использовал как вариант номер 4 или 5.

1) При плохом соединении зачем Вам делать одну подсеть?
1.1) При использовании одной подсети - 10-15% этого канала будут задействовано под бродкасты и тому прочее. Зачем
1.2) При шторме бродкастом - положите сетки все...
2) Зачем Вам туннель(и) сеансового типа? (сеансовые туннели это туннели PPTP,L2TP,SSTP)
2.1) Пойдите по минимальному пути, поднимите туннель не сеансового уровня (это IPIP, GRE, IPIP самый при самый простой)
2.2) Если туннели не сеансового уровня покажут себя хорошо на Ваших каналов - можете потом "навесить" в них шифрование.
3) Протокол РРТР - официально был не раз взломан(скомпроментирован).
4) Офисы должны иметь разную IP-адресацию, чтобы опять при падении туннелей, офис в рамках одной единицы не терял
рабочее подключения, компьютеры работали, и обслуживались локальным роутером....то есть в рамках падения
связи, локальная работа не приостанавливается.
5) Ну и чтобы сделать связку туннелей и офисов и т.д. - естественно надо использовать маршрутизацию (статическую),
с явным описанием маршрута до внешнего сервера через головной офис.

Согласен с вами, сеансовый немного странно, но сеанс же держится пока канал есть, и восстанавливаться должен, когда линк возвращается. Согласен, странновато, но я о нём думал из-за "лёгонького" шифрования, чтобы не открытым текстом и не нагружать микротик. В одну подсеть конечно хотелось больше для красоты, но про бродкастовый шум я даже не подумал.
Головного офиса нет, все офисы равнозначные, главное это доступ до сервера с приложением. Только что обнаружил, что ещё все запросы просто в интернет пойдут через сервер, тоже не очень хорошо.
Всю голову уже сломал, поиск не даёт адекватных ответов, вроде задача не уникальная, где эта золотая пуля.

1) при разрыве не важно, сеансовый или не сеансовый туннель, нету связи - всё рвётся, а при восстановлении - поднимается,
всё имеет разные интервалы и таймауты, и кстати...я пару раз замечал...что у меня ВПН-клиент при разрыве так быстро пытается
перевосстановить связь, что микротик ругается, мол пытается вторую сессию создать (обрыв клиент увидел и делает переконнект,
а микротик как сервер - ещё не понял что клиент отвалился...и держит его и тут стучится клиент как уже второй...а это запрещено...)
так что сеансовые туннели в этом контексте это минус

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

3) Зачем в одну сеть если офисы равноправны, ну а на счёт сетевого окружения - да мало кто его юзает, проще ярлык сделать или по айпи адресу зайти,
если так уж надо. Да и как будете контроллировать адресацию, если будет адресация одна, на все филиалы, то как DHCP будет знать кто есть кто нету,
если с одним филиалом связь оборвётся, ну скажем филиал 2 пропал, там есть компьютеры с адресами 10, 40, 75 и 100, связи с филиалом нету,
DHCP думает что всё, адреса свободны, и даёт такие адреса первым вновь подключившимся и тут бац и через 5 минут ещё и связь с филиалом восстанавливается -
как итог, конфликт адресов...вылет компов, и не рабочая ситуация.
Поэтому никакой общей сети и общего бродкастового домена, три филиала, три разные подсети, маршрутизацией всё расписать, на каждом микротике
поднимаете свой DHCP (локальный) и всегда он будет работать и делать свои функции.

4) Офиса головного нету, но там где будет сервер или выход на этот сервер - можно этот филиал условно и объявить главным,
ибо маршрутизацию всё равно придётся строить что все филиалы должны будут попадать на какой то филиал где стоит этот сервер или
на тот филиал через который они на сервер и будут попадать...

5) На счёт запросов и Интернета...в Ваших условиях ничего про это не было, но тут тоже опять же два пути:
а) каждый филиал работает со своим интернетом (разруливается)
б) каждый филиал для работы в глобальном интернете попадает на какой то условный офис, оттуда уже в сам Интернет.
(опять же, маршрутизация и статика)

На счёт поиска - готовых решений нет, есть кубики,кирпичики - из них и надо делать...

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

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