Да, к сожалению это так. Но, более менее приемлимой стабильности можно добится используя связку — стабильная сборка OpenWRT/Netwatch. Или решать задачу внешним ресурсом. Тут, как говорится — цена вопроса.
Думется, потому что, на данном изделии в качестве протокола используется TCP, который более «удобен» на нестабильных каналах. Кто мешает поднять два демона на разных протоколах и портах? У меня два — тот, что висит на TCP:443 я рекомендую тем пользователям, что используею канал WiFi/мобильных операторов для доступа к сети.
Если камень 64, то попробуйте DietPi — очень френдли сборка. Изначально под малинку, но есть под РС. Заложена установка профильного софта — создать медиатанк, файловый сервер, десктоп и т.д. Работает с флэшки.
Много букав, да. Забросить на рабочие станции и ТС глобальный конфиг для Firefox, где задушены все излишества и прописан прокси. Прикрутить к Squid авторизацию из домена (через auth_param basic program squid_ldap_auth), антивирус (через icap) и SAMS (для управления пользователями и статистики). И, ИМХО, все.
Вот не знаю как сейчас, но некоторые годы назад был программный пакет под названием pGina. И реализовывал он функции создания локальных уч. записей через администрирование центральной базы. Т.е. админ создавал в базе запись и при первом логине в системе клиент данного ПО создавал локальную запись в системе. Причем типов баз было несколько, вроде как mysql и еще что-то.
Конечно. Сразу скажу, что мои рекомендации совершенно не претендуют на абсолютную истину. Всего лишь выжимка из опыта и знаний.
1.Не нужно ставить сразу новейшую прошивку. Исходя из разумной достаточности, нужно поставить последнюю предыдущую, ибо в ней уже пофиксены многие баги. У Микротика сейчас 6.40.1, значит берем 6.39.4.
2.Ставить на удаленную площадку не обкатанную железку — моветон. Ибо высока вероятность мучений на объекте. Также, вероятность отказа электронного оборудования (из моих знаний) распределяется следующим образом: первые 14 дней вероятность отказа высока (заводской брак), следующие 3-5 лет вероятность отказа низка, далее — вероятность отказа высока. Отсюда вывод — перед установка в продакшен обкатать хотя бы неделю на стенде.
3.Нехороших людей в сети много, поэтому, второе, что нужно сделать после запуска интерфесов и маршрутизации — прописать «жесткий» ACL, разрешить только явно нужное, остальное запретить. Из локальной сеть — reject, из публичной — drop.
Неплохо повесить на внешний интерфейс правила считающий кол-во SYN пакетов в единицу времени и добавляющие в некий список src ip. Следующим правилом дропать пакеты с src ip из созданного списка.
4.«Маршрутизацию между подсетями Mikrotik добавит автоматически и будет осуществлять силами switch-чипа, тем самым не создавая нагрузку на процессор» — с моей точки зрения — абсурд. Свитч — устройство второго уровня и маршрутизацией заниматься не умеет, его задача коммутировать кадры между портами на основании MAC адресов, у вас на уст-ве один сетевой интерфейс, поэтому речь про коммутацию идти как-бы не должна, ибо у Вас IP адреса, а это третий уровень. С моей точки зрения все пакеты пойдут в ядро. И как правильно замечено выше — перейти из сети в сеть не составит труда и каждая сеть будет флудить другую широковещательными пакетами. Если это Ваш конечный вариант, то правильнее, ИМХО, прописать на внутреннем интерфейсе правила форварда разрешающие пакеты только между внешним и внутренним инт., а пакеты из внутреннего инт. во внутрениий (т.е. остальные) — дропать.
Конечно, софт на Вашем уст-ве может выступать в роли маршрутизатора, но вешать на него несколько сетей нехорошо, если нужно реально разделить внутрение сети, то правильнее поставить после него коммутатор третьего уровня или много-портовый маршрутизатор. VLAN дело конечно хорошее, но в Ваших условиях, мне кажется лучше не станет, поскольку трафик из транка все одно придет в ядро и ему придется решать, что с ним делать (исключая широковещательный трафик, который останется в своем вилане.)
5. Ваше уст-во содержит направленную антену, не «омни». Если у Вас сота на расстоянии 100 метров, то это все, если же вы «пробиваете» километр и больше, то необходимо задуматься о точном выставлении на соту и о зонах Френеля. Об этом ни слова.
Пойдет снег, сильный дождь и качество канала просядет — нужно принять превентивные меры, что бы избежать «отказа в обслуживании».
7.Ничего не сказано про VPN. А это важно, в особенности при использовании радиоканала, который не очень хорошо «переносит» большие пакеты. Хотя если у вас просто доступ из локалки к сайтам, то это не нужно. MTU на внешнем инт. я бы «зажал», хотя бы до 1000. «Вялый» канал все же лучше, чем канал с «дропами».
8. И последнее — из Вашей статьи сложно почерпнуть, что то иное, кроме инструкции и ФАК'а на уст-во.
А посоветуйте альтернативу, плз, в той же ценовой и аппаратной нише.
И,
Не могу сказать, что гуру в MikroTik, у меня их всего штук восемь на хозяйстве, но ИМХО, автор статьи слаб в сетях и системном подходе, ляп на ляпе, я бы не посоветовал данную статью как источник информации.
И,
По поводу производительности, буквально вчера гонял стенде два RB3011, порт в порт — IPSEC, на внутреннем генераторе трафика, UDP/TCP, packet size 1000, скорость в пределах 37Мб/сек в одном направлении, в двух ~22Мб, загрузка одного ядра — 100%, второе в простое, RouterOS 6.39.4
Нет, я не забыл — я упоминать не стал, вроде как известная уже, набившая оскомину, вещь. При поднятии системы все %TEMP% %TMP% перенаправляю в c:\temp. И раз уж разбор по косточкам — необходимо разрешить запуск *.lnk
И — Win с начало времен сильно «гадит» в «темп», и плохо прибирает за собой. «Темп» в рамдиск.
Совершенно верно, OpenVPN и иже сним позволяют решать множество задач. Если Вы ставили своей задачей составить хитроумное решения для тренировки интеллекта, то Вы сделали это прекрасно. Если же Вы ставили целью решить определенную задачу для продакшена, то извините, вычурно и избыточно, ИМХО.
И да, поднять контроллер AD стоит даже для такой задачи, виртуализация возможна сейчас практически на любых плаформах и ресурсах. Кроме всего прочего, можно использовать для авторизиции для Squid, Socks, Wi-Fi и т.д.
Напоминает изобретение велосипеда, ИМХО.
Привязываем OpenVPN к базе AD через openvpn-plugin-auth-pam.so и живем спокойно.
Не замучаетесь на личных уст-вах пользователей ставить сертификаты? Особенно для планктона.
Правильнее, ИМХО, один сертификат на всех + пароль/логин при подключении.
Какой смысл создавать под каждого пользователя правило в пакетном фильтре?
Правильнее, сертификаты и ключи пользователей прописывать в файле конфига пользователя, как уже было предложено ранее.
Используйте tls-auth для предотвращения тупого долбления на сервер.
Затем, все пользовательские данные — инсталлятор клиента, конфиг, RDP файлы сворачиваются в самораспаковывающийся архив со скриптом, переписывающим все в нужные каталоги на компе пользователя и выкладывается на FTP/HTTP сервер.
У меня есть велик, скутер и гироскутер. Я никогда не выеду на гироскутере на тротуар или в общественное место. Это уст-во устойчиво движется только на связке человек+электроника — любой толчок или неровность дороги приводит непредсказуемому движению уст-ва. Кому нормальному придет в голову выводить такое уст-во на дорогу или тротуар? Думается, это уст-во для развлечения в местах отдыха или передвижения по протяженным участкам на производстве. Тем более, при использовании гироскутера, довольно приличная статическая нагрузка на икроножные мышцы.
Так что лозунг двигать сегвеи/гироскутеры в массы выглядит довольно странным.
Для единичных подключений использовал PPtP. На нужном сервере/маршрутизаторе/etc настраивается подключение, запускаемое при старте. В центре стоял выделенный маршрутизатор с поднятым PPtP сервером, к учетке привязан IP (использовал Микротик). Просто как палка/веревка.
Да, так и есть. Я системный администратор в довольно крупной компании, работаю в данной должности более 15 лет. На граничных маршрутизаторах вначале идут правила разрешающие доступ к определенным внешним ресурсам, последним правило запрещающее все. Опять же, опытный администратор болшей частью знает, что нужно для правильного течения бизнес процессов, остальное дошлифовывается с руководством.
И таки да, под желанием «свободы» в инете существует огромное кол-во «грязи». Кому она нужна? Думается, для текущих любителей «грязи» и взращивания себе подобных, ИМХО.
Согласен на все 100%. Немного дополню из продакшена:
Бсервер на Linux.
На источниках данных шаринг правами RO.
bash скрипт, монтирует шаринги, забирает данные rsync на основе различия размера и времени модификации.
12 (4+4+3+1) внешних USB 3.0 дисков с luks.
Доступ к Бсервер только у админов по ssh-sftp/ключи.
После создания суточного бэкапа сервер выключается, будится биосом в нужный момент бэкапа.
Админ по потребности будит сервер через wol
2.4/5 Гц не проходят сквозь проводящие/слабопроводящие материалы и практически не огибают препятствия. Распространяются они большей частью переотражением. Используйте воображаемый фонарик для представления попадания излучения в нужную точку. Поставьте AP в самом многолюдном помещении, возмите что-то вроде Wi-Fi Analize и передвигайтесь в то место, где хотите получить устойчивый сигнал — если уровень не достаточный (менее 65)- ставьте в этом месте еще одну AP. После распределения AP по помещениям разведите их по не пересекающимся каналам — если на первой канал 1, то на следующей рядом расположенной должен быть 4 и т.д.
1.Не нужно ставить сразу новейшую прошивку. Исходя из разумной достаточности, нужно поставить последнюю предыдущую, ибо в ней уже пофиксены многие баги. У Микротика сейчас 6.40.1, значит берем 6.39.4.
2.Ставить на удаленную площадку не обкатанную железку — моветон. Ибо высока вероятность мучений на объекте. Также, вероятность отказа электронного оборудования (из моих знаний) распределяется следующим образом: первые 14 дней вероятность отказа высока (заводской брак), следующие 3-5 лет вероятность отказа низка, далее — вероятность отказа высока. Отсюда вывод — перед установка в продакшен обкатать хотя бы неделю на стенде.
3.Нехороших людей в сети много, поэтому, второе, что нужно сделать после запуска интерфесов и маршрутизации — прописать «жесткий» ACL, разрешить только явно нужное, остальное запретить. Из локальной сеть — reject, из публичной — drop.
Неплохо повесить на внешний интерфейс правила считающий кол-во SYN пакетов в единицу времени и добавляющие в некий список src ip. Следующим правилом дропать пакеты с src ip из созданного списка.
4.«Маршрутизацию между подсетями Mikrotik добавит автоматически и будет осуществлять силами switch-чипа, тем самым не создавая нагрузку на процессор» — с моей точки зрения — абсурд. Свитч — устройство второго уровня и маршрутизацией заниматься не умеет, его задача коммутировать кадры между портами на основании MAC адресов, у вас на уст-ве один сетевой интерфейс, поэтому речь про коммутацию идти как-бы не должна, ибо у Вас IP адреса, а это третий уровень. С моей точки зрения все пакеты пойдут в ядро. И как правильно замечено выше — перейти из сети в сеть не составит труда и каждая сеть будет флудить другую широковещательными пакетами. Если это Ваш конечный вариант, то правильнее, ИМХО, прописать на внутреннем интерфейсе правила форварда разрешающие пакеты только между внешним и внутренним инт., а пакеты из внутреннего инт. во внутрениий (т.е. остальные) — дропать.
Конечно, софт на Вашем уст-ве может выступать в роли маршрутизатора, но вешать на него несколько сетей нехорошо, если нужно реально разделить внутрение сети, то правильнее поставить после него коммутатор третьего уровня или много-портовый маршрутизатор. VLAN дело конечно хорошее, но в Ваших условиях, мне кажется лучше не станет, поскольку трафик из транка все одно придет в ядро и ему придется решать, что с ним делать (исключая широковещательный трафик, который останется в своем вилане.)
5. Ваше уст-во содержит направленную антену, не «омни». Если у Вас сота на расстоянии 100 метров, то это все, если же вы «пробиваете» километр и больше, то необходимо задуматься о точном выставлении на соту и о зонах Френеля. Об этом ни слова.
Пойдет снег, сильный дождь и качество канала просядет — нужно принять превентивные меры, что бы избежать «отказа в обслуживании».
7.Ничего не сказано про VPN. А это важно, в особенности при использовании радиоканала, который не очень хорошо «переносит» большие пакеты. Хотя если у вас просто доступ из локалки к сайтам, то это не нужно. MTU на внешнем инт. я бы «зажал», хотя бы до 1000. «Вялый» канал все же лучше, чем канал с «дропами».
8. И последнее — из Вашей статьи сложно почерпнуть, что то иное, кроме инструкции и ФАК'а на уст-во.
И,
Не могу сказать, что гуру в MikroTik, у меня их всего штук восемь на хозяйстве, но ИМХО, автор статьи слаб в сетях и системном подходе, ляп на ляпе, я бы не посоветовал данную статью как источник информации.
И,
По поводу производительности, буквально вчера гонял стенде два RB3011, порт в порт — IPSEC, на внутреннем генераторе трафика, UDP/TCP, packet size 1000, скорость в пределах 37Мб/сек в одном направлении, в двух ~22Мб, загрузка одного ядра — 100%, второе в простое, RouterOS 6.39.4
И — Win с начало времен сильно «гадит» в «темп», и плохо прибирает за собой. «Темп» в рамдиск.
%ProgramFiles%
%ProgramFiles(x86)%
%WINDIR%
И что сможет сделать код трояна при попытке его запуска?
И да, поднять контроллер AD стоит даже для такой задачи, виртуализация возможна сейчас практически на любых плаформах и ресурсах. Кроме всего прочего, можно использовать для авторизиции для Squid, Socks, Wi-Fi и т.д.
Привязываем OpenVPN к базе AD через openvpn-plugin-auth-pam.so и живем спокойно.
Не замучаетесь на личных уст-вах пользователей ставить сертификаты? Особенно для планктона.
Правильнее, ИМХО, один сертификат на всех + пароль/логин при подключении.
Какой смысл создавать под каждого пользователя правило в пакетном фильтре?
Правильнее, сертификаты и ключи пользователей прописывать в файле конфига пользователя, как уже было предложено ранее.
Используйте tls-auth для предотвращения тупого долбления на сервер.
Затем, все пользовательские данные — инсталлятор клиента, конфиг, RDP файлы сворачиваются в самораспаковывающийся архив со скриптом, переписывающим все в нужные каталоги на компе пользователя и выкладывается на FTP/HTTP сервер.
Так что лозунг двигать сегвеи/гироскутеры в массы выглядит довольно странным.
И таки да, под желанием «свободы» в инете существует огромное кол-во «грязи». Кому она нужна? Думается, для текущих любителей «грязи» и взращивания себе подобных, ИМХО.
Бсервер на Linux.
На источниках данных шаринг правами RO.
bash скрипт, монтирует шаринги, забирает данные rsync на основе различия размера и времени модификации.
12 (4+4+3+1) внешних USB 3.0 дисков с luks.
Доступ к Бсервер только у админов по ssh-sftp/ключи.
После создания суточного бэкапа сервер выключается, будится биосом в нужный момент бэкапа.
Админ по потребности будит сервер через wol
Wireless->Access List
Никак не связано с CAPsMAN. Существует уже доволно давно.