Новое в настройках OpenVPN в Mikrotik
Начиная с выпуска RouterOS 7.18 многие пользователи задались вопросом: а куда исчезла кнопка OVPN Server на закладке PPP – Interface.
А ее теперь там нет, вместо этого появилась отдельная вкладка OVPN Servers, которая позволяет теперь настроить более одного экземпляра OpenVPN сервера.
Данное нововведение можно оценить сугубо положительно, так как OpenVPN был и остается наиболее распространенным корпоративным VPN, а взаимоотношения его и Mikrotik были сложными.
Что это дает? Прежде всего позволяет разнести экземпляры по разным протоколам. Скажем, перевести пользователей на UDP, а остающиеся на RouterOS 6 роутеры оставить на единственно доступном им TCP.
Более сложные сценарии позволяют организовать сервера для разных наборов пользователей, каждый из которых получает сертификаты из собственного CA. Либо обеспечить разные уровни безопасности для разных типов пользователей или разного их расположения.
👍 В общем – инструмент есть, а применение ему найдем. А тенденция развития и улучшения возможностей OpenVPN в RouterOS только радует.
Начиная с выпуска RouterOS 7.18 многие пользователи задались вопросом: а куда исчезла кнопка OVPN Server на закладке PPP – Interface.
А ее теперь там нет, вместо этого появилась отдельная вкладка OVPN Servers, которая позволяет теперь настроить более одного экземпляра OpenVPN сервера.
Данное нововведение можно оценить сугубо положительно, так как OpenVPN был и остается наиболее распространенным корпоративным VPN, а взаимоотношения его и Mikrotik были сложными.
Что это дает? Прежде всего позволяет разнести экземпляры по разным протоколам. Скажем, перевести пользователей на UDP, а остающиеся на RouterOS 6 роутеры оставить на единственно доступном им TCP.
Более сложные сценарии позволяют организовать сервера для разных наборов пользователей, каждый из которых получает сертификаты из собственного CA. Либо обеспечить разные уровни безопасности для разных типов пользователей или разного их расположения.
👍 В общем – инструмент есть, а применение ему найдем. А тенденция развития и улучшения возможностей OpenVPN в RouterOS только радует.
О различных подходах к системному администрированию
Данная заметка написана как размышление по поводу одного обсуждения, где промелькнула интересная фраза об «уютном рабочем месте, где много чего есть». Под много чего подразумевается набор всяко-разных инструментов и утилит разной степени полезности.
Но зайдем мы сегодня издалека, сильно издалека, когда деревья были большие, а Windows 2003 еще не имел сервис-паков. Эпоха DOS стремительно уходила в прошлое, а новые версии Windows радовали новыми и удобными графическими интерфейсами.
Казалось, эпоха командной строки навсегда канула в прошлое. На любое, даже самое простое действие всегда можно было найти графическую утилиту и сделать все мышкой. Времена были тогда сильно попроще, и мы смело качали из сети все что под руку попадалось, особо не заморачиваясь ни насчет авторских прав, ни насчет двойного дна в программах.
Со временем у каждого собирался т.н. «джентельменский набор», который старательно записывался на дискеты, потом нарезался на диски, а затем уже и на флешки перекочевал. Можно ли что-либо из этого сделать просто так, средствами системы, мы не задумывались. А зачем?
Потом я начал осваивать мир Linux, естественно начал с графического интерфейса, потому как сразу нырять в глубину терминала классическому виндовому админу тех лет было не с руки. Там сразу кирпичом и на дно…
И сразу же стали всплывать вопросы вроде «а где мне найти аналог утилитки X или программки Y». Только вот интернет не спешил радовать порталами, где были бы сложены разные нужные программки для Linux, разной степени лицензионной чистоты.
Суровые и красноглазые «линуксоиды» чужаков не жаловали, все что от них можно было услышать, это про «курение манов» и репозитории.
Потихоньку выяснялось, что в Linux все есть и практически все это присутствует из коробки, а чего нет – быстро ставится одной командой. Но вот беда, все это было в основном заточено под консоль, что меня и моих коллег, привыкших к окошкам и мышке сильно пугало.
Первое, что мы пробовали делать, это искать графические оболочки для консольных утилит, но очень часто они выглядели так, как будто были написаны левым задним копытом в период ломового запоя. Ну и работали соответствующе.
Потом мы открыли для себя панели, и многие, включая меня на них подсели. Однако разочарование пришло довольно быстро. Системы время от времени ломались вместе с панелями. И становилось очень неуютно и тоскливо. Особенно если это была система заказчика.
В те времена многие сошли с этого трудного пути и вернулись обратно в простой и понятный, как нам тогда казалось, мир Windows.
Те, кто остался, стали осваивать сложный и непонятный мир терминала. Сколько раз в те годы я ругался, мол да это же MS DOS какой-то, ничего не видно, ничего не понятно, сплошная деградация.
Но потихоньку появлялись знания, нарабатывался опыт и в какой-то момент графика в Linux перестала быть нужна. А потом стало приходить понимание, что все что нужно – всегда у тебя под рукой, вместе с теми самыми «манами, которые нужно курить». Без этих ваших интернетов и СМС.
И, как это бывает, из чего-то чужого, непонятного и враждебного терминал превратился в теплую и уютную рабочую среду, где все есть и не нужно ничего искать, ну может сразу подкинуть парочку пакетов.
После чего, возвращаясь в мир окон стал возникать вопрос, а можно ли как-то решить эту задачу без привлечения сторонних утилит, средствами системы?
И оказалось, что да, что CMD, оказывается, не столь убог, как казалось. А PowerShell так вообще открыл новые, неведомые прежде возможности.
После чего необходимость в разных простых и не очень утилитках и программках стала как-то сходить на нет. Особенно с развитием удаленной работы. Это сегодня ты за своим уютным рабочим местом, а завтра в чужой системе, где ничего этого нет и возможность ставить что-то свое варьируется от нежелательно, до запрещено.
Поэтому, разный полезный софт – это хорошо, уютно, удобно. Но это не должно заменять владение родными инструментами системы.
Данная заметка написана как размышление по поводу одного обсуждения, где промелькнула интересная фраза об «уютном рабочем месте, где много чего есть». Под много чего подразумевается набор всяко-разных инструментов и утилит разной степени полезности.
Но зайдем мы сегодня издалека, сильно издалека, когда деревья были большие, а Windows 2003 еще не имел сервис-паков. Эпоха DOS стремительно уходила в прошлое, а новые версии Windows радовали новыми и удобными графическими интерфейсами.
Казалось, эпоха командной строки навсегда канула в прошлое. На любое, даже самое простое действие всегда можно было найти графическую утилиту и сделать все мышкой. Времена были тогда сильно попроще, и мы смело качали из сети все что под руку попадалось, особо не заморачиваясь ни насчет авторских прав, ни насчет двойного дна в программах.
Со временем у каждого собирался т.н. «джентельменский набор», который старательно записывался на дискеты, потом нарезался на диски, а затем уже и на флешки перекочевал. Можно ли что-либо из этого сделать просто так, средствами системы, мы не задумывались. А зачем?
Потом я начал осваивать мир Linux, естественно начал с графического интерфейса, потому как сразу нырять в глубину терминала классическому виндовому админу тех лет было не с руки. Там сразу кирпичом и на дно…
И сразу же стали всплывать вопросы вроде «а где мне найти аналог утилитки X или программки Y». Только вот интернет не спешил радовать порталами, где были бы сложены разные нужные программки для Linux, разной степени лицензионной чистоты.
Суровые и красноглазые «линуксоиды» чужаков не жаловали, все что от них можно было услышать, это про «курение манов» и репозитории.
Потихоньку выяснялось, что в Linux все есть и практически все это присутствует из коробки, а чего нет – быстро ставится одной командой. Но вот беда, все это было в основном заточено под консоль, что меня и моих коллег, привыкших к окошкам и мышке сильно пугало.
Первое, что мы пробовали делать, это искать графические оболочки для консольных утилит, но очень часто они выглядели так, как будто были написаны левым задним копытом в период ломового запоя. Ну и работали соответствующе.
Потом мы открыли для себя панели, и многие, включая меня на них подсели. Однако разочарование пришло довольно быстро. Системы время от времени ломались вместе с панелями. И становилось очень неуютно и тоскливо. Особенно если это была система заказчика.
В те времена многие сошли с этого трудного пути и вернулись обратно в простой и понятный, как нам тогда казалось, мир Windows.
Те, кто остался, стали осваивать сложный и непонятный мир терминала. Сколько раз в те годы я ругался, мол да это же MS DOS какой-то, ничего не видно, ничего не понятно, сплошная деградация.
Но потихоньку появлялись знания, нарабатывался опыт и в какой-то момент графика в Linux перестала быть нужна. А потом стало приходить понимание, что все что нужно – всегда у тебя под рукой, вместе с теми самыми «манами, которые нужно курить». Без этих ваших интернетов и СМС.
И, как это бывает, из чего-то чужого, непонятного и враждебного терминал превратился в теплую и уютную рабочую среду, где все есть и не нужно ничего искать, ну может сразу подкинуть парочку пакетов.
После чего, возвращаясь в мир окон стал возникать вопрос, а можно ли как-то решить эту задачу без привлечения сторонних утилит, средствами системы?
И оказалось, что да, что CMD, оказывается, не столь убог, как казалось. А PowerShell так вообще открыл новые, неведомые прежде возможности.
После чего необходимость в разных простых и не очень утилитках и программках стала как-то сходить на нет. Особенно с развитием удаленной работы. Это сегодня ты за своим уютным рабочим местом, а завтра в чужой системе, где ничего этого нет и возможность ставить что-то свое варьируется от нежелательно, до запрещено.
Поэтому, разный полезный софт – это хорошо, уютно, удобно. Но это не должно заменять владение родными инструментами системы.
Особенности использования точек восстановления в Windows 10
Точки восстановления Windows появились в Windows XP и сразу завоевали популярность, особенно у простых пользователей, позволяя выполнить откат изменений и вернуть систему в рабочее состояние.
В Windows 7 – 8.1 этот инструмент получил дальнейшее развитие вместе со средой восстановления Windows, которая стала размещаться на отдельном, защищённом разделе, позволяя загрузить компьютер, не прибегая к сторонним инструментам.
В Windows 7, 8 и 8.1 создание точек восстановления включалось автоматически и точки создавались при установке драйверов, ПО, обновлений.
А вот пользователи Windows 10 могут быть неприятно удивлены, если не сказать иначе. Потому что сей неприятный «сюрприз» многие из них обнаружат только в аварийной ситуации.
О чем речь? А о том, что у Windows 10 может вообще не оказаться точек восстановления! Потому что система защиты будет выключена. И, в отличии от многих других ситуаций, Windows не будет спешить уведомить вас об этом прискорбном факте.
👆 Дело в том, что в Windows 10 точки восстановления автоматически включаются только если объем системного раздела превышает 128 ГБ.
Если вы выполнили обновление системы с Windows 7 или 8/8.1 и объем системного диска меньше 128 ГБ, то система защиты будет автоматически выключена, а существующие точки восстановления удалены.
Таким образом в большинстве практических сценариев установки Windows вы можете оказаться без точек восстановления, хотя будете продолжать думать, что они создаются.
Поэтому на системах с размером системного раздела менее 128 ГБ точки восстановления нужно включить самостоятельно и не забыть при этом выделить дисковое пространство. Иначе система защиты хоть и будет включена, но работать не будет.
Рекомендуемый объем выделяемого пространства для разделов менее 64 ГБ – 3%, для более емких – 5%, но не более 10 ГБ.
Точки восстановления Windows появились в Windows XP и сразу завоевали популярность, особенно у простых пользователей, позволяя выполнить откат изменений и вернуть систему в рабочее состояние.
В Windows 7 – 8.1 этот инструмент получил дальнейшее развитие вместе со средой восстановления Windows, которая стала размещаться на отдельном, защищённом разделе, позволяя загрузить компьютер, не прибегая к сторонним инструментам.
В Windows 7, 8 и 8.1 создание точек восстановления включалось автоматически и точки создавались при установке драйверов, ПО, обновлений.
А вот пользователи Windows 10 могут быть неприятно удивлены, если не сказать иначе. Потому что сей неприятный «сюрприз» многие из них обнаружат только в аварийной ситуации.
О чем речь? А о том, что у Windows 10 может вообще не оказаться точек восстановления! Потому что система защиты будет выключена. И, в отличии от многих других ситуаций, Windows не будет спешить уведомить вас об этом прискорбном факте.
👆 Дело в том, что в Windows 10 точки восстановления автоматически включаются только если объем системного раздела превышает 128 ГБ.
Если вы выполнили обновление системы с Windows 7 или 8/8.1 и объем системного диска меньше 128 ГБ, то система защиты будет автоматически выключена, а существующие точки восстановления удалены.
Таким образом в большинстве практических сценариев установки Windows вы можете оказаться без точек восстановления, хотя будете продолжать думать, что они создаются.
Поэтому на системах с размером системного раздела менее 128 ГБ точки восстановления нужно включить самостоятельно и не забыть при этом выделить дисковое пространство. Иначе система защиты хоть и будет включена, но работать не будет.
Рекомендуемый объем выделяемого пространства для разделов менее 64 ГБ – 3%, для более емких – 5%, но не более 10 ГБ.
Небольшая подборка статей по Windows
Прежде всего коснемся темы LTSB/LTSC которая не дает покоя многим:
🔹 Чем является и чем не является Windows 10 LTSB/LTSC
Затем второй актуальный вопрос – встроенное ПО из магазина. Почему-то у многих прямо-таки навязчивая идея по поводу его удаления и при этом часто используются радикальные методы:
🔹 Предустановленное ПО в Windows 10 - мифы и реальность
Также не будет лишним почитать про «легковесные» сборки, которые являются таковыми ровно до первого обновления и по факту способны доставить больше проблем, чем преимуществ:
🔹 Tiny 11 - дело ZverCD живет и торжествует
Ну и наконец, как собрать свой предварительно настроенный образ Windows 10 с нужным набором предустановленного ПО и настроенными плитками меню Пуск.
🔹 Создание образа Windows 10 с собственным набором предустановленного ПО и настройками меню Пуск
Прежде всего коснемся темы LTSB/LTSC которая не дает покоя многим:
🔹 Чем является и чем не является Windows 10 LTSB/LTSC
Затем второй актуальный вопрос – встроенное ПО из магазина. Почему-то у многих прямо-таки навязчивая идея по поводу его удаления и при этом часто используются радикальные методы:
🔹 Предустановленное ПО в Windows 10 - мифы и реальность
Также не будет лишним почитать про «легковесные» сборки, которые являются таковыми ровно до первого обновления и по факту способны доставить больше проблем, чем преимуществ:
🔹 Tiny 11 - дело ZverCD живет и торжествует
Ну и наконец, как собрать свой предварительно настроенный образ Windows 10 с нужным набором предустановленного ПО и настроенными плитками меню Пуск.
🔹 Создание образа Windows 10 с собственным набором предустановленного ПО и настройками меню Пуск
Сборки Windows – вчера, сегодня, завтра
Сборки Windows как массовое явление появились во времена Windows XP и занимались ими практически все те, кто по специфике работы сталкивался с частой установкой ОС.
Прежде всего это было связано с тем, что после установки самой ОС требовался достаточно долгий и кропотливый процесс установки дополнительного ПО.
По факту требовалось доустановить системные компоненты, такие как пакеты Visual C++, NET Framework, DirectX и набор патчей от самых актуальных сетевых угроз.
Далее нужна была установка прикладного ПО: проигрыватели, кодеки, утилиты для записи дисков, DC++ клиенты и т.д. и т.п.
Делать это руками каждый раз было утомительно и поэтому сборка была просто отличным выходом из ситуации, существенно экономящим время.
Но у этого явления была и другая сторона – заполонившие интернет и файлообменники любительские сборки, самой известной из которых стала ZverCD.
Это был настоящий кошмар для сотрудников технических отделов и сервисов, когда клиенты приносили не работающие нормально компьютеры и стоило большого труда объяснить им, что с компьютером все нормально, не нормально с установленной на нем системой. И тем, что случай этот негарантийный.
В результате за этими сборками закрепилось народное название «г-сборки» и их использование стало ярким признаком непрофессионализма. Хотя, справедливости ради, ZverCD был далеко не худшим вариантом. Встречались разного рода «игровые» или «облегченные» сборки, в которых сборщики просто вырезали на свое усмотрение половину системы.
С выходом Windows 7 тенденция делать собственные сборки продолжилась, но акцент сместился с ПО на обновления. Потому что сети плотно вошли в повседневную жизнь, и эксплуатация не обновлённых систем стала небезопасной.
А штатный процесс скачивания и установки обновлений на новый компьютер мог занять часы, если не более. Поэтому обновления скачивались один раз и интегрировались в сборку. После чего оставалось ее регулярно обновлять и формировать новый образ.
При этом интегрируемого в сборку прикладного ПО стало меньше. Причин тому было несколько.
Во-первых, в Windows 7 появилось достаточное количество встроенного ПО, закрывающего базовые потребности: запись CD, просмотр изображений и видео, работа со скриншотами и т.д. и т.д.
Во-вторых, практически все компании стали жить «по белому» избегая установки нелицензионного ПО. Хотя, чтобы не оставлять пользователя совсем с голым ПК многие начали добавлять в образы свободное ПО.
При этом количество «г-сборок» продолжало расти и множиться. А там кто был во что горазд, тем более что собирать собственные сборки на базе Windows 7 стало легче, а интернет стал доступнее, и теперь каждый суслик мог выступить в роли агронома.
Все поменялось с выходом Windows 10 и ее полугодовым планом выпуска новых версий. Система обновлений перешла на накопительную модель, а встроенное прикладное ПО стало закрывать подавляющее число задач.
По-хорошему в чистой системе стало не хватать только офисного пакета и архиватора. Все остальное было из коробки и при этом нормально работало. Все эти наборы кодеков, просмотрщиков и т.п. ушли как страшный сон.
Обновления тоже перестали доставлять неудобства, как и системные компоненты, многие из которых скачивались автоматом при первой необходимости.
Поэтому смысл в сборках потихоньку сошел на нет, а выполнять пересборку каждые полгода стало немного накладно, так как результат не соответствовал потраченному времени.
В Windows 11 такая необходимость еще более уменьшилась, так как штатные инструменты стали лучше и появилась поддержка всех распространенных форматов архивов из коробки.
Поэтому создание сборок современных систем – это или внутренние корпоративные сборки с автоматической установкой всего прикладного ПО. Либо изменить состав предустановленного ПО и предварительно настроить меню Пуск. Либо и то и другое вместе.
В остальных случаях создание собственных сборок современных ОС оправдано сугубо в исследовательских целях, ну либо вам не дают покоя лавры создателя очередной «г-сборки».
Сборки Windows как массовое явление появились во времена Windows XP и занимались ими практически все те, кто по специфике работы сталкивался с частой установкой ОС.
Прежде всего это было связано с тем, что после установки самой ОС требовался достаточно долгий и кропотливый процесс установки дополнительного ПО.
По факту требовалось доустановить системные компоненты, такие как пакеты Visual C++, NET Framework, DirectX и набор патчей от самых актуальных сетевых угроз.
Далее нужна была установка прикладного ПО: проигрыватели, кодеки, утилиты для записи дисков, DC++ клиенты и т.д. и т.п.
Делать это руками каждый раз было утомительно и поэтому сборка была просто отличным выходом из ситуации, существенно экономящим время.
Но у этого явления была и другая сторона – заполонившие интернет и файлообменники любительские сборки, самой известной из которых стала ZverCD.
Это был настоящий кошмар для сотрудников технических отделов и сервисов, когда клиенты приносили не работающие нормально компьютеры и стоило большого труда объяснить им, что с компьютером все нормально, не нормально с установленной на нем системой. И тем, что случай этот негарантийный.
В результате за этими сборками закрепилось народное название «г-сборки» и их использование стало ярким признаком непрофессионализма. Хотя, справедливости ради, ZverCD был далеко не худшим вариантом. Встречались разного рода «игровые» или «облегченные» сборки, в которых сборщики просто вырезали на свое усмотрение половину системы.
С выходом Windows 7 тенденция делать собственные сборки продолжилась, но акцент сместился с ПО на обновления. Потому что сети плотно вошли в повседневную жизнь, и эксплуатация не обновлённых систем стала небезопасной.
А штатный процесс скачивания и установки обновлений на новый компьютер мог занять часы, если не более. Поэтому обновления скачивались один раз и интегрировались в сборку. После чего оставалось ее регулярно обновлять и формировать новый образ.
При этом интегрируемого в сборку прикладного ПО стало меньше. Причин тому было несколько.
Во-первых, в Windows 7 появилось достаточное количество встроенного ПО, закрывающего базовые потребности: запись CD, просмотр изображений и видео, работа со скриншотами и т.д. и т.д.
Во-вторых, практически все компании стали жить «по белому» избегая установки нелицензионного ПО. Хотя, чтобы не оставлять пользователя совсем с голым ПК многие начали добавлять в образы свободное ПО.
При этом количество «г-сборок» продолжало расти и множиться. А там кто был во что горазд, тем более что собирать собственные сборки на базе Windows 7 стало легче, а интернет стал доступнее, и теперь каждый суслик мог выступить в роли агронома.
Все поменялось с выходом Windows 10 и ее полугодовым планом выпуска новых версий. Система обновлений перешла на накопительную модель, а встроенное прикладное ПО стало закрывать подавляющее число задач.
По-хорошему в чистой системе стало не хватать только офисного пакета и архиватора. Все остальное было из коробки и при этом нормально работало. Все эти наборы кодеков, просмотрщиков и т.п. ушли как страшный сон.
Обновления тоже перестали доставлять неудобства, как и системные компоненты, многие из которых скачивались автоматом при первой необходимости.
Поэтому смысл в сборках потихоньку сошел на нет, а выполнять пересборку каждые полгода стало немного накладно, так как результат не соответствовал потраченному времени.
В Windows 11 такая необходимость еще более уменьшилась, так как штатные инструменты стали лучше и появилась поддержка всех распространенных форматов архивов из коробки.
Поэтому создание сборок современных систем – это или внутренние корпоративные сборки с автоматической установкой всего прикладного ПО. Либо изменить состав предустановленного ПО и предварительно настроить меню Пуск. Либо и то и другое вместе.
В остальных случаях создание собственных сборок современных ОС оправдано сугубо в исследовательских целях, ну либо вам не дают покоя лавры создателя очередной «г-сборки».
А давайте кого-нибудь заблокируем!
Очень часто к нам обращаются с вопросом: помогите составить правило, которое бы блокировало вот этих нехороших товарищей и приводят записи лога.
После чего сильно удивляются, когда узнают, что средствами только самого брандмауэра это сделать нельзя.
Почему? Давайте посмотрим, где у нас находится брандмауэр, а где логи. Условно цепочку мы можем построить так:
Классический брандмауэр работает на сетевом и транспортном уровне (L3 и L4) и все что он видит – это пакеты, которые бегают из сети к приложению и обратно.
Лог – это продукт работы приложения, куда оно пишет то, что считает нужным. Причем единого формата логов нет, где четко можно было бы понять, что если в этом поле стоит единичка, то это ошибка, лог – это строковая информация, которую нужно разобрать, проанализировать, определить ключевые части строки.
Любой лог рассчитан прежде всего на чтение его человеком, а не машиной, поэтому работа с логом всегда требует индивидуального подхода.
Следующий момент, лог пишется приложением в некоторое хранилище, которое живет там же, где и приложение и никакого отношения к брандмауэру не имеет.
👆 Сообщения лога через брандмауэр не проходят!
Возможно – это очевидные вещи, но мы не раз и не два слышали предложения искать сообщения лога с помощью критерия Content в брандмауэре.
Но постойте, ведь приложение сообщает клиенту об ошибке? Сообщает, но очень редко делает это открытым текстом, на улице 2023 год и подавляющее большинство коммуникаций зашифровано. Прошли те времена, когда мы могли посмотреть содержимое пакета и сказать «ага».
Все, что мы сейчас можем – это делать какие-либо выводы по косвенным критериям. Но ни один из них не дает 100% гарантии нежелательной активности. Большинство протоколов обмениваются стандартными сообщениями фиксированной длинны и не видя содержимого сообщений нельзя сказать, что именно происходит.
Поэтому в основе любых алгоритмов лежат определенные допущения. Например, при обнаружении брутфорса протокола RDP мы исходили из того, что четко знаем сколько пакетов в состоянии NEW требуется для успешного установления соединения.
Затем выдвинули предположение, что если их количество с одного адреса источника в течении некоторого промежутка времени превышает некоторый лимит – то перед нами попытка подбора пароля.
Никаких критериев, позволяющих однозначно сказать «это подбор» нет. Мы просто определяем некоторый паттерн поведения, который можем определить при помощи критериев брандмауэра и затем делать выводы на основе его повторяемости.
Т.е. в установке нового соединения само по себе криминал нет, но если некто делает это слишком часто, то скорее всего это злоумышленник.
Поэтому, прежде чем браться кого-то или что-то блокировать нужно посмотреть на этот процесс со стороны брандмауэра. Об ошибках в лог пишет приложение, а для сетевого экрана «правильное» и «неправильное» соединения могут не отличаться ничем.
Ну и, наконец, подумать, а зачем оно надо? Практический смысл отлавливать злоумышленников есть только там, где есть потенциально уязвимый сервис. Если же кто-то старательно долбится в стену там, где двери нет и никогда не было – то какая нам печаль до этого дела?
К примеру, на узле, где кроме VPN-сервера с аутентификацией по сертификатам ничего нет ловить и блокировать всяких брутфорсеров и сканеров практического смысла нет.
Современные боты прекрасно выявляют блокировки и либо подстраиваются под тайм-ауты, либо используют большой пул адресов, чтобы каждый запрос приходил с нового адреса.
Ну а если очень хочется создавать правила по событиям лога, то нужно начать писать свой Fail2ban, так как никакого иного способа научить брандмауэр взаимодействовать с логами нет.
Очень часто к нам обращаются с вопросом: помогите составить правило, которое бы блокировало вот этих нехороших товарищей и приводят записи лога.
После чего сильно удивляются, когда узнают, что средствами только самого брандмауэра это сделать нельзя.
Почему? Давайте посмотрим, где у нас находится брандмауэр, а где логи. Условно цепочку мы можем построить так:
Сеть => Брандмауэр => Приложение => ЛогКлассический брандмауэр работает на сетевом и транспортном уровне (L3 и L4) и все что он видит – это пакеты, которые бегают из сети к приложению и обратно.
Лог – это продукт работы приложения, куда оно пишет то, что считает нужным. Причем единого формата логов нет, где четко можно было бы понять, что если в этом поле стоит единичка, то это ошибка, лог – это строковая информация, которую нужно разобрать, проанализировать, определить ключевые части строки.
Любой лог рассчитан прежде всего на чтение его человеком, а не машиной, поэтому работа с логом всегда требует индивидуального подхода.
Следующий момент, лог пишется приложением в некоторое хранилище, которое живет там же, где и приложение и никакого отношения к брандмауэру не имеет.
👆 Сообщения лога через брандмауэр не проходят!
Возможно – это очевидные вещи, но мы не раз и не два слышали предложения искать сообщения лога с помощью критерия Content в брандмауэре.
Но постойте, ведь приложение сообщает клиенту об ошибке? Сообщает, но очень редко делает это открытым текстом, на улице 2023 год и подавляющее большинство коммуникаций зашифровано. Прошли те времена, когда мы могли посмотреть содержимое пакета и сказать «ага».
Все, что мы сейчас можем – это делать какие-либо выводы по косвенным критериям. Но ни один из них не дает 100% гарантии нежелательной активности. Большинство протоколов обмениваются стандартными сообщениями фиксированной длинны и не видя содержимого сообщений нельзя сказать, что именно происходит.
Поэтому в основе любых алгоритмов лежат определенные допущения. Например, при обнаружении брутфорса протокола RDP мы исходили из того, что четко знаем сколько пакетов в состоянии NEW требуется для успешного установления соединения.
Затем выдвинули предположение, что если их количество с одного адреса источника в течении некоторого промежутка времени превышает некоторый лимит – то перед нами попытка подбора пароля.
Никаких критериев, позволяющих однозначно сказать «это подбор» нет. Мы просто определяем некоторый паттерн поведения, который можем определить при помощи критериев брандмауэра и затем делать выводы на основе его повторяемости.
Т.е. в установке нового соединения само по себе криминал нет, но если некто делает это слишком часто, то скорее всего это злоумышленник.
Поэтому, прежде чем браться кого-то или что-то блокировать нужно посмотреть на этот процесс со стороны брандмауэра. Об ошибках в лог пишет приложение, а для сетевого экрана «правильное» и «неправильное» соединения могут не отличаться ничем.
Ну и, наконец, подумать, а зачем оно надо? Практический смысл отлавливать злоумышленников есть только там, где есть потенциально уязвимый сервис. Если же кто-то старательно долбится в стену там, где двери нет и никогда не было – то какая нам печаль до этого дела?
К примеру, на узле, где кроме VPN-сервера с аутентификацией по сертификатам ничего нет ловить и блокировать всяких брутфорсеров и сканеров практического смысла нет.
Современные боты прекрасно выявляют блокировки и либо подстраиваются под тайм-ауты, либо используют большой пул адресов, чтобы каждый запрос приходил с нового адреса.
Ну а если очень хочется создавать правила по событиям лога, то нужно начать писать свой Fail2ban, так как никакого иного способа научить брандмауэр взаимодействовать с логами нет.
Подборка материалов по Linux для начинающих
🔹 Linux - начинающим. Первое знакомство
🔹 Linux - начинающим. Работаем с файловой системой. Теория
🔹 Linux - начинающим. Работаем с файловой системой. Практика
🔹 Linux - начинающим. Управление пакетами в Debian и Ubuntu
🔹 Linux - начинающим. Управление пользователями и группами. Теория
🔹 Linux - начинающим. Управление пользователями и группами. Практика
🔹 Linux - начинающим. Потоки, перенаправление потоков, конвейер
Как установить и настроить?
🔹 Linux - начинающим. Установка и первоначальная настройка Debian 11 для сервера
🔹 Linux - начинающим. Установка и первоначальная настройка Ubuntu 22.04 LTS для сервера
🔹 Настройка языка и региональных стандартов в Ubuntu Server/Debian
🔹 Аpt-key is deprecated или управление ключами в современных выпусках Debian и Ubuntu
🔹 Установка российских корневых сертификатов в Debian и Ubuntu
🔹 Используем APT Pinning для закрепления пакетов в Debian и Ubuntu
Продолжение следует...
🔹 Linux - начинающим. Первое знакомство
🔹 Linux - начинающим. Работаем с файловой системой. Теория
🔹 Linux - начинающим. Работаем с файловой системой. Практика
🔹 Linux - начинающим. Управление пакетами в Debian и Ubuntu
🔹 Linux - начинающим. Управление пользователями и группами. Теория
🔹 Linux - начинающим. Управление пользователями и группами. Практика
🔹 Linux - начинающим. Потоки, перенаправление потоков, конвейер
Как установить и настроить?
🔹 Linux - начинающим. Установка и первоначальная настройка Debian 11 для сервера
🔹 Linux - начинающим. Установка и первоначальная настройка Ubuntu 22.04 LTS для сервера
🔹 Настройка языка и региональных стандартов в Ubuntu Server/Debian
🔹 Аpt-key is deprecated или управление ключами в современных выпусках Debian и Ubuntu
🔹 Установка российских корневых сертификатов в Debian и Ubuntu
🔹 Используем APT Pinning для закрепления пакетов в Debian и Ubuntu
Продолжение следует...
Hairpin NAT, обратный прокси и двойной горизонт DNS
В современном мире мобильные пользователи давно стали нормой жизни. Сегодня в офисе, завтра на удаленке, послезавтра где-то «в полях». И все это время нужно иметь доступ к информационным ресурсам предприятия и желательно без лишних телодвижений.
Основная проблема, с которой сталкиваются пользователи, это изменение адресов ресурсов при переходе из внешней сети во внутреннюю. Если снаружи это некий публичный адрес, но внутри сети это будет какой-либо локальный ресурс, а может даже и несколько.
Организовать одновременный доступ к таким ресурсам можно несколькими способами. Но прежде несколько важных моментов. Сразу и навсегда забудьте про доступ через IP и дело даже не в том, что IP может поменяться, таким образом вы просто сильно ограничите себя в доступных вариантах.
Второй момент: один сервис – один поддомен, даже если все они ведут на один и тот же внешний адрес. Почему? Да потому что в сети это могут быть различные хосты и тогда у вас возникнут проблемы.
Теперь рассмотрим способы доступа из внешней сети к ресурсам внутренней.
🔹 Самый простой – это проброс портов. Но его нужно сделать правильно, в терминах Mikrotik это называется Hairpin NAT, но данная проблема актуальна и для любых иных систем.
Обычно проброс портов осуществляется правилом с DNAT, которое заменяет адрес назначение и (при необходимости) порт пакета. При этом адрес источника никаких преобразований не испытывает.
Пока мы находимся снаружи – это не доставляет проблем, внешний адрес источника всегда будет возвращен обратно шлюзу.
А вот после того, как мы попали внутрь и получили внутренний адрес начинаются проблемы. Внутренний сервер видит, что адрес источника, хоть мы и обращались на внешний адрес роутера, принадлежит внутренней сети и отправляет ответ напрямую.
Но клиент не ждет ответа от локального сервера и поэтому такой пакет будет отброшен и ничего работать не будет. Чтобы избежать такой проблемы следует выполнить дополнительно действие SNAT и заменить адрес источника пакета на внутренний адрес роутера.
Подробнее можно прочитать в нашей статье: Проброс портов и Hairpin NAT в роутерах Mikrotik
🔹 Обратный прокси. Это альтернативный метод, при котором на внешнем интерфейсе мы поднимаем прокси-сервер, который принимает запросы из внешней сети и перенаправляет их к внутренним узлам.
В этом случае нам не нужны дополнительные телодвижения для внутренней сети, так как клиентом для внутренних узлов является именно прокси-сервер и отвечать они будут именно ему, независимо от того, где находится клиентское устройство, внутри или снаружи.
Популярным обратным прокси является веб-сервер NGINX и пример такого его использования можно найти в статье: Настраиваем NGINX как обратный прокси для веб-публикации 1С:Предприятие
🔹 И наконец двойной горизонт DNS, сам по себе он не решает проблемы с доступом внешних клиентов, для них вам все равно придется настраивать проброс или обратный прокси, но позволяет не гонять локальный трафик через роутер.
Оба предыдущих метода подразумевают, что при нахождении клиента в локальной сети его трафик все равно проходит через роутер, что создает дополнительную лишнюю нагрузку, от которой лучше избавиться.
Именно это и дает нам двойной горизонт DNS, смысл его заключается в том, что внутренний DNS-сервер отдает для доменных имен сервисов внутренние адреса и клиент будет взаимодействовать напрямую с локальным сервером.
Оказавшись за пределами сети он получит от публичных DNS внешний адрес и будет работать через проброс или обратный прокси.
При использовании проброса вместе с двойным горизонтом DNS следует избегать проброса на другой номер порта. В этом случае лучше поменять порт самого сервиса.
С примером настройки двойного горизонта DNS можно ознакомиться здесь: Настраиваем двойной горизонт DNS (Split DNS) на роутерах Mikrotik
В современном мире мобильные пользователи давно стали нормой жизни. Сегодня в офисе, завтра на удаленке, послезавтра где-то «в полях». И все это время нужно иметь доступ к информационным ресурсам предприятия и желательно без лишних телодвижений.
Основная проблема, с которой сталкиваются пользователи, это изменение адресов ресурсов при переходе из внешней сети во внутреннюю. Если снаружи это некий публичный адрес, но внутри сети это будет какой-либо локальный ресурс, а может даже и несколько.
Организовать одновременный доступ к таким ресурсам можно несколькими способами. Но прежде несколько важных моментов. Сразу и навсегда забудьте про доступ через IP и дело даже не в том, что IP может поменяться, таким образом вы просто сильно ограничите себя в доступных вариантах.
Второй момент: один сервис – один поддомен, даже если все они ведут на один и тот же внешний адрес. Почему? Да потому что в сети это могут быть различные хосты и тогда у вас возникнут проблемы.
Теперь рассмотрим способы доступа из внешней сети к ресурсам внутренней.
🔹 Самый простой – это проброс портов. Но его нужно сделать правильно, в терминах Mikrotik это называется Hairpin NAT, но данная проблема актуальна и для любых иных систем.
Обычно проброс портов осуществляется правилом с DNAT, которое заменяет адрес назначение и (при необходимости) порт пакета. При этом адрес источника никаких преобразований не испытывает.
Пока мы находимся снаружи – это не доставляет проблем, внешний адрес источника всегда будет возвращен обратно шлюзу.
А вот после того, как мы попали внутрь и получили внутренний адрес начинаются проблемы. Внутренний сервер видит, что адрес источника, хоть мы и обращались на внешний адрес роутера, принадлежит внутренней сети и отправляет ответ напрямую.
Но клиент не ждет ответа от локального сервера и поэтому такой пакет будет отброшен и ничего работать не будет. Чтобы избежать такой проблемы следует выполнить дополнительно действие SNAT и заменить адрес источника пакета на внутренний адрес роутера.
Подробнее можно прочитать в нашей статье: Проброс портов и Hairpin NAT в роутерах Mikrotik
🔹 Обратный прокси. Это альтернативный метод, при котором на внешнем интерфейсе мы поднимаем прокси-сервер, который принимает запросы из внешней сети и перенаправляет их к внутренним узлам.
В этом случае нам не нужны дополнительные телодвижения для внутренней сети, так как клиентом для внутренних узлов является именно прокси-сервер и отвечать они будут именно ему, независимо от того, где находится клиентское устройство, внутри или снаружи.
Популярным обратным прокси является веб-сервер NGINX и пример такого его использования можно найти в статье: Настраиваем NGINX как обратный прокси для веб-публикации 1С:Предприятие
🔹 И наконец двойной горизонт DNS, сам по себе он не решает проблемы с доступом внешних клиентов, для них вам все равно придется настраивать проброс или обратный прокси, но позволяет не гонять локальный трафик через роутер.
Оба предыдущих метода подразумевают, что при нахождении клиента в локальной сети его трафик все равно проходит через роутер, что создает дополнительную лишнюю нагрузку, от которой лучше избавиться.
Именно это и дает нам двойной горизонт DNS, смысл его заключается в том, что внутренний DNS-сервер отдает для доменных имен сервисов внутренние адреса и клиент будет взаимодействовать напрямую с локальным сервером.
Оказавшись за пределами сети он получит от публичных DNS внешний адрес и будет работать через проброс или обратный прокси.
При использовании проброса вместе с двойным горизонтом DNS следует избегать проброса на другой номер порта. В этом случае лучше поменять порт самого сервиса.
С примером настройки двойного горизонта DNS можно ознакомиться здесь: Настраиваем двойной горизонт DNS (Split DNS) на роутерах Mikrotik
Как устроен IT-бизнес изнутри — без иллюзий и прикрас
Я — CTO и IT-консультант. Веду канал, где пишу о том, как действительно работают команды, технологии и IT-системы.
Разбираю на конкретных кейсах:
— Почему разваливаются проекты?
— Что происходит внутри eCommerce и EdTech?
— Как выстроить сильную команду и не сгореть?
— Какие ошибки ИТ стоят вам денег?
Если хотите разбираться глубже и видеть картину изнутри — подписывайтесь. Только полезное, без воды, продажи курсов и инфоцыганства.
👉 Авторский канал ИТ Директора
Я — CTO и IT-консультант. Веду канал, где пишу о том, как действительно работают команды, технологии и IT-системы.
Разбираю на конкретных кейсах:
— Почему разваливаются проекты?
— Что происходит внутри eCommerce и EdTech?
— Как выстроить сильную команду и не сгореть?
— Какие ошибки ИТ стоят вам денег?
Если хотите разбираться глубже и видеть картину изнутри — подписывайтесь. Только полезное, без воды, продажи курсов и инфоцыганства.
👉 Авторский канал ИТ Директора
Подборка статей по Linux
В прошлой нашей заметке мы дали ссылки на статьи нашего базового цикла для начинающих, и материалы по установке и настройке: https://www.group-telegram.com/interface31.com/4460
Сегодня продолжим, затронув другие темы.
Как получить информацию о системе?
🔹 Как быстро разобраться в Debian/Ubuntu если вы видите систему первый раз
🔹 Как узнать температуру процессора и накопителей
🔹 Как получить информацию об оборудовании ПК
🔹 Как узнать чем занято место на диске?
🔹 Как узнать оставшийся ресурс SSD в Linux
Как именно это работает?
🔹 Что такое Load Average и какую информацию он несет
🔹 Что такое пространства подкачки и как они работают
🔹Что такое OOM Killer и как он работает
Продолжение следует...
В прошлой нашей заметке мы дали ссылки на статьи нашего базового цикла для начинающих, и материалы по установке и настройке: https://www.group-telegram.com/interface31.com/4460
Сегодня продолжим, затронув другие темы.
Как получить информацию о системе?
🔹 Как быстро разобраться в Debian/Ubuntu если вы видите систему первый раз
🔹 Как узнать температуру процессора и накопителей
🔹 Как получить информацию об оборудовании ПК
🔹 Как узнать чем занято место на диске?
🔹 Как узнать оставшийся ресурс SSD в Linux
Как именно это работает?
🔹 Что такое Load Average и какую информацию он несет
🔹 Что такое пространства подкачки и как они работают
🔹Что такое OOM Killer и как он работает
Продолжение следует...
И снова про отечественные сертификаты
Осень еще не наступила, а очередное осеннее обострение уже началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры.
Мол какое может быть доверие этим сертификатам и этому CA если… (тут можете вписать любой набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
Осень еще не наступила, а очередное осеннее обострение уже началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры.
Мол какое может быть доверие этим сертификатам и этому CA если… (тут можете вписать любой набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Key exchange ECDHE_RSA with P-256Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
Риски использования зарубежного хостинга
Решили обобщить свой опыт и собрать в одном материале все основные риски использования зарубежного хостинга в настоящее время.
Начнем с причин, которые заставляли использовать именно зарубежных провайдеров. Точнее с причины. Основная причина – это соотношение цена/возможности. В этом плане зарубежные хостеры предоставляли и предоставляют более интересные предложения, чем отечественные.
Все остальное вторично, а в текущих реалиях и вовсе перестало иметь значение, например, вынос сайта «за пределы юрисдикции» по соображениям безопасности. По факту безопасностью там и не пахнет, а теперь еще и заблокировать могут, просто по факту принадлежности к определенной юрисдикции.
Но начнем по порядку.
1️⃣ Оплата. Сегодня платить напрямую зарубежным провайдерам из РФ невозможно, вам придется использовать посредников, карты зарубежных банков, криптовалюты и прочие схемы, которые удорожают стоимость услуг.
А так как основной стимул хоститься там – это стоимость, то нужно крепко подумать и хорошо посчитать, может все-таки выгоднее вернуться в родные пенаты? Тем более что рисков хватает.
Также мы не говорим о том, что канал оплаты может в любой момент закрыться или кратно подорожать, добавляем сюда еще и нестабильность валютного курса.
2️⃣ Санкционные блокировки. Многие зарубежные провайдеры поддерживают санкции в отношении РФ и могут как полностью заблокировать ваш аккаунт, так и частично.
К частичным блокировкам относится, например, блокировка личного кабинета для российских адресов или систем с установленным русским языком или локалью.
В большинстве случаев для полноценного использования аккаунта вам понадобится виртуалка на зарубежной редакции ОС, без русской локали и раскладки клавиатуры и с часовым поясом отличным от поясов РФ.
3️⃣ Персональные блокировки. Если предыдущий пункт содержал чисто технические меры, когда блокировка была настроена в автоматическом режиме и не касалась вас лично, то здесь все хуже.
Например, вы можете получить такое письмо:
Sehr geehrte Damen und Herren,
wir möchten Sie daran erinnern, dass unseren Aufzeichnungen zufolge, Sie oder eine in Ihrem Konto aufgeführte Kontaktperson oder Domaininhaber/in sich möglicherweise in der Russischen Föderation befinden. Soweit diese Angaben zutreffen, werden Ihre Konten und/oder das/die betroffene(n) Produkt(e) zum 29.02.2024 gekündigt.
Für alle anderen Produkte wird Ihr Zugriff auf alle bei uns gespeicherten Daten und Inhalte zum 29.02.2024 beendet, und wir können Ihnen keine Backups zur Verfügung stellen. Aus diesem Grund bitten wir Sie dringend, Ihre Daten zu sichern und alle Produkte, die Sie bei uns haben, vor diesem Datum zu einem neuen Anbieter zu übertragen.
Общий смысл прост, мы заметили, что вы из РФ, поэтому просим с вещами на выход. Причем просят на выход в довольно сжатые сроки, данное письмо мы получили 22 февраля 2024. А если у вас там был не один сайт, а целая инфраструктура?
4️⃣ Трансграничные замедления. Тут трудно сказать кто именно виноват и чьих это рук дело, но замедление трансграничного трафика имело и имеет место быть. Причем у вас все может быть хорошо, а вот у посетителей вашего сайта не очень.
В результате начнет расти процент отказов, будут падать позиции в поисковиках, просядет трафик что напрямую скажется на коммерческом результате. Причем не важно получаете вы доход с сайта напрямую или опосредованно. Для информационного ресурса тоже нет ничего хорошего, просядет рекламный доход.
5️⃣ Блокировки РКН. Под блокировку сегодня можно попасть легко и непринужденно. Просто, потому что где-то рядом у вас плохие соседи и РКН отдал на блокировку целый блок IP-адресов, потому что РКН не договорился с провайдером и т.д. и т.п.
Приятного тут тоже мало. Переезжать с заблокированного ресурса – еще то удовольствие, так как обходит, возможно, придется с двух сторон. С одной – запреты РКН, с другой – санкционные блокировки там.
Ну и вишенкой на торте будет спалиться и попасть под блокировки персональные.
Решили обобщить свой опыт и собрать в одном материале все основные риски использования зарубежного хостинга в настоящее время.
Начнем с причин, которые заставляли использовать именно зарубежных провайдеров. Точнее с причины. Основная причина – это соотношение цена/возможности. В этом плане зарубежные хостеры предоставляли и предоставляют более интересные предложения, чем отечественные.
Все остальное вторично, а в текущих реалиях и вовсе перестало иметь значение, например, вынос сайта «за пределы юрисдикции» по соображениям безопасности. По факту безопасностью там и не пахнет, а теперь еще и заблокировать могут, просто по факту принадлежности к определенной юрисдикции.
Но начнем по порядку.
1️⃣ Оплата. Сегодня платить напрямую зарубежным провайдерам из РФ невозможно, вам придется использовать посредников, карты зарубежных банков, криптовалюты и прочие схемы, которые удорожают стоимость услуг.
А так как основной стимул хоститься там – это стоимость, то нужно крепко подумать и хорошо посчитать, может все-таки выгоднее вернуться в родные пенаты? Тем более что рисков хватает.
Также мы не говорим о том, что канал оплаты может в любой момент закрыться или кратно подорожать, добавляем сюда еще и нестабильность валютного курса.
2️⃣ Санкционные блокировки. Многие зарубежные провайдеры поддерживают санкции в отношении РФ и могут как полностью заблокировать ваш аккаунт, так и частично.
К частичным блокировкам относится, например, блокировка личного кабинета для российских адресов или систем с установленным русским языком или локалью.
В большинстве случаев для полноценного использования аккаунта вам понадобится виртуалка на зарубежной редакции ОС, без русской локали и раскладки клавиатуры и с часовым поясом отличным от поясов РФ.
3️⃣ Персональные блокировки. Если предыдущий пункт содержал чисто технические меры, когда блокировка была настроена в автоматическом режиме и не касалась вас лично, то здесь все хуже.
Например, вы можете получить такое письмо:
Sehr geehrte Damen und Herren,
wir möchten Sie daran erinnern, dass unseren Aufzeichnungen zufolge, Sie oder eine in Ihrem Konto aufgeführte Kontaktperson oder Domaininhaber/in sich möglicherweise in der Russischen Föderation befinden. Soweit diese Angaben zutreffen, werden Ihre Konten und/oder das/die betroffene(n) Produkt(e) zum 29.02.2024 gekündigt.
Für alle anderen Produkte wird Ihr Zugriff auf alle bei uns gespeicherten Daten und Inhalte zum 29.02.2024 beendet, und wir können Ihnen keine Backups zur Verfügung stellen. Aus diesem Grund bitten wir Sie dringend, Ihre Daten zu sichern und alle Produkte, die Sie bei uns haben, vor diesem Datum zu einem neuen Anbieter zu übertragen.
Общий смысл прост, мы заметили, что вы из РФ, поэтому просим с вещами на выход. Причем просят на выход в довольно сжатые сроки, данное письмо мы получили 22 февраля 2024. А если у вас там был не один сайт, а целая инфраструктура?
4️⃣ Трансграничные замедления. Тут трудно сказать кто именно виноват и чьих это рук дело, но замедление трансграничного трафика имело и имеет место быть. Причем у вас все может быть хорошо, а вот у посетителей вашего сайта не очень.
В результате начнет расти процент отказов, будут падать позиции в поисковиках, просядет трафик что напрямую скажется на коммерческом результате. Причем не важно получаете вы доход с сайта напрямую или опосредованно. Для информационного ресурса тоже нет ничего хорошего, просядет рекламный доход.
5️⃣ Блокировки РКН. Под блокировку сегодня можно попасть легко и непринужденно. Просто, потому что где-то рядом у вас плохие соседи и РКН отдал на блокировку целый блок IP-адресов, потому что РКН не договорился с провайдером и т.д. и т.п.
Приятного тут тоже мало. Переезжать с заблокированного ресурса – еще то удовольствие, так как обходит, возможно, придется с двух сторон. С одной – запреты РКН, с другой – санкционные блокировки там.
Ну и вишенкой на торте будет спалиться и попасть под блокировки персональные.
Как настроить выход в интернет через Linux?
Такой вопрос задал один из читателей в комментариях под статьей про базовую установку ОС для сервера.
У нас есть статьи на эту тему, они хоть и довольно старые, но будут работать и сегодня, хотя в современных системах некоторые вещи можно сделать и более изящно.
Но есть одно но, большинство из них предусматривает также настройку кеширующего прокси-сервера SQUID.
На наш взгляд сегодня это абсолютно избыточно, во всяком случае для рядовых коммерческих организаций.
Большинству будет достаточно включить форвардинг пакетов в ядре и настроить SNAT или маскарадинг.
Для этого в /etc/sysctl.conf добавьте:
Подробнее про все это можно прочитать в нашей статье: Основы iptables для начинающих. Часть 4. Таблица nat - типовые сценарии использования
А теперь о том, что же не так со SQUID и почему он сегодня вам, скорее всего, не нужен.
Когда-то давно, когда деревья были большими, а интернет дорогим и медленным SQUID позволят решать эту проблему средством кеширования. Т.е. если у вас один пользователь посетил условный сайт, то все следующие пользователи могут не скачивать с него заново статическое содержимое, а получить его из кеша-прокси сервера.
Это позволило значительно ускорить загрузку сайтов у пользователей и снизить нагрузку на канал.
Вторая задача, которую эффективно решал SQUID - это был контроль доступа: черные и белые списки, контентный фильтр, фильтр по MIME и т.д.
Третья - контроль и отчетность, анализируя логи можно всегда было сказать кто выкачал весь трафик или на какие сайты он ушел.
Но все течет, все меняется. На смену HTTP поголовно пришел HTTPS и выяснилось, что SQUID стал практически бесполезен.
Так как каждый пользователь теперь имеет индивидуальный зашифрованный уникальным одноразовым ключом канал браузер-сайт, то кешировать стало нечего.
Да и в эпоху широкополосного интернета бывает быстрее скачать статику заново, чем искать ее в кеше, особенно если он на тарахтящем HDD.
Фильтровать тоже стало нечего. Трафик закрыт. Да мы можем вскрыть его через SSL-Bump - но это фактическая атака человек посередине и резко снижает безопасность сети.
Если просто вскрывать заголовки и фильтровать по домену назначения, то это становится чудовищно неэффективно по вычислительным затратам. И зачем заниматься расшифровкой, если все тоже самое можно сделать на уровне DNS?
Есть даже специализированные решения, мы подробно рассматривали одно из них в статье: Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Статистика потребленного трафика? А кого она сейчас волнует, сегодня может стать вопрос - кто грузит канал, но не вопрос - кто скачал сколько гигабайт.
Ну а при желании понять кто-куда лазил всегда можно снять статистику с лога DNS.
Таким образом мы не видим сегодня причин использовать прокси, все прекрасно решается и без него.
Но просто так сдавать свои позиции SQUID пока не намерен, но это уже нишевые применения. А это уже совсем другая история.
Такой вопрос задал один из читателей в комментариях под статьей про базовую установку ОС для сервера.
У нас есть статьи на эту тему, они хоть и довольно старые, но будут работать и сегодня, хотя в современных системах некоторые вещи можно сделать и более изящно.
Но есть одно но, большинство из них предусматривает также настройку кеширующего прокси-сервера SQUID.
На наш взгляд сегодня это абсолютно избыточно, во всяком случае для рядовых коммерческих организаций.
Большинству будет достаточно включить форвардинг пакетов в ядре и настроить SNAT или маскарадинг.
Для этого в /etc/sysctl.conf добавьте:
net.ipv4.ip_forward = 1
А в таблицу nat добавить правило:iptables -t nat -A POSTROUTING -o ens33 -s 192.168.100.0/24 -j MASQUERADE
Где ens33 - интерфейс выхода, а 192.168.100.0/24 - диапазон локальной сети.Подробнее про все это можно прочитать в нашей статье: Основы iptables для начинающих. Часть 4. Таблица nat - типовые сценарии использования
А теперь о том, что же не так со SQUID и почему он сегодня вам, скорее всего, не нужен.
Когда-то давно, когда деревья были большими, а интернет дорогим и медленным SQUID позволят решать эту проблему средством кеширования. Т.е. если у вас один пользователь посетил условный сайт, то все следующие пользователи могут не скачивать с него заново статическое содержимое, а получить его из кеша-прокси сервера.
Это позволило значительно ускорить загрузку сайтов у пользователей и снизить нагрузку на канал.
Вторая задача, которую эффективно решал SQUID - это был контроль доступа: черные и белые списки, контентный фильтр, фильтр по MIME и т.д.
Третья - контроль и отчетность, анализируя логи можно всегда было сказать кто выкачал весь трафик или на какие сайты он ушел.
Но все течет, все меняется. На смену HTTP поголовно пришел HTTPS и выяснилось, что SQUID стал практически бесполезен.
Так как каждый пользователь теперь имеет индивидуальный зашифрованный уникальным одноразовым ключом канал браузер-сайт, то кешировать стало нечего.
Да и в эпоху широкополосного интернета бывает быстрее скачать статику заново, чем искать ее в кеше, особенно если он на тарахтящем HDD.
Фильтровать тоже стало нечего. Трафик закрыт. Да мы можем вскрыть его через SSL-Bump - но это фактическая атака человек посередине и резко снижает безопасность сети.
Если просто вскрывать заголовки и фильтровать по домену назначения, то это становится чудовищно неэффективно по вычислительным затратам. И зачем заниматься расшифровкой, если все тоже самое можно сделать на уровне DNS?
Есть даже специализированные решения, мы подробно рассматривали одно из них в статье: Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Статистика потребленного трафика? А кого она сейчас волнует, сегодня может стать вопрос - кто грузит канал, но не вопрос - кто скачал сколько гигабайт.
Ну а при желании понять кто-куда лазил всегда можно снять статистику с лога DNS.
Таким образом мы не видим сегодня причин использовать прокси, все прекрасно решается и без него.
Но просто так сдавать свои позиции SQUID пока не намерен, но это уже нишевые применения. А это уже совсем другая история.
Linux – права файловой системы
Все знают, что Linux унаследовал и использует классическую систему прав UNIX, которая строится вокруг трех субъектов: владельца, группового владельца и остальных, каждый из которых имеет право на чтение – r, запись – w и исполнение – х.
Записываются права посимвольно слева на право: владелец – группа – прочие, для каждого указываются доступные права – rwx, отсутствующее право заменяется прочерком, например:
Для системы это набор трехбитовых записей, где каждый бит соответствует определенному праву, если право доступно – бит устанавливается в единицу.
Т.е. приведенный набор прав можно записать как:
Так чтобы понять, что значит тот или иной набор прав в цифрах – переводим его в двоичную форму и заменяем биты действиями:
Теперь перейдем от файлов к директориям, директория — это такой особый тип файла, который содержит записи о файлах, содержащихся в этой директории.
И права тут значат немного иное: r - право получения имен файлов в каталоге (но не их атрибутов), x - право получения доступа к файлам и их атрибутам, w - право манипулировать именами файлов, т.е. создавать, удалять, переименовывать.
Минимально разумный набор прав к директории r-x, полный rwx.
Поэтому обычно в Linux используются следующие права по умолчанию: 644 для файлов и 755 для директорий.
Т.е. владелец имеет права на запись и чтение файла, группа и остальные – только чтение, а также полный доступ к директории для владельца и только чтение для остальных.
Право на исполнение файлов по умолчанию не устанавливается.
Это – минимальный набор знаний, которые вы должны иметь о правах доступа к файловой системе Linux.
Но не все знают, что на самом деле права доступа это не три, а четыре октета, просто первый ноль часто пропускается и правильно будет не 777, а 0777. Что интересного содержит первый октет?
Там также трехбитовая запись, каждый бит в которой (слева-направо) означает:
При установке данного бита удалить файлы в каталоге может только их владелец или суперпользователь, даже если остальные имеют полные права.
SGID – 010 или 2 - устанавливает группу владельца каталога для каждого создаваемого в нем файла, по умолчанию файлы создаются с группой создавшего его пользователя.
SUID – 100 или 4 – право запускать файл с правами его владельца, а не пользователя который его запустил. Широко используется для ряда системных утилит, таких как passwd. Ведь пользователь должен иметь право изменить сам себе пароль, но для этого необходимы права root, что легко решается через установку SUID.
В буквенной записи SUID и SGID заменяют x на s в правах пользователя или группы, установленный sticky-бит заменяет x на t в правах для остальных.
В восьмеричном виде записывается первым октетом. Например, комбинация stiky + SGID + стандартные права 755 может быть записана так:
Более подробно рекомендуем прочитать в наших статьях:
🔹 Linux - начинающим. Работаем с файловой системой. Теория
🔹 Linux - начинающим. Работаем с файловой системой. Практика
Все знают, что Linux унаследовал и использует классическую систему прав UNIX, которая строится вокруг трех субъектов: владельца, группового владельца и остальных, каждый из которых имеет право на чтение – r, запись – w и исполнение – х.
Записываются права посимвольно слева на право: владелец – группа – прочие, для каждого указываются доступные права – rwx, отсутствующее право заменяется прочерком, например:
rw- r—- r—-
Обозначает право на запись и чтение для владельца и только чтение для группы и прочих.Для системы это набор трехбитовых записей, где каждый бит соответствует определенному праву, если право доступно – бит устанавливается в единицу.
Т.е. приведенный набор прав можно записать как:
110 100 100
Или в более привычной восьмеричной форме:644
Да, несмотря на то что запись ведется привычными десятичными цифрами система указания прав использует восьмеричную систему.Так чтобы понять, что значит тот или иной набор прав в цифрах – переводим его в двоичную форму и заменяем биты действиями:
755 -> 111 101 101 -> rwx r-x r-x
Т.е. полные права у владельца и чтение и исполнение для остальных.Теперь перейдем от файлов к директориям, директория — это такой особый тип файла, который содержит записи о файлах, содержащихся в этой директории.
И права тут значат немного иное: r - право получения имен файлов в каталоге (но не их атрибутов), x - право получения доступа к файлам и их атрибутам, w - право манипулировать именами файлов, т.е. создавать, удалять, переименовывать.
Минимально разумный набор прав к директории r-x, полный rwx.
Поэтому обычно в Linux используются следующие права по умолчанию: 644 для файлов и 755 для директорий.
Т.е. владелец имеет права на запись и чтение файла, группа и остальные – только чтение, а также полный доступ к директории для владельца и только чтение для остальных.
Право на исполнение файлов по умолчанию не устанавливается.
Это – минимальный набор знаний, которые вы должны иметь о правах доступа к файловой системе Linux.
Но не все знают, что на самом деле права доступа это не три, а четыре октета, просто первый ноль часто пропускается и правильно будет не 777, а 0777. Что интересного содержит первый октет?
Там также трехбитовая запись, каждый бит в которой (слева-направо) означает:
SUID – SGID – stiky
sticky-бит – он же 001 или 1 – может быть установлен только для каталога, его установка для файлов игнорируется. В переводе stiky означает – липкий, что полностью соответствует его работе. При установке данного бита удалить файлы в каталоге может только их владелец или суперпользователь, даже если остальные имеют полные права.
SGID – 010 или 2 - устанавливает группу владельца каталога для каждого создаваемого в нем файла, по умолчанию файлы создаются с группой создавшего его пользователя.
SUID – 100 или 4 – право запускать файл с правами его владельца, а не пользователя который его запустил. Широко используется для ряда системных утилит, таких как passwd. Ведь пользователь должен иметь право изменить сам себе пароль, но для этого необходимы права root, что легко решается через установку SUID.
В буквенной записи SUID и SGID заменяют x на s в правах пользователя или группы, установленный sticky-бит заменяет x на t в правах для остальных.
В восьмеричном виде записывается первым октетом. Например, комбинация stiky + SGID + стандартные права 755 может быть записана так:
011 111 101 101 -> 3755 –> rwx r-s r-t
Указанная комбинация часто используется на файловых серверах, когда нужно нарезать права на основе дополнительных групп, а также запретить пользователям удалять чужие файлы.Более подробно рекомендуем прочитать в наших статьях:
🔹 Linux - начинающим. Работаем с файловой системой. Теория
🔹 Linux - начинающим. Работаем с файловой системой. Практика
Некоторые особенности переустановки и удаления пакетов в Apt
Apt – мощный инструмент управления пакетами в Debian и основанных на него дистрибутивах, но он имеет свои особенности, которые следует знать и понимать.
Все знают, что для установки пакета используется:
А для удаления:
Но у данной команды есть своя особенность, она удаляет только сам пакет, но оставляет связанные с ним настройки и данные. Это может быть неудобно, если с пакетом связаны какие-то крупные объемы данных.
Чтобы удалить все, воспользуйтесь другой командой:
Но перед этим убедитесь, что все необходимые данные вы сохранили, потому что она удалит все. Так, если применить эту команду к установленному экземпляру СУБД, то будут удалены в том числе все созданные базы данных.
При этом бывают случаи, когда вы накуролесили в настройках пакета и хотите вернуть все к установкам по умолчанию. При этом простое удаление вам не поможет, а полное вы не хотите использовать, потому что пакет связан с пользовательскими данными.
Для этого есть специальная команда:
Которая приведет пакет в изначальный вид, но не затронет при этом связанные с ним данные.
Apt – мощный инструмент управления пакетами в Debian и основанных на него дистрибутивах, но он имеет свои особенности, которые следует знать и понимать.
Все знают, что для установки пакета используется:
apt install package
А для удаления:
apt remove package
Но у данной команды есть своя особенность, она удаляет только сам пакет, но оставляет связанные с ним настройки и данные. Это может быть неудобно, если с пакетом связаны какие-то крупные объемы данных.
Чтобы удалить все, воспользуйтесь другой командой:
apt purge package
Но перед этим убедитесь, что все необходимые данные вы сохранили, потому что она удалит все. Так, если применить эту команду к установленному экземпляру СУБД, то будут удалены в том числе все созданные базы данных.
При этом бывают случаи, когда вы накуролесили в настройках пакета и хотите вернуть все к установкам по умолчанию. При этом простое удаление вам не поможет, а полное вы не хотите использовать, потому что пакет связан с пользовательскими данными.
Для этого есть специальная команда:
apt reinstall package
Которая приведет пакет в изначальный вид, но не затронет при этом связанные с ним данные.
Использование отчета о состоянии батареи в Windows
Сведения о батарее являются важными для любого владельца ноутбука или иного мобильного устройства под управлением Windows.
Важно не только знать текущий ресурс батареи, но и понимать каким образом он расходуется. Ведь часто виновником малой работы в автономном режиме является вовсе не аккумулятор, а приложения.
Обычно для этого используются сторонние утилиты, но в современных выпусках Windows есть встроенные удобные инструменты, о которых мы сегодня расскажем.
https://interface31.com.ru/tech_it/2024/07/ispol-zovanie-otcheta-o-sostoyanii-batarei-v-windows.html
Сведения о батарее являются важными для любого владельца ноутбука или иного мобильного устройства под управлением Windows.
Важно не только знать текущий ресурс батареи, но и понимать каким образом он расходуется. Ведь часто виновником малой работы в автономном режиме является вовсе не аккумулятор, а приложения.
Обычно для этого используются сторонние утилиты, но в современных выпусках Windows есть встроенные удобные инструменты, о которых мы сегодня расскажем.
https://interface31.com.ru/tech_it/2024/07/ispol-zovanie-otcheta-o-sostoyanii-batarei-v-windows.html
Файловая база 1С:Предприятия – проблемы и решения
Последнее время начали поступать вопросы по поводу файловой базы 1С:Предприятие, но в комментариях трудно дать развернутый ответ, поэтому мы решили написать эту заметку.
Как мы знаем, в основе современной архитектуры 1С лежит так называемая «трехзвенка»: клиент – сервер – СУБД.
Каждый из этих компонентов занят своим делом: клиент – обработкой данных, вносимых пользователем, сервер – запросами к БД и обработкой информации, запрошенной из нее клиентом или, наоборот, записываемой, СУБД хранит всю эту информацию.
Файловая база данных представляет собой файл специального формата собственной базы данных 1С:Предприятие. Он называется 1Cv8.1CD и представляет основную ценность, несмотря на то что папка с базой содержит иные файлы и каталоги только он содержит полезные данные и для копирования базы достаточно перенести только этот файл.
Для резервного копирования мы также должны скопировать именно этот файл, а не дамп базы в формате DT. Еще раз обратим ваше внимание, что сам вендор в официальной документации предупреждает, что DT не предназначен для резервного копирования.
Но вернемся к нашей файловой базе, как мы уже сказали – это файл БД собственного формата, который играет роль СУБД в трехзвенной схеме. Остальные два звена обеспечивает платформа на рабочей станции пользователя. Там запускается серверный и клиентский экземпляр, которые и выполняют соответствующий код.
Если все эти три звена расположены на одном компьютере, то работает такая база достаточно неплохо, по крайней мере до тех пор, пока не разрастется по размерам.
В былые времена пределом размера файловой БД было примерно около 4 ГБ, сейчас, с приходом недорогих и быстрых NVMe этот предел сильно вырос и в файловом варианте неплохо ворочаются базы и по 10 – 20 ГБ.
Но вся эта благодать быстро исчезает при необходимости работать с базой более чем одному человеку.
Обычный сценарий – это сетевой доступ к информационной базе, когда файл базы выкладывается на общий ресурс и к нему подключаются по сети клиенты.
При этом практически вся информация гоняется по сети, причем в достаточно значительных объемах. Это ведет к долгой загрузке базы и замедлении операций, требующих доступ к данным, которых нет в локальном кеше.
Но беда не в этом, а во взаимных блокировках, которые пользователи накладывают на базу данных при работе.
Именно это, а не сетевые задержки становится главной проблемой многопользовательской работы с файловой базой данных 1С:Предприятие.
Поэтому бесполезно пытаться делать какие-то настройки на уровне сети или сетевого хранилища, так как проблема находится в другом месте.
Критическим количеством одновременных пользователей для файловой базы является в зависимости от характера работы 3-5 человек (иногда больше).
Что делать? Вариантов тут не много. Самый простой – веб-сервер, в этом случае серверная часть будет работать на ПК с веб-сервером, а клиентская на тонком клиенте. При использовании веб-клиента весь код будет исполняться на веб-сервере.
Следует помнить, что веб-клиент с файловой базой однопоточен, но это по факту меньшее зло, при небольшом количестве пользователей однопоточность не становится узким горлышком, но при этом снимается проблема блокировок.
Поэтому переход на веб-сервер с файловой базой в большинстве случаев ускоряет работу и рекомендуется к применению даже в небольших сетях.
Второй вариант – переход на клиент-серверную технологию. Да, это довольно дорого, но если вам достаточно 5 сеансов, то можно приобрести Сервер-МИНИ за очень небольшие деньги (19 300 руб. на настоящий момент).
Также есть небольшая хитрость, если у вас несколько баз с небольшим количеством пользователей, то можно купить и развернуть несколько экземпляров Сервера-МИНИ, что будет дешевле покупки полноценного сервера 1С:Предприятие за 115 200 руб.
Последнее время начали поступать вопросы по поводу файловой базы 1С:Предприятие, но в комментариях трудно дать развернутый ответ, поэтому мы решили написать эту заметку.
Как мы знаем, в основе современной архитектуры 1С лежит так называемая «трехзвенка»: клиент – сервер – СУБД.
Каждый из этих компонентов занят своим делом: клиент – обработкой данных, вносимых пользователем, сервер – запросами к БД и обработкой информации, запрошенной из нее клиентом или, наоборот, записываемой, СУБД хранит всю эту информацию.
Файловая база данных представляет собой файл специального формата собственной базы данных 1С:Предприятие. Он называется 1Cv8.1CD и представляет основную ценность, несмотря на то что папка с базой содержит иные файлы и каталоги только он содержит полезные данные и для копирования базы достаточно перенести только этот файл.
Для резервного копирования мы также должны скопировать именно этот файл, а не дамп базы в формате DT. Еще раз обратим ваше внимание, что сам вендор в официальной документации предупреждает, что DT не предназначен для резервного копирования.
Но вернемся к нашей файловой базе, как мы уже сказали – это файл БД собственного формата, который играет роль СУБД в трехзвенной схеме. Остальные два звена обеспечивает платформа на рабочей станции пользователя. Там запускается серверный и клиентский экземпляр, которые и выполняют соответствующий код.
Если все эти три звена расположены на одном компьютере, то работает такая база достаточно неплохо, по крайней мере до тех пор, пока не разрастется по размерам.
В былые времена пределом размера файловой БД было примерно около 4 ГБ, сейчас, с приходом недорогих и быстрых NVMe этот предел сильно вырос и в файловом варианте неплохо ворочаются базы и по 10 – 20 ГБ.
Но вся эта благодать быстро исчезает при необходимости работать с базой более чем одному человеку.
Обычный сценарий – это сетевой доступ к информационной базе, когда файл базы выкладывается на общий ресурс и к нему подключаются по сети клиенты.
При этом практически вся информация гоняется по сети, причем в достаточно значительных объемах. Это ведет к долгой загрузке базы и замедлении операций, требующих доступ к данным, которых нет в локальном кеше.
Но беда не в этом, а во взаимных блокировках, которые пользователи накладывают на базу данных при работе.
Именно это, а не сетевые задержки становится главной проблемой многопользовательской работы с файловой базой данных 1С:Предприятие.
Поэтому бесполезно пытаться делать какие-то настройки на уровне сети или сетевого хранилища, так как проблема находится в другом месте.
Критическим количеством одновременных пользователей для файловой базы является в зависимости от характера работы 3-5 человек (иногда больше).
Что делать? Вариантов тут не много. Самый простой – веб-сервер, в этом случае серверная часть будет работать на ПК с веб-сервером, а клиентская на тонком клиенте. При использовании веб-клиента весь код будет исполняться на веб-сервере.
Следует помнить, что веб-клиент с файловой базой однопоточен, но это по факту меньшее зло, при небольшом количестве пользователей однопоточность не становится узким горлышком, но при этом снимается проблема блокировок.
Поэтому переход на веб-сервер с файловой базой в большинстве случаев ускоряет работу и рекомендуется к применению даже в небольших сетях.
Второй вариант – переход на клиент-серверную технологию. Да, это довольно дорого, но если вам достаточно 5 сеансов, то можно приобрести Сервер-МИНИ за очень небольшие деньги (19 300 руб. на настоящий момент).
Также есть небольшая хитрость, если у вас несколько баз с небольшим количеством пользователей, то можно купить и развернуть несколько экземпляров Сервера-МИНИ, что будет дешевле покупки полноценного сервера 1С:Предприятие за 115 200 руб.
