Режимы выделения виртуальной памяти в Linux
Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.
Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.
Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).
И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса.
Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.
Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.
Режим работы этого механизма можно задать при помощи опции
Которая может принимать одно из трех значений: 0, 1 и 2
🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.
В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.
Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.
Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой.
🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).
Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer.
🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:
Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:
По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.
Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.
Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.
В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.
Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.
Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.
Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).
И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса.
Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.
Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.
Режим работы этого механизма можно задать при помощи опции
vm.overcommit_memory
Которая может принимать одно из трех значений: 0, 1 и 2
🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.
В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.
Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.
Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой.
🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).
Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer.
🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:
vm.overcommit_ratio = 100
Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:
CommitLimit = swap_total + (RAM_total × vm.overcommit_ratio / 100)
По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.
Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.
Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.
В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%.
👍15❤1
Как в Linux узнать скорость USB-портов и их текущий режим работы
Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных.
Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться.
Первый приходящий на ум вариант – заглянуть в документацию, но это не всегда возможно, тем более документация не покажет нам реальный режим работы устройства.
Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:
Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств.
Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:
▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2
Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.
Вопрос достаточно интересный и непраздный, очень часто нужно определить наиболее быстрый USB-порт устройства, чтобы, например, перекинуть большой объем данных.
Воткнуть в синий порт давно уже не вариант, так как разновидностей стандарта USB 3.x сегодня несколько и скорость работы там может существенно отличаться.
Первый приходящий на ум вариант – заглянуть в документацию, но это не всегда возможно, тем более документация не покажет нам реальный режим работы устройства.
Но в Linux указанную информацию получить не просто, а очень просто, достаточно выполнить команду:
lsusb -t
Которая покажет номинальные скорости концентраторов и режимы работы подключенных к ним устройств.
Расшифровать значения также не сложно, они соответствуют значениям скорости в МБ/с, а именно:
▫️12М - USB 1.0
▫️480M – USB 2.0
▫️5000M - USB 3.2 Gen 1 (USB 3.0)
▫️10000M - USB 3.2 Gen 2 (USB 3.1)
▫️20000M/x2 - USB 3.2 Gen 2x2
Реальный вывод команды показан на скриншоте из которого четко видны режимы работы концентраторов и портов.
👍23🔥5
Визуальный калькулятор подсетей
При расчете и планировании подсетей многие используют специальные сетевые калькуляторы, но не все могут сразу представить себе полный расклад и взаимное расположение получившихся сетей, что иногда приводит к неприятным казусам.
Обычно это решается графическими построениями на бумаге или в Excel, но есть способ лучше – использовать Visual Subnet Calculator, открытый продукт, распространяющийся под лицензией MIT.
Проще и быстрее всего запустить его в Docker:
Теперь открываем
Все результаты тут же отображаются в таблице, а справа мы видим визуальное отображение нашей сети и сразу можем планировать рациональное распределение адресного пространства, агрегирование маршрутов и т.д. и т.п. Причем делать это интерактивно, в реальном времени.
Утилита имеет четыре режима работы: стандартный и специализированный расчет для AWS, Azure и Oracle Cloud.
Подобные инструменты вроде бы мелочь, но способны существенно упростить и облегчить жизнь, особенно если вы не постоянно занимаетесь расчетом сетей. Рекомендуем включить в собственный набор инструментов.
При расчете и планировании подсетей многие используют специальные сетевые калькуляторы, но не все могут сразу представить себе полный расклад и взаимное расположение получившихся сетей, что иногда приводит к неприятным казусам.
Обычно это решается графическими построениями на бумаге или в Excel, но есть способ лучше – использовать Visual Subnet Calculator, открытый продукт, распространяющийся под лицензией MIT.
Проще и быстрее всего запустить его в Docker:
docker run -d -p 8081:8080 --name visualsubnetcalc ckabalan/visualsubnetcalc:latest
Теперь открываем
http://myhost:8081 и начинаем работать. Сначала задаем желаемую сеть верхнего уровня и начинаем делить ее мышкой. Нажатие на сеть нижнего уровня делит ее на две равных подсети, нажатие на сеть верхнего уровня сворачивает все подсети под ней. Все результаты тут же отображаются в таблице, а справа мы видим визуальное отображение нашей сети и сразу можем планировать рациональное распределение адресного пространства, агрегирование маршрутов и т.д. и т.п. Причем делать это интерактивно, в реальном времени.
Утилита имеет четыре режима работы: стандартный и специализированный расчет для AWS, Azure и Oracle Cloud.
Подобные инструменты вроде бы мелочь, но способны существенно упростить и облегчить жизнь, особенно если вы не постоянно занимаетесь расчетом сетей. Рекомендуем включить в собственный набор инструментов.
👍13🔥9❤4
Как обустроить современный корпоративный VPN
Сегодня многие пользователи сталкиваются со сложностями в работе VPN-соединений благодаря заботе о нас одного уважаемого ведомства.
Забота эта достаточно непредсказуема и может коснуться каждого. Поэтому у многих возникает вопрос: а как жить дальше в этом непредсказуемом мире. Причем мы говорим о сугубо законопослушном использовании VPN для корпоративных нужд.
Поэтому мы с коллегами проанализировали и обобщили практику, на основе которой выработали современную модель удаленного доступа, максимально оптимизированную к текущим условиям.
Как показывает практика, наиболее устойчивы к блокировкам крупные российские датацентры. Поэтому возникает вполне закономерная схема их использования для размещения VPN-серверов.
Тот же Cloud.ru дает неплохую виртуалку бесплатно в рамках free tier, все что вам останется – это купить белый IP-адрес, который обойдется примерно в 150 руб./мес.
Также многие датацентры предоставляют IPsec соединения от облачной инфраструктуры к вашей сети, обеспечивая максимально быстрый и производительный канал для обмена данными.
Таким образом наша схема приобретает законченные очертания. Приобретаем виртуалку в крупном отечественном датацентре и разворачиваем там VPN-сервер для доступа удаленных сотрудников.
Соединяем ее или виртуальную сеть облака быстрым каналом с офисом, лучше всего для этого использовать предоставляемый хостером IPsec или самостоятельно поднять аналогичный канал в офисную сеть.
Задача выполнена. Удаленные клиенты соединяются с доверенным облаком, блокировки которого гораздо менее вероятны, нежели блокировки офисного адреса, а офис общается с удаленной площадкой по туннелю IPsec, который также имеет крайне невысокий риск блокировки.
Хотя как именно организовать канал – это дело сугубо личное. Но в любом случае перенастроить одно подключение проще, нежели чем десяток-другой клиентских.
Сегодня многие пользователи сталкиваются со сложностями в работе VPN-соединений благодаря заботе о нас одного уважаемого ведомства.
Забота эта достаточно непредсказуема и может коснуться каждого. Поэтому у многих возникает вопрос: а как жить дальше в этом непредсказуемом мире. Причем мы говорим о сугубо законопослушном использовании VPN для корпоративных нужд.
Поэтому мы с коллегами проанализировали и обобщили практику, на основе которой выработали современную модель удаленного доступа, максимально оптимизированную к текущим условиям.
Как показывает практика, наиболее устойчивы к блокировкам крупные российские датацентры. Поэтому возникает вполне закономерная схема их использования для размещения VPN-серверов.
Тот же Cloud.ru дает неплохую виртуалку бесплатно в рамках free tier, все что вам останется – это купить белый IP-адрес, который обойдется примерно в 150 руб./мес.
Также многие датацентры предоставляют IPsec соединения от облачной инфраструктуры к вашей сети, обеспечивая максимально быстрый и производительный канал для обмена данными.
Таким образом наша схема приобретает законченные очертания. Приобретаем виртуалку в крупном отечественном датацентре и разворачиваем там VPN-сервер для доступа удаленных сотрудников.
Соединяем ее или виртуальную сеть облака быстрым каналом с офисом, лучше всего для этого использовать предоставляемый хостером IPsec или самостоятельно поднять аналогичный канал в офисную сеть.
Задача выполнена. Удаленные клиенты соединяются с доверенным облаком, блокировки которого гораздо менее вероятны, нежели блокировки офисного адреса, а офис общается с удаленной площадкой по туннелю IPsec, который также имеет крайне невысокий риск блокировки.
Хотя как именно организовать канал – это дело сугубо личное. Но в любом случае перенастроить одно подключение проще, нежели чем десяток-другой клиентских.
👍15🤔4🤝2❤1
VPN-протоколы, степени риска
Не так давно, в связи с потребностями наших заказчиков мы провели достаточно объемное исследование на тему рисков использования VPN-протоколов для использования их в корпоративных целях и хотим поделиться некоторыми результатами.
Исследование основано на изучении публикаций в сети, доступных документов регулятора, доступной статистики и не претендует на всеобъемлющее или истину в последней инстанции.
Начнем с общих причин и следствий. VPN широко используются как средство пойти туда, не надо куда и чем более популярен в этих целях протокол, тем выше вероятность его блокировки.
При этом мы не можем знать принципов и направлений блокировок, а, следовательно, проблемы могут возникнуть и у корпоративных клиентов, использующих протокол сугубо для внутренней связи внутри страны.
Исходя из этого, а также из сложившейся практики блокировок мы подготовили краткий анализ протоколов удаленного доступа:
🔴 L2TP/IPsec – риски крайне высокие, сигнатуры выгружены для блокировки, кроме того, протокол обладает крайне низкой устойчивостью, есть проблемы в сетях мобильных операторов, проблемы нескольких клиентов из-за одного NAT и т.д.
🟠 IKEv2/IPsec – риски высокие, UDP-сигнатуры прекрасно видны, сам протокол также широко использовался в известных целях. Устойчивость высокая, стабильно работает в сетях различных операторов, но также имеет высокую сложность настройки и отладки.
🔴 OpenVPN – классика жанра, риски высокие, устойчивость средняя, без дополнительной настройки может иметь низкую производительность на плохих каналах, самые высокие накладные расходы. Из плюсов – передача настроек с сервера на клиент.
🔴 WireGuard – риски очень высокие, легко детектируется и активно блокируется. Устойчивость высокая, но при этом имеет повышенные накладные расходы на администрирование в корпоративной среде.
🟢 SSTP – риски ниже среднего, это объясняется тем, что протокол проприетарный и в основном применение ограничено экосистемой Windows, ну и, пожалуй, Mikrotik. Для указанных целей практически не используется. Устойчивость высокая, практически не отличим от HTTPS, но при необходимости легко детектируется. Работает даже там, где заблокирован практически весь интернет.
🟢 OpenConnect – риски низкие, устойчивость высокая, внешне представляет реалистичный HTTPS-трафик, для обозначенных целей практически не используется. Привлекателен в корпоративной среде благодаря возможностям передачи настроек с сервера на клиент.
🟠 GRE/IPIP – риски низкие, устойчивость также низкая, имеют проблему прохождения NAT, не работают в сетях мобильных операторов, небезопасны. IPIP архитектурно ограничен только IP-трафиком.
🟢 IPsec – риски низкие, в основном используется для корпоративных и магистральных коммуникаций. Устойчивость выше средней, но также присутствуют требования к сторонам соединения (белые адреса и т.д.). Сложность настройки и отладки – крайне высокая, требует специальных знаний и навыков.
🟢 GRE/IPIP over IPsec – риски низкие, устойчивость выше средней. Внешне это тот же IPsec со всеми плюсами и минусами. Внутри привычные GRE/IPIP туннели. Сложность эксплуатации выше средней из-за присутствия IPsec, но значительно ниже, чем у чистого IPsec.
👉 Исходя из вышесказанного для целей удаленного доступа (Road-Warrior) рекомендуются SSL-VPN решения, такие как SSTP или OpenConnect, последний очень хорошо впишется в корпоративную сеть как полноценная замена OpenVPN с возможностью централизованного управления настройками клиентов.
Для соединения площадок (Site-to-Site) следует предпочитать решения на базе IPsec, наилучшим вариантом здесь будет GRE over IPsec, который сочетает сильные стороны IPsec с понятной сетевой моделью туннелей GRE, основанной на классической маршрутизации, а не на политиках.
‼️ Решений с высоким риском следует во всех сценариях избегать, даже если они еще работают, потому что в любой момент все может неожиданно измениться.
Не так давно, в связи с потребностями наших заказчиков мы провели достаточно объемное исследование на тему рисков использования VPN-протоколов для использования их в корпоративных целях и хотим поделиться некоторыми результатами.
Исследование основано на изучении публикаций в сети, доступных документов регулятора, доступной статистики и не претендует на всеобъемлющее или истину в последней инстанции.
Начнем с общих причин и следствий. VPN широко используются как средство пойти туда, не надо куда и чем более популярен в этих целях протокол, тем выше вероятность его блокировки.
При этом мы не можем знать принципов и направлений блокировок, а, следовательно, проблемы могут возникнуть и у корпоративных клиентов, использующих протокол сугубо для внутренней связи внутри страны.
Исходя из этого, а также из сложившейся практики блокировок мы подготовили краткий анализ протоколов удаленного доступа:
🔴 L2TP/IPsec – риски крайне высокие, сигнатуры выгружены для блокировки, кроме того, протокол обладает крайне низкой устойчивостью, есть проблемы в сетях мобильных операторов, проблемы нескольких клиентов из-за одного NAT и т.д.
🟠 IKEv2/IPsec – риски высокие, UDP-сигнатуры прекрасно видны, сам протокол также широко использовался в известных целях. Устойчивость высокая, стабильно работает в сетях различных операторов, но также имеет высокую сложность настройки и отладки.
🔴 OpenVPN – классика жанра, риски высокие, устойчивость средняя, без дополнительной настройки может иметь низкую производительность на плохих каналах, самые высокие накладные расходы. Из плюсов – передача настроек с сервера на клиент.
🔴 WireGuard – риски очень высокие, легко детектируется и активно блокируется. Устойчивость высокая, но при этом имеет повышенные накладные расходы на администрирование в корпоративной среде.
🟢 SSTP – риски ниже среднего, это объясняется тем, что протокол проприетарный и в основном применение ограничено экосистемой Windows, ну и, пожалуй, Mikrotik. Для указанных целей практически не используется. Устойчивость высокая, практически не отличим от HTTPS, но при необходимости легко детектируется. Работает даже там, где заблокирован практически весь интернет.
🟢 OpenConnect – риски низкие, устойчивость высокая, внешне представляет реалистичный HTTPS-трафик, для обозначенных целей практически не используется. Привлекателен в корпоративной среде благодаря возможностям передачи настроек с сервера на клиент.
🟠 GRE/IPIP – риски низкие, устойчивость также низкая, имеют проблему прохождения NAT, не работают в сетях мобильных операторов, небезопасны. IPIP архитектурно ограничен только IP-трафиком.
🟢 IPsec – риски низкие, в основном используется для корпоративных и магистральных коммуникаций. Устойчивость выше средней, но также присутствуют требования к сторонам соединения (белые адреса и т.д.). Сложность настройки и отладки – крайне высокая, требует специальных знаний и навыков.
🟢 GRE/IPIP over IPsec – риски низкие, устойчивость выше средней. Внешне это тот же IPsec со всеми плюсами и минусами. Внутри привычные GRE/IPIP туннели. Сложность эксплуатации выше средней из-за присутствия IPsec, но значительно ниже, чем у чистого IPsec.
👉 Исходя из вышесказанного для целей удаленного доступа (Road-Warrior) рекомендуются SSL-VPN решения, такие как SSTP или OpenConnect, последний очень хорошо впишется в корпоративную сеть как полноценная замена OpenVPN с возможностью централизованного управления настройками клиентов.
Для соединения площадок (Site-to-Site) следует предпочитать решения на базе IPsec, наилучшим вариантом здесь будет GRE over IPsec, который сочетает сильные стороны IPsec с понятной сетевой моделью туннелей GRE, основанной на классической маршрутизации, а не на политиках.
‼️ Решений с высоким риском следует во всех сценариях избегать, даже если они еще работают, потому что в любой момент все может неожиданно измениться.
👍25🥱1
Защищаем сетевые службы при помощи stunnel
Говоря о защите сетевых служб, многие администраторы сразу вспоминают о VPN, нередко забывая об иных, не менее эффективных способах. Да, VPN позволяет эффективно решить эту задачу, но не всегда бывает удобен и очень часто избыточен.
Особенно если нужно защитить одну - две сетевые службы. Поэтому давайте посмотрим на доступные альтернативы, одна из них - это stunnel, SSL-прокси с широкими возможностями, одна из них - создание защищенного соединения между двумя узлами.
Чтобы понять для каких случаев предпочтительнее stunnel снова вернемся к VPN, при всех ее достоинствах некоторые из них могут обернуться недостатками.
С помощью VPN легко предоставить доступ ко всем ресурсам внутренней сети, но если с той стороны находится неконтролируемый или внештатный сотрудник (скажем бухгалтер на аутсорсинге), то этот плюс моментально превращается в минус. И нам уже надо думать не о том, как доступ к сети предоставить, а о том, как бы его закрыть.
В то же время stunnel предусматривает совершенно иной принцип работы, он работает на уровне TCP-соединений и позволяет просто и эффективно защитить его при помощи современного шифрования.
С его помощью клиент будет иметь доступ к одному единственному порту сетевой службы и никуда более. При необходимости можно настроить несколько таких соединений.
Для примера мы рассмотрим организацию доступа к веб-серверу с опубликованной на нем базой 1С:Предприятия, доступ к которой должен иметь удаленный сотрудник.
Будем считать, что веб-сервер с модулем расширения 1С установлен на машине с Linux (Debian или Ubuntu) расположенной в локальной сети предприятия, веб-сервер принимает подключения по протоколу HTTP без шифрования. Задача - обеспечить доступ к 1С с рабочего места бухгалтера.
✅ Читать далее: https://interface31.ru/post/zashhishhaem-setevye-sluzhby-pri-pomoshhi-stunnel/
Говоря о защите сетевых служб, многие администраторы сразу вспоминают о VPN, нередко забывая об иных, не менее эффективных способах. Да, VPN позволяет эффективно решить эту задачу, но не всегда бывает удобен и очень часто избыточен.
Особенно если нужно защитить одну - две сетевые службы. Поэтому давайте посмотрим на доступные альтернативы, одна из них - это stunnel, SSL-прокси с широкими возможностями, одна из них - создание защищенного соединения между двумя узлами.
Чтобы понять для каких случаев предпочтительнее stunnel снова вернемся к VPN, при всех ее достоинствах некоторые из них могут обернуться недостатками.
С помощью VPN легко предоставить доступ ко всем ресурсам внутренней сети, но если с той стороны находится неконтролируемый или внештатный сотрудник (скажем бухгалтер на аутсорсинге), то этот плюс моментально превращается в минус. И нам уже надо думать не о том, как доступ к сети предоставить, а о том, как бы его закрыть.
В то же время stunnel предусматривает совершенно иной принцип работы, он работает на уровне TCP-соединений и позволяет просто и эффективно защитить его при помощи современного шифрования.
С его помощью клиент будет иметь доступ к одному единственному порту сетевой службы и никуда более. При необходимости можно настроить несколько таких соединений.
Для примера мы рассмотрим организацию доступа к веб-серверу с опубликованной на нем базой 1С:Предприятия, доступ к которой должен иметь удаленный сотрудник.
Будем считать, что веб-сервер с модулем расширения 1С установлен на машине с Linux (Debian или Ubuntu) расположенной в локальной сети предприятия, веб-сервер принимает подключения по протоколу HTTP без шифрования. Задача - обеспечить доступ к 1С с рабочего места бухгалтера.
✅ Читать далее: https://interface31.ru/post/zashhishhaem-setevye-sluzhby-pri-pomoshhi-stunnel/
👍18🔥3❤1👌1
Кто-то думал иначе?
В последние дни пользователи Облако Mail.ru, ставшие в свое время обладателями акционного вечного терабайта стали получать письма о том, что очень скоро этот "аттракцион невиданной щедрости" будет прекращен.
Ключевые даты:
🔹 30 октября 2026 года - 1 ТБ превращается втыкву стандартные 8 ГБ.
🔹 30 января 2027 года - начинается удаление файлов превышающих лимит.
🔹 3 февраля 2027 года - все лишние файлы будут удалены.
И до тех пор пока вы не освободите место, работать у вас не будет не только облако, но и почта.
🤷♀️ Ну а что, кто-то ждал иного?
В последние дни пользователи Облако Mail.ru, ставшие в свое время обладателями акционного вечного терабайта стали получать письма о том, что очень скоро этот "аттракцион невиданной щедрости" будет прекращен.
Ключевые даты:
🔹 30 октября 2026 года - 1 ТБ превращается в
🔹 30 января 2027 года - начинается удаление файлов превышающих лимит.
🔹 3 февраля 2027 года - все лишние файлы будут удалены.
И до тех пор пока вы не освободите место, работать у вас не будет не только облако, но и почта.
🤷♀️ Ну а что, кто-то ждал иного?
😁29🔥6🤷♂3🤬3❤2
Как быть если потеряли лицензию от 1С?
Сразу начнем с того, что вы потеряли. Если аппаратный ключ, то сразу можете идти покупать новый, даже если остался полный комплект документов.
Сломанные и сгоревшие USB-ключи меняют (во всяком случае раньше меняли, сейчас возможен вариант с заменой на программную лицензию). Но вам обязательно потребуется сдать обломки от ключа.
Потеряли пин-коды? Не беда, достаточно знать регистрационный номер поставки (написан на коробке и в регистрационной анкете) и адрес электронной почты, который указывали при активации.
После чего идем на https://portal.1c.ru/support/license и получаем что нам нужно, а получить можно:
🔹 Информацию о владельце
🔹Текущее состояние пин-кодов
🔹 Резервный пин-код
Либо обращаемся с этой информацией на линию поддержки по вопросам лицензирования
Обычно
Дальше снова или идем на сайт, или на линию поддержки. Так как номер и данные владельца вам известны, то достаточно запросить текущее состояние пин-кодов и резервный пин при необходимости.
Ну или просто ищем на диске файлы с расширением
☝️ И еще тонкость, если есть такая возможность, то обращения на линию поддержки следует писать с того адреса, который был указан при регистрации лицензии. Во многих случаях это значительно ускоряет процесс.
Сразу начнем с того, что вы потеряли. Если аппаратный ключ, то сразу можете идти покупать новый, даже если остался полный комплект документов.
Сломанные и сгоревшие USB-ключи меняют (во всяком случае раньше меняли, сейчас возможен вариант с заменой на программную лицензию). Но вам обязательно потребуется сдать обломки от ключа.
Потеряли пин-коды? Не беда, достаточно знать регистрационный номер поставки (написан на коробке и в регистрационной анкете) и адрес электронной почты, который указывали при активации.
После чего идем на https://portal.1c.ru/support/license и получаем что нам нужно, а получить можно:
🔹 Информацию о владельце
🔹Текущее состояние пин-кодов
🔹 Резервный пин-код
Либо обращаемся с этой информацией на линию поддержки по вопросам лицензирования
lic@1c.ru
Если коробок и анкет нет, но программа работает, то заходим в Сведения о программе и там видим регистрационный номер активной лицензии, ее владельца и путь расположения файла программной лицензииОбычно
C:/ProgramData/1C/licence
Затем качаем утилиту LicDataViewer, это удобная обертка над стандартными Ring и License Tools, натравливаем его на файл программной лицензии и получаем сведения о регистрационном номере, использованном пин-коде и введенной информации о владельце. Дальше снова или идем на сайт, или на линию поддержки. Так как номер и данные владельца вам известны, то достаточно запросить текущее состояние пин-кодов и резервный пин при необходимости.
Ну или просто ищем на диске файлы с расширением
.lic, скажем, в тех случаях, если упала система или отказало оборудование.☝️ И еще тонкость, если есть такая возможность, то обращения на линию поддержки следует писать с того адреса, который был указан при регистрации лицензии. Во многих случаях это значительно ускоряет процесс.
1👍13❤2🔥1🤬1
Временные метки файлов в Linux
Этот, вроде-бы простой на первый взгляд вопрос часто вызывает достаточно много сложностей, особенно у начинающих.
Согласно стандарту POSIX у файлов в Linux имеются три временных метки:
▫️ atime – время последнего доступа к файлу
▫️ mtime – время последней модификации содержимого файла
▫️ ctime – время последнего изменения содержимого файла или его метаданных
С первой меткой вроде бы все просто, atime обновляется при любом доступе к файлу, однако по умолчанию в большинстве систем включен режим
Метка mtime меняется при изменении содержимого файла, но ее не меняют изменения метаданных, такие как изменение владельца или прав доступа или переименование.
И, наконец, ctime, которая фиксирует любое изменение файла, будь то изменение содержимого или метаданных. Хотя во многих материалах метка ctime ошибочно описывается как время последнего изменения метаданных.
Особенностью метки ctime является то, что данная метка управляется системой, в то время как atime и mtime может произвольно изменять владелец файла. Таким образом данная метка однозначно покажет нам время последнего изменения файла, в то время как mtime может содержать неверную информацию.
При этом в нормальных условиях изменение mtime всегда влечет изменение ctime, а вот изменение ctime может происходить отдельно от других временных меток.
Так переименование файла изменит только ctime (а также затронет родительский каталог), но не отразится на mtime, а изменение прав или владельца файла затронет только ctime.
Позвольте, скажет иной читатель, а как быть с временем создания файла? А никак, такой временной метки POSIX не предусматривает. Однако позже была добавлена еще одна временная метка – crtime – которая как раз отражает время создания файла, но она имеет некоторые особенности.
Не являясь POSIX-совместимой, данная метка была реализована на уровне файловой системы и, следовательно, хранится только в ее пределах, между системами данный атрибут не переносится.
Таким образом данная метка отражает время создания файла в текущей файловой системе и при переносе файла между файловыми системами данная метка у него изменится, в то время как остальные временные метки будут сохранены.
Это может приводить к ситуации, показанной на рисунке ниже, когда время создания файла больше, чем время его модификации.
Каким образом можно посмотреть временные метки? Используйте команду stat, например:
Строки Доступ, Модифицирован и Изменен будут соответствовать atime, mtime и ctime. Однако если мы посмотрим на свойства файла в графическом окружении, то сможем увидеть, что Изменен в этом случае соответствует mtime, что в целом верно логически, но способно внести путаницу.
Поэтому, если вы хотите получить точное значение параметра, то используйте форматирование вывода команды stat:
Как видим, вроде бы простая тема оказалась не такой уж и простой. Но, если не пытаться переносить на Linux опыт других систем, а внимательно изучить теорию, то все станет на свои места и вы будете прекрасно понимать, что значит та или иная временная метка.
Этот, вроде-бы простой на первый взгляд вопрос часто вызывает достаточно много сложностей, особенно у начинающих.
Согласно стандарту POSIX у файлов в Linux имеются три временных метки:
▫️ atime – время последнего доступа к файлу
▫️ mtime – время последней модификации содержимого файла
▫️ ctime – время последнего изменения содержимого файла или его метаданных
С первой меткой вроде бы все просто, atime обновляется при любом доступе к файлу, однако по умолчанию в большинстве систем включен режим
relatime (метка обновляется не чаще раза в сутки, если файл не менялся), а при опции noatime обновление отключено вовсеМетка mtime меняется при изменении содержимого файла, но ее не меняют изменения метаданных, такие как изменение владельца или прав доступа или переименование.
И, наконец, ctime, которая фиксирует любое изменение файла, будь то изменение содержимого или метаданных. Хотя во многих материалах метка ctime ошибочно описывается как время последнего изменения метаданных.
Особенностью метки ctime является то, что данная метка управляется системой, в то время как atime и mtime может произвольно изменять владелец файла. Таким образом данная метка однозначно покажет нам время последнего изменения файла, в то время как mtime может содержать неверную информацию.
При этом в нормальных условиях изменение mtime всегда влечет изменение ctime, а вот изменение ctime может происходить отдельно от других временных меток.
Так переименование файла изменит только ctime (а также затронет родительский каталог), но не отразится на mtime, а изменение прав или владельца файла затронет только ctime.
Позвольте, скажет иной читатель, а как быть с временем создания файла? А никак, такой временной метки POSIX не предусматривает. Однако позже была добавлена еще одна временная метка – crtime – которая как раз отражает время создания файла, но она имеет некоторые особенности.
Не являясь POSIX-совместимой, данная метка была реализована на уровне файловой системы и, следовательно, хранится только в ее пределах, между системами данный атрибут не переносится.
Таким образом данная метка отражает время создания файла в текущей файловой системе и при переносе файла между файловыми системами данная метка у него изменится, в то время как остальные временные метки будут сохранены.
Это может приводить к ситуации, показанной на рисунке ниже, когда время создания файла больше, чем время его модификации.
Каким образом можно посмотреть временные метки? Используйте команду stat, например:
stat file.txtСтроки Доступ, Модифицирован и Изменен будут соответствовать atime, mtime и ctime. Однако если мы посмотрим на свойства файла в графическом окружении, то сможем увидеть, что Изменен в этом случае соответствует mtime, что в целом верно логически, но способно внести путаницу.
Поэтому, если вы хотите получить точное значение параметра, то используйте форматирование вывода команды stat:
stat -c '%x' file.txt - atimestat -c '%y' file.txt - mtimestat -c '%z' file.txt - ctimeКак видим, вроде бы простая тема оказалась не такой уж и простой. Но, если не пытаться переносить на Linux опыт других систем, а внимательно изучить теорию, то все станет на свои места и вы будете прекрасно понимать, что значит та или иная временная метка.
1🤝4👍1