Записки IT специалиста

Подписка на Лента Записки IT специалиста Записки IT специалиста
Технический блог специалистов ООО"Интерфейс"
Обновлено: 1 день 23 часа назад

Как устроен и работает протокол DHCP

вс, 07/14/2019 - 00:19

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

DHCP - это клиент-серверный протокол, использующий в качестве транспорта UDP, порт сервера - 67, порт клиента - 68. Так как для работы протокола используется широковещание (broadcast), то его действие ограничено текущей подсетью (широковещательным доменом). Для взаимодействия с клиентами расположенными в иных широковещательных доменах могут использоваться агенты ретрансляции (DHCP Relay), о них мы поговорим позже.

Основная задача протокола - получение клиентом IP-адреса, поля для иных сетевых настроек не предусмотрены, дополнительные сетевые параметры передаются протоколом DHCР в виде опций, например: опция 1 - маска сети, опция 3 - адрес маршрутизатора (основной шлюз), опция 6 - адреса серверов имен (DNS).

Получение адреса

Рассмотрим процесс получения IP-адреса, он достаточно прост и состоит из четырех этапов, которые в упрощенном виде показаны на следующей схеме:

Начинает этот процесс клиент, отправляя широковещательное сообщение Обнаружения DHCP (DHCP DISCOVER), в качестве обязательных полей передается номер транзакции - xid, MAC-адрес устройства - chaddr, также в опциях передается последний присвоенный клиенту IP-адрес, однако данная опция может быть проигнорирована сервером.

Все это можно увидеть, если заглянуть внутрь DHCP-пакета:

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

Обратим внимание на опцию 55 (Parameter Request List) - это список опции запрашиваемых клиентом. Именно так, опции всегда запрашиваются клиентом. С непониманием этого момента связаны ситуации, когда администратор добавил на сервере нужные ему опции, но клиенты их "почему-то" не получают. Ниже показан состав данной опции для Linux и Windows клиентов:

Можно увидеть, что Linux-клиент запрашивает опцию 42 - сервера времени (NTP), а Windows нет, поэтому даже если вы укажете ее на сервере, то Windows-клиенты не будут ее использовать. А что радует, так это что оба клиента запрашивают обе опции для получения маршрутов: предусмотренную стандартом 121 и введенную Microsoft 249.

Запрос обнаружения рассылается для всех узлов сети, но отвечают на него только DHCP-сервера, формируя сообщение Предложения DHCP (DHCP OFFER), которое содержит предлагаемую сервером сетевую конфигурацию. Если серверов несколько, то предложений клиент получит несколько. Из предложенных конфигураций клиент выбирает одну, как правило полученную первой. Предлагаемый клиенту адрес содержится в специальном поле yiaddr, а поле siaddr передается адрес DHCP-сервера.

Так как MAC-адрес отправителя известен, то сервер направляет ответ непосредственно клиенту (unicast), хотя в некоторых случаях может ответить и широковещательным пакетом. Например, DHCP-сервера dnsmasq и Mikrotik отвечает непосредственно клиенту (юникастом), в то время как DHCP Windows Server отвечает широковещательным пакетом. По большому счету это не имеет особого значения, просто вы должны знать, что это вполне допустимые режимы работы DHCP-сервера и не являются признаком неправильной работы.

В структуре ответа мы также отметили цветом вышеописанные опции, также обратите внимание, что в данном случае ответ был отправлен широковещательным пакетом (Windows Server). Ниже показана структура ответа dnsmasq:

Здесь видно, что сервер ответил непосредственно клиенту (отправив фрейм на его MAC-адрес), не прибегая к широковещательной рассылке.

Остальные сетевые параметры передаются в виде опций, в нашем случае это опции 1, 3 и 6 (маска, шлюз, DNS):

Приняв предложение клиент официально запрашивает у сервера данную конфигурацию, для чего отправляет широковещательно Запрос DHCP (DHCP REQUEST), он полностью повторяет по структуре сообщение обнаружения (Discover), только добавляет к нему опцию 54 с адресом сервера, конфигурацию которого клиент принял. Опция 50 содержит предложенный сервером IP-адрес. Несмотря на то, что MAC-адрес DHCP-сервера известен, запрос (Request) рассылается широковещательно, это нужно для того, чтобы остальные DHCP-сервера понимали, что их предложение отвергнуто.

Выше показана структура запроса, можете сравнить его с пакетом обнаружения, обратите внимание на заполненное значение опции 54.

Получив запрос сервер направляет клиенту в ответ Подтверждение DHCP (DHCP ACK), которое отправляется на MAC-адрес клиента (хотя может и широковещательно) и получив которое клиент должен настроить свой сетевой адаптер согласно указанного адреса и опций.

По структуре сообщение подтверждения (Ask) практически не отличается от предложения (Offer), за исключением того, что поле siaddr с адресом DHCP-сервера не заполняется, но его адрес передается в опции 54.

Получив адрес клиент может проверить его на предмет использования при помощи широковещательного ARP-запроса (в большинстве реализаций так и происходит) и если будет обнаружено, что выделенный адрес уже используется (скажем, назначен вручную), то клиент посылает широковещательное сообщение Отказа DHCP (DHCP DECLINE) и начинает процесс получения адреса заново. Сервер, получив сообщение отказа, должен пометить указанный адрес как недоступный и уведомить администратора о возможной проблеме в конфигурации (например, записью в логе).

Также клиент может самостоятельно отказаться от выданного адреса, отправив серверу сообщение Освобождения DHCP (DHCP RELEASE), в отличии от других сообщений, освобождение направляется юникастом серверу, выдавшему адрес. Получив такое сообщение сервер помечает адрес как доступный, но на всякий случай оставляет запись о клиенте, если он захочет получить адрес повторно. Это поведение не является обязательным, но реализовано в большинстве DHCP-серверов.

Обновление адреса

IP-адрес выдается клиенту на определенное время, называемое сроком аренды, его значение зависит от настроек сервера и может варьироваться в широких пределах, например, для DHCP-сервера Windows стандартный срок аренды - 8 дней.

В зависимости от срока прошедшего с момента получения адреса клиент может находится в одном из нескольких состояний.

Сразу после получения адреса клиент переходит в нормальное состояние (BOUND), при этом устанавливаются два момента времени T1 - равный половине времен аренды и T2 - равный 7/8 срока. По достижении времени T1 клиент переходит в состояние Обновления адреса (RENEWING), при котором он пытается обновить свой IP-адрес.

Для этого он отправляет сообщение запроса (Request), в котором указывает текущий IP-адрес. Если сервер подтверждает аренду, то отвечает сообщением подтверждения (Ask), клиент сбрасывает счетчики T1 и T2 и начинает отсчет срока аренды заново.

Обратите внимание, что на сообщение запроса ответит только тот сервер, у которого имеется запись для этого клиента, если такой записи нет - запрос будет проигнорирован.

Данные о сроке аренды и времени обновления адреса и обновлении конфигурации передаются сервером в опциях 51, 58 и 59:

Если сервер не ответил клиенту, то он берет промежуток времени до окончания состояния обновления и делит его пополам, в это время будет отправлен повторный запрос, при его отсутствии промежуток времени снова будет поделен пополам, потом снова пополам, при этом полученный промежуток времени не может быть меньше 60 сек. Таким образом, чем ближе окончание срока обновления, тем чаще будут делаться запросы.

После наступления момента времени T2, если клиенту не удалось обновить адрес, он переходит в состояние обновления Обновления конфигурации (REBINDING). В этом случае он посылает сообщение Обнаружения DHCP, теперь клиенту может ответить любой DHCP-сервер, а не только тот, который выдал IP-адрес. Если ответа от сервера не было, то оставшееся время также делится пополам и запрос повторяется. Все это время клиент может продолжать пользоваться уже полученной сетевой конфигурацией и нормально работать.

Если же до окончания срока аренды ответ так и не был получен, то клиент прекращает все сетевые операции и переходит в состояние Инициализации (INIT). В последствии, при получении предложений (Offer) от различных серверов клиент предпочтет выбрать предложение от сервера, который выдавал ему адрес прошлый раз и продолжит пользоваться старым адресом.

Также при обновлении могут быть иные сценарии развития событий. Скажем, клиент был включен в другую подсеть. В этом случае при получении запроса DHCP (клиент не знает, что он в другой подсети и пытается продлить аренду) сервер определяет неподходящий адрес в запросе и отвечает ему сообщением Отмены DHCP (DHCP NAK), после чего клиент должен начать процедуру получения адреса заново.

Если сеть клиента корректна, но запрашиваемый адрес занят, то сервер также ответит сообщением отмены (Nak) и клиент начнет получение адреса повторно.

Получение дополнительной информации

Если клиент имеет статически назначенный IP-адрес, но хочет получить дополнительные параметры, скажем адрес серверов имен или статические маршруты, то он отправляет специальное широковещательное сообщение Информации DHCP (DHCP INFORM), в ответ сервера отправляют сообщение подтверждения (Ask) без выделения IP-адреса.

Установка консольного клиента Яндекс.Диск на Debian / Ubuntu

пт, 07/12/2019 - 02:00

Яндекс.Диск - популярный отечественный облачный сервис для хранения и синхронизации пользовательских данных. Многие администраторы широко применяют его в своей повседневной деятельности для организации обмена файлами или хранения резервных копий. Чаще всего Яндекс.Диск используют на платформе Windows, для которой существует простое и удобное графическое приложение. Но далеко не все знают, что существует не менее удобный консольный клиент для ОС семейства Linux, о котором мы сегодня хотим вам рассказать.

Идея использовать Яндекс.Диск как дополнительное хранилище резервных копий является весьма интересной, потому как на клиентское приложение сервиса можно переложить достаточно большой пласт задач, связанный с размещением данных в облаке и контролем их целостности. Действительно, нам не нужно ни о чем заботиться, кроме как положить файлы в нужную папку локально, остальное клиент берет на себя.

Ценовая политика сервиса позволяет достаточно недорого получить пространство, достаточное для хранения данных небольших и средних организаций. Так годовую подписку на 100 ГБ можно сегодня приобрести за 990 руб, а на 1 ТБ за 2500 руб. Это недорого, собственная инфраструктура обойдется вам существенно дороже, 2500 руб - это цена одиночного жесткого диска на 1 ТБ, добавим к нему еще один диск (RAID 1), железо для NAS (или готовое устройство), канал связи, ИБП. Да и разместить это все надо надежно где-то за пределами офиса.

Перейдем от слов к делу. В нашем случае были использованы системы на Debian 9 и Ubuntu Server 16.04, но данная инструкция будет справедлива для любого основанного на них дистрибутива, в т.ч. настольного. Все описанные ниже действия следует выполнять с правами суперпользователя.

Прежде всего подключим репозиторий Яндекс.Диска:

echo "deb http://repo.yandex.ru/yandex-disk/deb/ stable main" >> /etc/apt/sources.list.d/yandex-disk.list

Скачаем и установим в систему его GPG-ключ:

wget http://repo.yandex.ru/yandex-disk/YANDEX-DISK-KEY.GPG -O- | apt-key add

Теперь обновим список пакетов и установим клиент Яндекс.Диска

apt update
apt install yandex-disk

Для первоначальной настройки следует воспользоваться мастером установки:

yandex-disk setup

Будет задано несколько простых вопросов, после чего клиент будет автоматически сконфигурирован и добавлен в автозапуск.

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

Сразу после запуска службы начнется синхронизация. Текущий статус можно выяснить командой:

yandex-disk status

Все вроде бы хорошо, но только синхронизируется в обе стороны у нас все содержимое диска, что нужно далеко не всегда, как минимум, сразу следует исключить стандартные папки Яндекс.Диска, если вы их используете. Для этого следует создать список исключений. Откроем конфигурационный файл сервиса, который находится в домашней папке по пути ~/.config/yandex-disk/config.cfg и добавим туда строку:

exclude-dirs="Загрузки,Музыка,Скриншоты"

Путь к папкам исключениям следует указывать относительно корневой папки Яндекс.Диска, которая указана в опции:

dir="/backup/yandex"

Т.е. если у вас существует директория /backup/yandex/mydir1/mydir2, то в исключениях следует указать mydir1/mydir2. директории перечисляются через запятую, без пробелов. После внесения изменений сервис необходимо перезапустить:

yandex-disk stop
yandex-disk start

Больше параметров можно узнать в официальной документации: https://yandex.ru/support/disk/cli-clients.html

Как видим, установить консольный клиент Яндекс.Диск совсем несложно, при этом по удобству использования он мало отличается от своего настольного собрата, позволяя полноценно использовать сервис даже в среде Linux-серверов.

Microsoft должна назвать обновления Windows 10 именами собак

чт, 07/11/2019 - 01:55

Представляем вашему вниманию перевод статьи, которая хоть и не является технической, но на наш взгляд должна быть интересна широкому кругу читателей, так как затрагивает достаточно серьезные вопросы. Действительно, должны ли быть имена обновлений ОС запоминающимися? Особенно в наше время, когда новые релизы выходят каждые полгода. Следует ли идти навстречу пользователям или надеяться на доминирующее положение? Эти вопросы пока остаются без ответов, но все-таки собаки - идея интересная.

Уважаемая компания Мicrosoft, ваши имена для обновлений Windows 10 не запоминаются, и пользователи не могут их отслеживать. А вы знаете, что будет отлично запоминаться? Собаки.

Кстати, Windows 10 - это здорово, нам нравится получать новые функции примерно каждые полгода. Но имена этих обновлений ужасны, вы посмотрите на этот список:

  • Ноябрьское обновление
  • Юбилейное обновление
  • Обновление для дизайнеров
  • Осеннее обновление для дизайнеров
  • Апрельское обновление 2018
  • Октябрьское обновление 2018
  • Майское обновление 2019

У меня установлен какой-то из них, но я не могу вспомнить какой. В этом и проблема. Данные имена настолько безлики, что полностью бесполезны. А когда я читаю, что "Ноябрьское обновление" больше не будет поддерживаться, я вообще не понимаю, о чем идет речь, может это обновление было выпущено в прошлом ноябре, хотя речь идет о выпуске 2015 года. Ну а если бы я жил в Австралии, то вышедшее весной "Осеннее обновление для дизайнеров" привело бы меня в недоумение.

Но это можно легко исправить. Дайте своим обновлениям запоминающиеся имена. Имена с личностью, которые будут привлекательны.

Microsoft - это собаки

Вы думаете мы шутим? Нет, Apple и Canonical использовали имена животных с положительным эффектом, я до сих пор помню "Precise Pangolin" и "Snow Leopard" (а Linux Mint использует имена девушек, что тоже запоминается. Прим. переводчика). Если у вас будут частые обновления, то пользователям нужно как-то их отслеживать, нужны запоминающиеся имена. Животные запоминаются.

Почему именно собаки? Во-первых - собаки классные! Во-вторых - есть сотни пород, вам хватит надолго. Ну и наконец, собаки дают безграничные возможности, например, посмотрите ниже:

Я бы не раздумывая загрузил это обновление, даже если бы оно удалило мне Paint и Notepad. Вы только представьте какую силу могут иметь эти собаки.

Я догадываюсь о чем вы думаете: "Если мы назовем релизы в честь собак, то как пользователи догадаются на какой возможности мы решили сосредоточиться? Ведь именно поэтому мы назвали один из наших выпусков "Обновлением для дизайнеров". Но не волнуйтесь. Собаки принимают вызов, собаки могут всё!

Выпуск, посвященный безопасности? Держите:

Кроме безопасности добавлено много интересных функций? Возьмем игривую породу с жесткой репутацией:

Новое обновление содержит назойливые уведомления, не дающие покоя ни днем, ни ночью? Собаки снова помогут:

Или вы уверены, что данное обновление понравится всем?

Но если вы твердо намерены придерживаться сезонов в наименовании выпусков, то и здесь собаки придут на помощь:

Хотя мы не советуем...

Мы могли бы продолжать бесконечно, мир полон хороших собак.

Мы ничего не хотим взамен этой идеи, нам хочется, чтобы имена выпусков Windows 10 были отличимые друг от друга. Возможно, это глупая идея, но не глупее чем текущая схема именования.

Источник: Microsoft Should Name Windows 10 Updates After Dogs

Автор: Justin Pot

Перевод: Уваров А.С., ООО "Интерфейс", г. Белгород

Проброс портов и Hairpin NAT в роутерах Mikrotik

вт, 07/09/2019 - 02:49

Проброс портов - на первый взгляд тривиальная повседневная задача, которая не должна вызывать никаких затруднений. Действительно, в бытовых роутерах это так, но если речь идет об оборудовании Mikrotik, то сложности могут не заставить себя ждать. А все потому, что RouterOS дает в руки администратора богатые сетевые возможности, требуя в ответ понимания работы сетей хотя бы на базовом уровне. Конечно, можно настроить все по готовой инструкции, но гораздо лучше понимать каждое свое действие, и именно для тех, кто хочет разобраться предназначена эта статья.

Проброс портов

Проброс, он же форвардинг, портов - что это такое? Это технология, которая позволяет обращаться к узлам, находящимся за маршрутизатором путем перенаправления трафика для определенных портов с внешнего адреса маршрутизатора на внутренний адрес узла в локальной сети. Это становится возможным благодаря технологии NAT.

Давайте рассмотрим небольшую схему, которая поможет понять принцип действия проброса портов.

Допустим, некий удаленный ПК хочет обратиться к нашему веб-серверу, который находится за маршрутизатором в локальной сети. Но обратиться он может только по внешнему адресу маршрутизатора (в нашем примере 192.168.3.113), на который мы пробросили порт 80 веб-сервера. Поэтому он формирует пакет, в котором адресом назначения выступает маршрутизатор и отправляет его получателю, в качестве адреса источника он указывает собственный адрес.

Маршрутизатор, получив такой пакет выполняет замену адреса назначения с собственного, на адрес веб-сервера, также, при необходимости, он может изменить и порт назначения. После чего пакет отправляется в локальную сеть и достигает веб-сервера. Данные о преобразовании заносятся в специальную таблицу трансляции NAT.

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

Маршрутизатор на основании данных таблицы трансляции выполнит обратное преобразование, заменив на этот раз адрес источника с внутреннего адреса веб-сервера, на свой внешний адрес и отправит пакет запросившему его узлу.

На первый взгляд все понятно, поэтому перейдем к практике. В RouterOS в качестве сетевого фильтра используется iptables, поэтому далее мы будем оперировать его терминами. В таблице NAT используются две цепочки: PREROUTING - в которую попадают все пришедшие на маршрутизатор пакеты и POSTROUTING - через нее проходят все прошедшие через устройство пакеты. В PREROUTING нам доступно действие dst-nat (DNAT), которое позволяет изменить адрес назначения пакета, в POSTROUTING будут доступны src-nat (SNAT) и masquerade, которые позволяют изменить адрес источника пакета.

Мы не даром заостряем на этом особое внимание, так как непонимание процесса прохождения пакета по цепочкам сетевого фильтра способно привести к значительным затруднениям, когда вроде-бы все правила составлены верно, но ничего не работает.

Так для пакета от клиента к веб-серверу и обратно порядок прохождения цепочек будет следующим:

PREROUTING -> FORWARD -> POSTROUTING

Обратите внимание, что пакет не попадает в цепочки INPUT и OUTPUT, которые используются для собственных пакетов маршрутизатора.

Как правильно выполнить настройку? Перейдем в IP - Firewall - NAT и добавим следующее правило: Chain - dstnat (читай PREROUTING), Dst. Address - 192.168.1.113 - внешний IP-адрес нашего роутера, Protocol - tcp - используемый протокол, если сервис может использовать несколько протоколов, скажем TCP и UDP - потребуется создать отдельное правило для каждого протокола, Dst. Port - 80 - порт, на котором маршрутизатор будет принимать внешние соединения.

На закладке Action укажите: Action - dst-nat - выполняем замену адреса получателя, To Addresses - 192.168.186.195 - внутренний адрес веб-сервера, To Ports - 80 - порт, на котором веб-сервер принимает соединения. Если внешний и внутренний порт совпадают, то последний можно не указывать.

Либо выполните в терминале:

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=192.168.3.113 dst-port=80 protocol=tcp to-addresses=192.168.186.195 to-ports=80

Но это еще не все, после PREROUTING пакет попадет в цепочку FORWARD, в которой, если вы настраивали роутер по нашей инструкции, запрещены любые внешние пакеты, кроме инициированных из локальной сети соединений.

Создадим новое правило. IP - Firewall - Filter Rules, где добавим: Chain - forward - цепочка FORWARD, Protocol - tcp, Dst. Port - 80 - протокол и порт, In. Interface - ether5 - внешний интерфейс вашего роутера. Так как по умолчанию в новых правилах стоит действие accept, на закладку Action можно не переходить.

Располагаться данное правило должно выше правила, запрещающего транзитный трафик из внешней сети во внутреннюю.

Обратите внимание, что если вы пробрасываете порт с изменением номера, скажем внутренний 3389 (RDP) на внешний 3390, то в правиле брандмауэра вы всегда должны указывать внутренний порт, т.е. 3389, так как пакет уже прошел цепочку PREROUTING и данные о получателе в нем уже изменены на адрес и порт внутреннего сервера.

Из терминала это можно сделать командами:

/ip firewall filter
add action=accept chain=forward dst-port=80 in-interface=ether5 protocol=tcp

Осталось только проверить работу наших правил, попробуем получить доступ к веб-серверу со внешнего узла:

Как видим, все прекрасно работает.

Hairpin NAT

Все это хорошо, но ровно до тех пор, пока мы не попытаемся получить доступ по внешнему адресу из внутренней сети. Вообще, таких ситуаций следует избегать, предпочтительно использовать для доступа доменные имена и двойной горизонт DNS, когда для внешних пользователей одно и тоже имя разрешается во внешний адрес, а для внутренних - во внутренний. Но это возможно не всегда. Попробовав же обратиться изнутри по внешнему адресу, мы получим ошибку соединения:

Почему так происходит? Давайте рассмотрим еще одну схему:

Первая ее часть нам уже знакома, узел отправляет запрос на внешний адрес маршрутизатора, он заменяет адрес назначения адресом внутреннего сервера и отправляет пакет к нему, адрес отправителя остается неизменным. А вот дальше начинается самое интересное, веб-сервер видит, что отправитель находится в ним в одной сети и отправляет ответ ему напрямую. Но отправитель направлял запрос на внешний адрес сервера и ждет ответа именно от него, поэтому ответный пакет, отправителем которого указан внутренний адрес веб-сервера будет отброшен и связь установить не удастся.

Что же делать? Очевидно, что нужно каким-то образом заставить веб-сервер отвечать не напрямую клиенту, а пересылать пакет обратно маршрутизатору. Здесь нам на помощь придет действие src-nat (SNAT), которое позволяет изменить адрес отправителя, находящееся в цепочке POSTROUTING. В терминах Mikrotik данная настройка носит наименование Hairpin NAT.

Чтобы понять, как это работает мы подготовили следующую схему:

Теперь наш маршрутизатор не только изменяет адрес назначения, но и адрес источника, указывая в его качестве собственный внутренний IP. Обработав такой пакет веб-сервер отправит его обратно к маршрутизатору, который выполнит обратные преобразования (согласно таблице трансляции) и оправит его получателю. А так как отвечать будет именно тот узел, к которому был отправлен запрос, то в данном случае все будет работать.

Для настройки на Mikotik перейдем в IP - Firewall - NAT и добавим: Chain - src-nat (POSTROUTING), Src. Address - 192.168.186.0/24 - диапазон вашей локальной сети, Dst. Address - 192.168.186.195 - внутренний адрес веб-сервера, Protocol - tcp, Dst. Port - 80 - протокол и порт.

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

Затем переходим на закладку Action и указываем: Action - src-nat (SNAT), To Addresses - 192.168.186.1 - указываем внутренний адрес нашего маршрутизатора. Если вы используете на внешнем интерфейсе другой порт, то обязательно укажите его в поле To Ports, если порты совпадают, то делать это необязательно.

Через терминал данное правило можно создать следующим образом:

/ip firewall nat
add action=src-nat chain=srcnat dst-address=192.168.186.195 dst-port=80 protocol=tcp src-address=192.168.186.0/24 to-addresses=192.168.186.1

Во многих иных статьях для данного правила используется действие masquerade, давайте разберемся в чем разница. В первом приближении оба действия делают одно и тоже - изменяют адрес источника пакета, но src-nat работает только со статическими адресами, зато позволяет указать в качестве источника любой адрес, masquerade работает с динамическими адресами, но в качестве адреса источника может использовать только адрес того интерфейса, с которого уходит пакет. За счет того, что masquerade при каждом запросе определяет адрес интерфейса - это действие требует больше вычислительных ресурсов, нежели src-nat.

В нашем случае все адреса статические, поэтому использование src-nat здесь будет более уместно.

Правило создано, проверим его работу:

Если вы нигде не допустили ошибок - все будет работать, как и предполагалось.

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

UNIX в кедах или звериный оскал десктопного BSD

сб, 07/06/2019 - 23:07

Не столь давно один из коллег упрекнул нас, что мы совсем не уделяем внимания системам на основе BSD, в том числе их настольному применению, указывая на перспективность использования именно BSD, а не Linux, как основы российских ОС. В качестве аргументов было использование BSD в таких системах как MacOS и Orbis OS (PlayStation 4). А так как c BSD мы не работали давно и конструктивно возразить не могли, то решили по мере появления свободного времени самостоятельно оценить положение дел в этом семействе и пригодность BSD-систем к работе на десктопе.

Когда-то давно, когда Linux был еще "молодой и перспективной" системой, FreeBSD была в своем роде "старшей сестрой", представляя на тот момент, несомненно, более зрелое и законченное решение. Она широко использовалась на серверах и в коммерческих разработках, а BSD-админы поглядывали на своих Linux-коллег свысока.

Сейчас BSD больше проходит по разряду экзотики или используется в специализированных и нишевых решениях, практически полностью уступив свои позиции Linux. Что же произошло? Здесь уместно процитировать В.И. Ленина: "Страшно далеки они от народа", это про разработчиков. В свое время они сами сравнивали BSD с "величественным собором", который возводит небольшая группа архитекторов, в то время как Linux, по их словам, представлял некий "караван-сарай" с "базарным" стилем разработки.

Действительно, созданием BSD занималась узкая группа специалистов из университета Беркли, в то время как принять участие в разработке Linux мог любой. Еще одну злую шутку сыграла лицензия, которая позволяла просто брать и закрывать код, ничего не возвращая сообществу. В итоге в Беркли проспали приход многоядерности и многопоточности, виртуализацию и еще множество современных технологий. Что-то удалось наверстать, но с той же виртуализацией дела до сих пор обстоят очень и очень плохо.

Что касается применения BSD в коммерческих разработках, то в той же MacOS от BSD используется очень немного, а то что есть - скрыто глубоко под капотом, во всяком случае к настольной части этой системы BSD имеет опосредованное отношение. Использование BSD-кода в JunOS (сетевое оборудование Juniper), ONTAP (ОС для систем хранения NetApp) и той же PlayStation 4 обусловлено прежде всего лицензией и сложно сказать сколько там BSD, а сколько собственных разработок, все эти системы закрытые и имеют специализированное назначение.

Из открытых систем определенную популярность имеют pfSense (специализированный дистрибутив для шлюзов) и FreeNAS (ОС для сетевого хранилища), в остальном же перспективы BSD достаточно туманны.

FreeBSD 12

Начинать, так с первоисточника. Скажем честно, мы не касались FreeBSD уже много лет, поэтому было даже интересно, что изменилось с тех пор и в какую сторону. Мы скачали актуальную на текущий момент версию 12 и приступили к установке.

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

Дальше нас встречает установщик, который не менялся уже очень и очень много лет, по сравнению с ним текстовые инсталляторы Linux кажутся верхом совершенства и значительно превосходят его по удобству. Скажем больше, если вы никогда не устанавливали FreeBSD, то вряд ли вам удастся сделать это с первого раза, логика здесь своя, местами доступная только "посвященным".

И что нам тут выбрать? Да пес его знает... Оставим по умолчанию... Вот оно, суровое очарование настоящего Unix. В Linux этот этап давно прошли, сделав процесс выбора состава дистрибутива более понятным и прозрачным.

Что действительно радует - так это возможность автоматической разметки диска, потому как это был еще один квест для начинающих с весьма сомнительным результатом.

Процесс пошел, можем пока сходить за кофе или чем покрепче, потому как все это не для слабых духом.

Для ввода пароля root или создания нового пользователя нас выбрасывает в чистую консоль. Такая вот дружелюбность в 2019 году.

Это всё? Или будет продолжение? Нет, не будет, если нужно что-то настроить, то лучше сделать это сейчас, самому, руками. Потому что потом все тоже самое придется делать также руками, но уже в консоли незнакомой системы.

Про графическую оболочку нас нигде и близко не спросили, ладно, установим вручную. Но если в Linux вполне достаточно просто установить нужный набор пакетов и перезагрузиться, то здесь вам еще понадобиться внести ручные правки в файлы конфигурации.

В качестве редактора по умолчанию установлен vi, что добавляет происходящему "прелести". В общем чужих здесь не ждут, и чтобы дойти до конца нужно иметь достаточно сильную мотивацию, одного любопытства будет явно недостаточно.

Наконец все трудности позади и нас встречает графическая оболочка. Выглядит на первый взгляд неплохо, но это заслуга не BSD, а разработчиков Gnome. Набор софта - минимален, оно и понятно, никаких настольных метапакетов здесь нет, просили Gnome 3 с базовым набором утилит - получите и распишитесь.

Настроить систему? Ну попробуйте, только снять снапшот не забудьте, потому как повторить второй раз процесс установки решится не каждый. И пусть вас не обманывает более-менее современный вид системы, в реальности вы получите весь набор "детских болезней" настольного Linux 10-15 летней давности. Полноценной русификации нет, точнее есть, но только через консоль и старательную правку конфигурационных файлов.

Какого-либо подобия графической оболочки пакетного менеджера нет. Хорошо если вы знаете имя пакета, который вам нужен, найти по описанию или просто просмотреть список пакетов, скажем для работы с видео, здесь не получится. С поддержкой виртуализации тоже все туго. Если любой современный Linux в среде VMWare или VirtualBoх чувствует себя отлично, позволяя использовать средства интеграции, аппаратное ускорение графики и прочие радости жизни, то здесь всего этого нет. Увидел все виртуальное железо - и хорошо. Автоматически подогнать экран под размер виртуалки? Нет, не слышали...

Ой, сорри, ну забыли предупредить, что для того, чтобы пользователь мог повысить себе права нужно было руками добавить его в одну группу. Ладно, перезагрузимся в однопользовательский режим и выполним пару команд, делов то...

А чудеса просто лезут из всех щелей. Хотите правильно установить часовой пояс? Ну попробуйте. А что, хотели MSK (UTC +03) - держите, правда почему-то Москва оказалась в Лондоне, на долготе Гринвичского меридиана. Что? Вы хотите все-таки видеть правильное время? Ну поправьте пару строк в конфиге, ну что вы как маленький...

Хотя если есть стимул, то трудностями не испугать. Должна же система в чем-то раскрыться и показать свои сильные стороны. Может быть в софте? Да нет, с софтом для BSD сейчас туго, спасает в основном только GNU и некоторые проекты из мира Linux, которые можно пересобрать под BSD, не притаскивая попутно половину Linux в нагрузку. Поэтому базовый набор привычного ПО у вас будет, а вот шаг вправо, шаг влево...

Говорите нравится браузер Опера? Придется как-нибудь без нее, возьмите Firefox или Chromium, все равно ничего другого не завезли. Хотите поработать с 1С? Как бы это помягче. Нет, можно установить пакет linux-base для бинарной совместимости с Linux и жить станет полегче, но зачем, если есть Linux, где есть все тоже самое, но без всех этих тягот и лишений.

Ладно, не все же нам работать, надо и отдыхать, посмотрим, как обстоят дела с мультимедиа.

Здесь мы опасливо покосились на календарь, да нет, все верно, на дворе 2019 год, когда любая современная ОС проигрывает все распространенные форматы просто из коробки. Проблему исправил установленный VLC, но сам факт такой вот "поддержки" мультимедиа снова отослал нас лет на десять назад, когда подобные проблемы были нормой для Linux.

Позвольте, скажет иной читатель, но ведь FreeBSD и не позиционирует себя на десктоп. Ну как сказать...

Про "современную" и "для десктопов", заметьте, не мы написали. Но выводы будем делать немного позже, а пока двинемся дальше.

TrueOS 18.03 (бывшая PC-PSD)

PC-BSD достаточно старый и амбициозный проект по созданию дружелюбного пользовательского BSD-дистрибутива и мы когда-то давно, примерно десять лет назад, делали на него обзор. Но даже тогда система выглядела не лучшим образом на фоне современного ему Linux, хотя настольный Linux десять лет назад страдал множеством "детских болезней" и сильно отличался от современных дистрибутивов. Но если Linux сумел пройти этот путь, то должен же был куда-то дойти и BSD?

В процессе этого пути разработчики видимо решили, что как лодку назовете - так она и поплывет, и сменили название системы на довольно амбициозное и пафосное TrueOS. Также дистрибутив обзавелся собственным легковесным окружением Lumina.

В прошлом году в жизни проекта произошли очередные изменения и TrueOS отказалась от поддержки десктопной версии, превратившись в нисходящий (downstream) форк FreeBSD c поддержкой технологий OpenRC (система инициализации родом из Gentoo) и LibreSSL. Настольное направление перешло в отдельный проект Trident, к которому мы вернемся позже, а пока поглядим к чему пришел проект PC-BSD / TrueOS к моменту кардинального переосмысления собственной деятельности.

Последняя настольная версия TrueOS - 18.03, т.е. чуть менее чем годовалой давности, как и основная LTS версия Ubuntu, поэтому... Мы хотели написать, что можно смело сравнить с актуальными версиями основных дистрибутивов, но не будем этого делать. Почему - поймете чуть позже.

Традиционная псевдографика, это классика и визитная карточка BSD-систем.

А вот и инсталлятор, выглядит пока неплохо, да, есть к чему придраться в плане визуального оформления, но это не главное, задача инсталлятора - провести нас через все этапы установки с минимальными затруднениями. Со своей задачей он справляется.

По умолчанию используется ZFS и автоматическая разметка диска, уже неплохо.

В остальном все ожидаемо и скучно. Запутаться в процессе решительно негде и есть надежда, что в этот раз BSD повернется к пользователю все-таки лицом.

Но уже на этапе входа в систему нас начали терзать смутные сомнения. Современные шрифты и сглаживание? Аккуратная графика? То, что предстало нашему взору более похоже на самодеятельность уровня сельского клуба, а не ОС с 12-летней историей.

Это что? Где все элементы управления? Минимализм, конечно, сегодня в моде, но не до такой же степени.

Да нет, все гораздо проще, ну не умеет система 2018 года автоматически определять размер экрана и масштабироваться, тем более в виртуальной среде (это же надо додуматься, в 2018 и на виртуалку).

Это, если кто-то не понял, собственная среда окружения рабочего стола - Lumina. Блеск и нищета BSD в одном флаконе. Если вернуться на 10 лет назад, то можно сделать выводы, что версия PC-BSD с KDE выглядела гораздо лучше и сразу возникает вопрос, а зачем надо было городить весь этот огород, можно ведь было взять уже готовое окружение, не обязательно тяжелые KDE или Gnome, наоборот, можно что-то легковесное.

Но не все так просто. Современные оболочки разрабатываются сугубо для Linux, что вызывает сложности при портировании из-за зависимостей от таких специфичных Linux-компонент как D-Bus, systemd, hald и прочих. Поэтому разработчики решили делать полностью свою, BSD-оболочку. Что получилось - вы уже видели.

Те десять лет (с момента прошлого обзора PC-BSD), которые Linux шел к пользователю, обрастая по пути современными технологиями, разработчики PC-BSD шли куда-то не туда, да и скорее не шли, а блуждали где-то в трех соснах. На наш взгляд проще было сделать форк уже готовой рабочей среды (Mate, LXDE и т.п.), адаптировать ее к BSD и продолжить развивать, опираясь на прочный фундамент, нежели пытаться сделать что-то свое, явно не имея для этого сил и средств.

Отложим в сторону графическую составляющую и посмотрим на предлагаемый в составе оболочки файловый менеджер, он просто убог и неудобен, но зачем-то к нему прикручен Git. И мы снова ловим себя на мысли, что высказывание Владимира Ильича тут как никогда к месту.

Видимо разработчики TrueOS трезво оценили перспективы своего детища и переключили свои силы на более перспективные направления, занявшись портированием в BSD Linux-технологий и нам трудно винить их за это.

Дальнейшему знакомству с системой нам помешало полное отсутствие доступа к репозиториям, вместе с отказом от десктопной ОС разработчики полностью отказались и от ее поддержки, дистрибутивы настольной системы также недоступны на сайте, единственная возможность получить их сейчас - это торренты.

Trident 19.06

Но дело PC-BSD живет, превратившись ныне в проект Trident, название выбрано тоже достаточно символичное, так как именно трезубцем был вооружен даймон - маскот FreeBSD. Может быть в новом проекте что-то сдвинется с мертвой точки? Посмотрим.

Псевдографика, как всегда, хороша, пожалуй, это единственное к чему не придраться.

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

Разработчики постарались наполнить дистрибутив современными программами и обеспечить хорошую совместимость. Здесь и популярный Телеграмм, и VLC, и поддержка NTFS, также заявлена поддержка гостевых расширений для виртуальных машин.

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

В графическом плане мало что изменилось, те же самые ужасные шрифты и неаккуратная графика.

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

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

Панель управления столь же бедна возможностями, насколько лаконична внешне.

Системный монитор крайне прост и убог, сравнивать с Linux или Windows аналогами просто не хочется.

С графикой в системе просто беда, LibreOffice выглядит так, как будто мы перенеслись к конец 90-х и запущен он в среде Windows 98/2000. Плохо просто все и если на небольших мониторах той поры это еще выглядело приемлемо, то в современных условиях, на HD-разрешениях с высокой плотностью пикселей все графические огрехи, ужасные шрифты и отсутствие сглаживания просто режут глаз. Кто сможет работать каждый день в таких условиях нам непонятно.

Если снова вернуться на десять лет назад и сравнить тот Linux с современным - мы увидим огромный качественный рывок, как в плане технологий, так и в простоте использования. Здесь время словно остановилось, но десять лет назад PC-BSD был вполне современной системой, хоть и уступал конкурентам, сегодня же Trident выглядит откровенно беспомощно.

GhostBSD 19.04

Еще одна настольная система на базе BSD и, пожалуй, самая современная из них, во всяком случае наиболее дружелюбная и проработанная.

Как всегда - псевдографика, все-таки что-то такое в ней есть.

Установка начинается с текстового режима, в котором предлагается выбрать используемый видеодрайвер, выбор довольно велик, но в нашем случае неплохо справилась и автоматическая конфигурация.

Затем система загружается в режиме Live-CD, что дает возможность проверить работу на собственном железе без установки и, убедившись, что все будет нормально, продолжить установку в графическом режиме. В качестве рабочего окружения используется Mate и выглядит все действительно неплохо. На этом этапе каких-либо претензий нет, все сделано действительно неплохо.

А это что такое?! Забыли добавить графическую оболочку в автозагрузку? Бывалые линуксоиды, конечно, знают заветное слово, оно даже автоматически подсвечивается если набрать первую букву, но возникает закономерный вопрос - дистрибутив кто-нибудь тестировал? А если тестировал, то, наверное, "не заметил" или решил, что такая "мелочь" не стоит внимания? Для современной системы подобный баг - это весьма серьезный недочет.

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

Разработчики не стали изобретать велосипед и просто хорошо настроили популярное рабочее окружение, так что, бросив беглый взгляд не сразу и поймешь, что это BSD-система. У нас не возникло проблем ни с документами, ни с мультимедийными файлами и мы даже хотели написать, что все просто замечательно, но тем временем система скачала и установила обновления.

Досадный баг с загрузкой графической оболочки исправили, зато полностью слетела локализация. Настроек в панели управления ожидаемо немного и локализации среди них не числится, хотя если быть честными, то большинство из них относится к рабочей среде Mate, а не самой BSD-системе. Т.е. для чего-то более сложного, чем смена обоев придется все-таки открывать терминал.

А вот центр приложений огорчил, он как будто вынырнул из пучин пятнадцатилетней давности. Описания пакетов нет и вам повезло, если вы точно знаете, что вам нужно. Фактически мы снова (как и во FreeBSD) сталкиваемся с ситуацией, когда что-то выходит за рамки графической оболочки и затрагивает собственные функции BSD, то выглядит это весьма печально, особенно если учесть, что все популярные оболочки заимствуются из Linux.

Хотя в общем GhostBSD весьма неплох, с поправкой на все особенности BSD, конечно. Поэтому если вы все-таки хотите немного приобщиться к настоящему UNIX - то начните с него. Но в целом ничего нового вы не получите, скорее, наоборот, приобретете полный ворох "детских проблем" свойственных Linux десятилетней давности. Кстати, если вы испытываете ностальгию по тем "далеким и светлым" временам, то данный дистрибутив поможет вам переместиться в прошлое без всякой машины времени.

Выводы

А выводы у нас будут печальные, FreeBSD в свое время проиграла гонку с Linux и находится сейчас в позиции догоняющего. У нее нет каких-либо отличительных черт или технологий, которые давали бы конкурентное преимущество, наоборот, сейчас в BSD идет активный импорт Linux-решений (тот же OpenRC). Единственная интересная фишка - ZFS, но и это не родная для BSD технология, а наследство от Sun Solaris, а так как обе системы - это настоящий UNIX, то особых проблем с портированием не возникло. Но сегодня ZFS есть и в Linux, поэтому перспективы и сферы применения BSD выглядят весьма неопределенно. Хотя есть отдельные ниши, где BSD по-прежнему неплоха.

Во всем, что касается настольного применения система отстала лет на десять-пятнадцать. Начиная с того, что нет собственного рабочего окружения (Lumina не в счет), которое бы использовало родные механизмы системы, а не требовало бы импорта Linux-подсистем и заканчивая многочисленными "детскими болезнями", которые в других ОС давно решены.

Можно ли использовать BSD как основу для разработки собственных систем? Наверное можно, но не нужно, потому что вам придется потратить много сил и средств на то, что в Linux уже давно сделано, разве что только вы являетесь искренним фанатом BSD и вопрос рационального расходования ресурсов перед вами не стоит.

Единственный вариант, когда применение BSD оправдано - если вы хотите впоследствии закрыть код, но в современном мире платить за ОС скоро станет столь же непривычно, как платить за браузер. Последние годы все шире распространяется модель SaaS (ПО как услуга) с подписками и микроплатежами. Закрытая ОС в данном контексте просто теряет свой смысл. Что касается специфичных систем для государственного применения, в т.ч. в силовых структурах, то там GPL нисколько не мешает ни коммерческому подходу, ни закрытию доступа к определенным компонентам, включая их исходный код.

Ну и наконец "успешные" применения BSD, скажем в составе PlayStation 4, это лишь исключение, подтверждающее правило. Игровая приставка, как и техника Apple, это четко определенный набор железа в аппаратной части, не предусматривающий серьезную вариативность, поэтому всегда можно скомпилировать систему под целевое железо и получить серьезный прирост производительности, при том, что там будет под капотом, Linux или BSD, в данном контексте неважно. Все равно поверх ядра ОС будет развернута собственная оболочка, которая имеет с родительской системой очень мало общего.

А выбор BSD в данном случае более интересен по лицензионным соображениям, так как позволяет просто продавать закрытую систему и не думать о ее лицензионной чистоте. Но это и есть нишевое применение, ничем не отличающееся от того-же pfSense, где поверх BSD развернута собственная веб-оболочка, разве что код открыт, что для конечного пользователя практически не имеет никакого значения.

Настраиваем VPN. Часть 2 - Cтруктура сети

пн, 07/01/2019 - 01:09

Продолжая разговор о виртуальных частных сетях (VPN) следует обязательно коснуться вопроса структуры создаваемой сети, которая в свою очередь зависит от выполняемых задач. Неверные решения на стадии проектирования могут сказаться далеко не сразу, а по мере роста и развития инфраструктуры, когда поменять что-либо "малой кровью" будет очень проблематично. В статье мы рассмотрим типовые сценарии использования VPN, области их применения, достоинства и недостатки.

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

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

Для оставшегося большинства задач следует использовать L3 VPN, работающий на сетевом уровне и использующий маршрутизацию, которая позволяет эффективно управлять потоками трафика и строить достаточно сложные сетевые решения. В данной статье мы не будем подробно разбирать вопросы маршрутизации, для знакомства с ее основами рекомендуем обратиться к другой нашей статье.

Соединение хост-хост (Сквозной VPN, End-to-End)

Самая простая схема, при которой туннель непосредственно соединяет два узла. В данном случае VPN-сервер не является маршрутизатором и клиент не имеет доступа за его пределы. В данной схеме не используется маршрутизация и нет требований к локальным адресам клиента и сервера.

Данное решение используется в первую очередь для создания защищенного канала связи для удаленной работы с сервисами, имеющими недостаточный уровень безопасности. Например, для организации удаленного доступа бухгалтера к базам 1С:Предприятия, либо для доступа к административной панели расположенного в сети интернет сервера.

Также подобное решение часто используют для защиты недостаточно защищенных протоколов, скажем FTP или POP3, если вариант с SSL по какой-либо причине (чаще всего обратной совместимости) недоступен.

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

Соединение хост - сеть (Удаленный доступ, End-to-Site)

В случаях, когда удаленному сотруднику требуется полный доступ к сети предприятия используют несколько иную схему. В этом случае VPN-сервер должен являться маршрутизатором, а адресное пространство клиента и локальной сети не должно пересекаться. Именно поэтому мы категорически не рекомендуем использовать в локальных сетях подсети 192.168.0.0 и 192.168.1.0, которые широко используются в сетевом оборудовании уровня SOHO (для дома и малого офиса), так как в этом случае вы с очень большой долей вероятности столкнетесь с пересечением адресного пространства.

Для того, чтобы удаленный компьютер имел доступ к локальной сети нам потребуется использовать маршрутизацию. Для этого на клиенте потребуется создать маршрут, который укажет, что все пакеты для сети 192.168.51.0 следует направлять через туннель на адрес VPN-сервера 10.10.0.1. Никаких обратных маршрутов со стороны локальной сети указывать не нужно.

Как и в предыдущем сценарии следует понимать, что подобное соединение дает доступ внутрь периметра и требует доверия к удаленному пользователю. В ряде случаев, когда уровень доверия низок, имеет смысл изолировать удаленных пользователей в DMZ-зоне и контролируя с помощью брандмауэра их доступ к остальной части сети.

Еще один сценарий использования подобного соединения - административный, используемый системным администратором для доступа к собственной сети из любой точки земного шара.

Соединение сеть-сеть (Site-to-Site)

Наиболее популярная в корпоративной среде схема, позволяющая соединить сети офисов между собой. В этом случае туннель обычно поднимается между маршрутизаторами сетей, хотя это не обязательно, но при расположении VPN-сервера и клиента на отдельных узлах сети потребуется дополнительная маршрутизация.

В нашем примере узлы VPN-сети совпадают с основными шлюзами и на каждом их них потребуется добавить дополнительный маршрут, который будет направлять пакеты к удаленной сети на другую сторону туннеля.

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

Как видно из следующей схемы, два филиала с сетями 192.168.41.0/24 и 192.168.31.0/24 могут общаться между собой исключительно через сервер центрального офиса. Все пакеты для иных сетей филиалы направляют на VPN-адрес офиса - 10.10.0.1, потому как если указать для 41-й сети путь к 31-й через 10.10.0.2, то такой маршрут работать не будет.

Почему? Потому что туннель - это точка-точка, в данном случае у нас есть соединения 10.10.0.2-10.10.0.1 и 10.10.0.3-10.10.0.1, но соединения 10.10.0.2 - 10.10.0.3 нет и быть не может. Понимание данного факта заставляет по-новому взглянуть на потоки трафика между удаленными сетями и предполагает построение оптимальной топологии с учетом этого факта.

Допустим сети 31 и 41 территориально расположены в одном городе и предполагают большой объем трафика между ними (скажем филиал и производственная площадка). В этом случае нет никакой необходимости гонять трафик через центральный офис и более правильно будет настроить два VPN-канала: между 31-й и 51-й сетями (филиал - офис) и 31-й и 41-й (филиал - производство), а благодаря маршрутизации мы можем также без проблем настроить соединение офис - производство через филиал.

Доступ в интернет

Если быть формалистами, то данный сценарий к виртуальной частной сети (VPN) не относится, но использование VPN-соединений для доступа в интернет становится все более и более популярным, поэтому рассмотрим и этот сценарий.

В каких случаях использование VPN для доступа в интернет оправдано? В первую очередь низкий уровень доверия к текущей сети. Скажем вы находитесь в командировке и вынуждены использовать гостиничный Wi-Fi, вы не знаете, что это за сеть и какой у нее уровень безопасности, поэтому для работы будет вполне оправданно поднять VPN-соединение с корпоративным шлюзом и уже через него выходить в глобальную сеть.

Другой сценарий - это доступ к сайтам, которые недоступны через вашего основного провайдера или для вашего регионального расположения. В этом случае VPN-сервер должен располагаться в юрисдикции, из которой доступ к интересующему сайту ничем не ограничен.

Так если вы занимаетесь работой с американскими интернет-магазинами, то вам понадобится VPN-сервер в США, чтобы вы выглядели для сайтов резидентами этой страны.

В подобных случаях нет никакой необходимости пускать в туннель весь исходящий трафик, более разумно настроить правила, когда через VPN будут работать только необходимые сайты, а весь остальной трафик пойдет через основного провайдера.

Данный сценарий применим и для локальных сетей, но в этом случае VPN-клиент следует располагать на шлюзе, который получая запросы из локальной сети будет решать, какой пакет отправить дальше через провайдера, а какой через VPN.

Настраиваем VPN. Часть 1 - Общие вопросы

вс, 06/30/2019 - 00:10

VPN-технологии сегодня прочно вошли в повседневную жизнь и на слуху не только у IT-специалистов, поэтому мы решили обновить ряд старых статей, значительно дополнив и расширив имеющуюся в них информацию. Если десять лет назад VPN был в основном уделом достаточно крупных организаций, сегодня он широко используется повсеместно. В этой статье мы рассмотрим, что такое VPN в 2019 году, какие технологии доступны, в чем их достоинства и недостатки и как это все можно использовать.

Прежде всего определимся с терминологией. VPN (Virtual Private Network, виртуальная частная сеть) - обобщенное название технологий позволяющих обеспечить построение логической (виртуальной) сети поверх физической, чаще всего поверх сети интернет или иных сетей с низким уровнем доверия.

Для построения сетей VPN обычно используются туннели, туннелирование это процесс установления соединения между двумя точками с использованием инкапсуляции, когда данные одного протокола помещаются в "конверты" другого протокола с целью обеспечить их прохождение в неподходящей среде, обеспечения целостности и конфиденциальности, защиты с помощью шифрования и т.д. и т.п.

Т.е. если подходить к вопросу терминологии строго, то под VPN следует понимать виртуальную сеть, которая образуется путем установления туннельных соединений между отдельными узлами. Но на практике термины используются гораздо более вольно и очень часто вносят серьезную путаницу. Скажем, популярный сейчас доступ в интернет через VPN виртуальной частной сетью собственно не является, а представляет туннельное соединение для выхода в интернет, с логической точки зрения ничем не отличаясь от PPPoE, которое тоже является туннелем, но VPN его никто не называет.

По схеме организации можно выделить две большие группы: клиент-серверные технологии и просто туннели. В названии первых обычно принято использовать аббревиатуру VPN, у вторых нет. Туннели требуют наличия с обоих концов выделенного IP-адреса, не используют вспомогательных протоколов для установления соединения и могут не иметь инструментов контроля канала. Клиент-серверные решения, наоборот, используют дополнительные протоколы и технологии, осуществляющие установку связи между клиентом и сервером, контроль и управление каналом, обеспечение целостности и безопасности передаваемых данных.

Ниже мы рассмотрим наиболее популярные типы туннельных соединений, которые применяются для построения VPN-сетей, начнем с классических решений.

PPTP

PPTP (Point-to-Point Tunneling Protocol, туннельный протокол точка-точка) - один из наиболее известных клиент-серверных протоколов, получил широкое распространение благодаря тому, что начиная с Windows 95 OSR2 PPTP-клиент был включен в состав ОС. В настоящее время поддерживается практически всем спектром систем и устройств, включая роутеры и смартфоны (клиент удален из последних версий macOS и iOS).

Технически PPTP использует два сетевых соединения: канал управления, работающий через TCP и использующий порт 1723 и GRE-туннель для передачи данных. Из-за этого могут возникать сложности с использованием в сетях мобильных операторов, проблема с одновременной работой нескольких клиентов из-за NAT и проблема проброса PPTP соединения через NAT.

Еще одним существенным недостатком является низкая безопасность протокола PPTP, что не позволяет строить на нем защищенные виртуальные сети, но широкое распространение и высокая скорость работы делают PPTP популярным там, где безопасность обеспечивается иными методами, либо для доступа в интернет.

L2TP

L2TP (Layer 2 Tunneling Protocol, протокол туннелирования второго уровня) - разработка компаний Сisco и Microsoft, использует для передачи данных и управляющих сообщений единственное UDP соединение на порту 1701, но не содержит никаких встроенных средств защиты информации. L2TP-клиент также встроен во все современные системы и сетевые устройства.

Без шифрования L2TP широко применялся и применяется провайдерами для обеспечения доступа в интернет, обеспечивая таким образом разделение бесплатного внутрисетевого и дорогого интернет трафика. Это было актуально в эпоху домовых сетей, но данная технология продолжает применяться многими провайдерами и по сей день.

Для построения VPN обычно используют L2TP over IPsec (L2TP/IPsec), где IPsec работает в транспортном режиме и шифрует данные L2TP-пакета. При этом L2TP-туннель создается внутри IPsec-канала и для его установления необходимо прежде обеспечить IPsec-соединение между узлами. Это может вызвать сложности при работе в сетях с фильтрацией трафика (гостиничные сети, публичный Wi-Fi и т.д.), вызывает проблемы с пробросом L2TP/IPSec через NAT и работой из-за NAT одновременно нескольких клиентов.

К плюсам L2TP можно отнести высокую распространенность и надежность, IPsec не имеет серьезных уязвимостей и считается очень безопасным. Минус - высокая нагрузка на оборудование и невысокая скорость работы.

SSTP

SSTP (Secure Socket Tunneling Protocol, протокол безопасного туннелирования сокетов) - разработанный компанией Microsoft безопасный VPN-протокол, относится к так называемым SSL VPN, распространен преимущественно в Windows-среде, хотя клиенты доступны в среде многих современных ОС. Также есть сторонние серверные решения, скажем в Mikrotik.

Технически SSTP представляет собой туннельное PPP-соединение внутри HTTPS-сессии на стандартный порт 443. Для стороннего наблюдателя доступны только HTTPS-заголовки, наличия туннеля в трафике остается скрытым. Это позволяет успешно работать в любых сетях, так как HTTPS широко используется для доступа к сайтам и обычно разрешен, снимает проблему с пробросом или работой из-за NAT. Безопасен.

К плюсам можно отнести интеграцию в Windows-среду, безопасность, возможность работы через NAT и брандмауэры. К недостаткам - слабую или недостаточную поддержку со стороны других ОС и сетевых устройств, а также уязвимость к некоторым классическим SSL-атакам, таким как "человек посередине".

OpenVPN

OpenVPN - свободная реализация VPN с открытым исходным кодом. Для защиты соединения также используется SSL, но в отличие от SSTP заголовки OpenVPN отличаются от стандартных HTTPS, что позволяет однозначно определить наличие туннеля. Для передачи данных внутри SSL-канала OpenVPN использует собственный протокол с транспортом UDP, также существует возможность использовать в качестве транспорта TCP, но данное решение является нежелательным из-за высоких накладных расходов.

OpenVPN обеспечивает высокую безопасность и считается одним из самых защищенных протоколов, составляя альтернативу IPsec. Также имеются дополнительные возможности в виде передачи с сервера на клиент необходимых настроек и маршрутов, что позволяет легко создавать сложные сетевые конфигурации без дополнительной настройки клиентов.

Кроме туннелей, работающих на сетевом уровне (L3) - TUN, OpenVPN позволяет создавать соединения канального (L2) уровня - TAP, позволяя связывать сети на уровне Ethernet. Однако следует помнить, что в этом случае в туннель будет инкапсулироваться широковещательный трафик, а это может привести к повышенной нагрузке на оборудование и снижению скорости соединения.

Несмотря на то, что OpenVPN требует установки дополнительного ПО серверная часть доступна для Windows и UNIX-like систем, а клиентская в том числе и для мобильных устройств. Также поддержка OpenVPN имеется во многих моделях роутеров (часто в ограниченном виде).

К недостаткам можно отнести работу в пользовательском пространстве и некоторую сложность настроек. Скорость внутри OpenVPN туннелей также может быть значительно ниже скорости канала.

Несмотря на это OpenVPN имеет высокую популярность и достаточно широко используется как в корпоративных сетях, так и для доступа в интернет.

GRE туннель

GRE (Generic Routing Encapsulation, общая инкапсуляция маршрутов) - протокол туннелирования разработанный компаний Cisco и предназначен для инкапсуляции любых протоколов сетевого уровня OSI (т.е. не только IP), GRE работает непосредственно поверх IP и не использует порты, не проходит через NAT, номер протокола 47.

GRE требует белых IP-адресов для обоих сторон туннеля и является протоколом без сохранения состояния, т.е. никак не контролирует доступность противоположного узла, хотя большинство современных реализаций содержат дополнительные механизмы, позволяющие определить состояние канала. Также отсутствуют какие-либо механизмы безопасности, но это не является недостатком, так как в отличие от клиент-серверных решений GRE-туннели применяются в корпоративной и телекоммуникационной среде, где для обеспечения безопасности могут использоваться иные технологии.

Для построения защищенных решений обычно используется GRE over IPsec, когда туннель GRE располагается поверх защищенного IPsec канала, хотя возможно и иное решение - IPsec over GRE, когда защищенное соединение устанавливается внутри незашифрованного GRE-туннеля.

GRE поддерживается в UNIX-like системах, сетевом оборудовании (исключая домашние модели), а также в Windows Server начиная с версии 2016. Данный протокол широко используется в телекоммуникационной сфере и корпоративной среде.

IP-IP туннель

IP-IP (IP over IP) - один из самых простых и имеющий минимальные накладные расходы протокол туннелирования, но в отличие от GRE инкапсулирует только IPv4 unicast трафик. Также является протоколом без сохранения состояния и встроенных механизмов безопасности, обычно используется в паре с IPsec (IP-IP over IPsec). Поддерживается UNIX-like системами и сетевым оборудованием. Как и GRE не использует порты и не проходит через NAT, номер протокола 4.

EoIP туннель

EoIP (Ethernet over IP) - разработанный Mikrotik протокол туннелирования канального уровня (L2), работает на базе протокола GRE инкапсулируя Ethernet кадры в GRE пакеты. Позволяет соединять на канальном уровне удаленные сети (что равносильно прямому соединению патч-кордом между ними) и обеспечивать связь без использования маршрутизации. При этом следует понимать, что такое соединение предполагает прохождение широковещательного трафика, что способно существенно снизить производительность туннеля, особенно на узких каналах или каналах с большими задержками.

В тоже время EoIP может быть полезен для подключения торгового и промышленного оборудования, которое не умеет работать на сетевом (L3) уровне с маршрутизацией. Например, для подключения удаленных видеокамер к видеорегистратору.

Первоначально EoIP поддерживался только оборудованием Mikrotik, сегодня его поддержка реализована в оборудовании Zyxel и существуют пакеты для его реализации в среде Linux.

IPsec

IPsec (IP Security) - набор протоколов для обеспечения безопасности передаваемых по сетям IP данных. Также может использоваться не только для защиты уже существующих каналов связи, а для организации самостоятельных туннелей. Но IPsec-туннели не нашли широкого распространения по ряду причин: сложность настройки, критичность к ошибкам конфигурирования (может сильно пострадать безопасность) и отсутствие возможности использовать маршрутизацию для управления трафиком в таких туннелях (решение об обработке IP-пакетов принимается на основании политик IPsec).

Заключение

Переписывая данную статью, мы не ставили задачу объять необъятное, рассмотреть все существующие VPN-решения в рамках одной статьи невозможно. Ее назначение - познакомить читателя с основными используемыми сегодня технологиями для построения виртуальных частных сетей. При этом мы намеренно оставили за кадром решения от Cisco или иных "взрослых" производителей, так как их внедрением занимаются профессионалы, которым подобные статьи явно без надобности.

Также мы не стали рассматривать решения без широкой поддержки со стороны производителей сетевого оборудования, хотя там есть достаточно интересные продукты. Например, мультипротокольный сервер SoftEther VPN, который поддерживает L2TP, SSTP, OpenVPN и собственный SSL VPN протокол, имеет широкие сетевые возможности, графический клиент для настройки и администрирования и многие иные "вкусности". Или перспективный WireGuard, который отличается простотой, высокой производительностью и использованием современной криптографии.

Тем не менее, какую именно технологию следует использовать? Все зависит от сферы применения. Если стоит задача связать два офиса с выделенными IP-адресами, то мы порекомендовали бы использовать GRE или IP-IP, если возможность настройки удаленных сетей ограничена, то следует посмотреть в сторону OpenVPN, он также подойдет, если удаленные сети находятся за NAT или не имеют выделенного IP.

А вот для организации удаленного доступа следует использовать один из протоколов с нативной поддержкой в используемых пользователями системах или устройствах. Если у вас основу инфраструктуры составляют Windows-системы и не стоит вопрос доступа с мобильных устройств, то следует обратить внимание на SSTP, в противном случае лучше остановить свой выбор на универсальном L2TP.

PPTP в современных условиях не может считаться надежным из-за слабой защиты, но может оставаться хорошим выбором, если данные в туннеле будут передаваться по одному из защищенных протоколов. Скажем для доступа по HTTPS к корпоративному порталу или веб-версии корпоративного приложения, также работающему через SSL. В данном случае VPN будет обеспечивать дополнительную аутентификацию и сужать периметр атаки на приложение, безопасность самого канала в данном случае не будет играть решающей роли.

Movavi PDF Editor - теперь еще и работа с текстом

ср, 06/19/2019 - 15:18

Не так давно мы писали о простом и удобном инструменте для работы с PDF от отечественных разработчиков - Movavi PDF Editor. Тогда мы выразили сожаление, что в программе отсутствуют инструменты работы с текстом. Отрадно что разработчики прислушиваются к пожеланиям пользователей, и новая версия программы получила возможность редактирования текста.

Да, существуют бесплатные онлайн-сервисы, которое могут делать почти все тоже самое. Но не все так радужно, обычно бесплатно можно обработать лишь небольшое число страниц, после чего вас попросят приобрести подписку.

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

Новая версия Movavi PDF Editor с функцией редактирования текста доступна по ссылке https://pdf.movavi.ru/how-to-change-text-in-pdf.html и может быть бесплатно скачана для ознакомления. В ознакомительной версии нет ограничений по функциональности, но при сохранении на страницы документа накладывается водяной знак.

Сразу обращает внимание новый элемент интерфейса - Редактирование, при нажатии на который выпадает меню с предложением отредактировать изображение, текст или подпись. Затем просто выделяем нужный текстовый блок и вносим в него изменения.

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

Зато можно легко и просто внести небольшие изменения, скажем, в документацию. В нашем примере мы быстро заменили строку текста и изображение.

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

Зато можно легко и просто внести небольшие изменения, скажем, в документацию. В нашем примере мы быстро заменили строку текста и изображение.

Либо удалять, если они перестали быть нужны:

Чтобы добавить новый текстовый блок достаточно перейти в режим редактирования текста, щелкнуть мышкой в нужном месте страницы и просто начать набор на клавиатуре или вставить содержимое из буфера обмена.

Появление возможности работы с текстом делает данный продукт полноценным редактором PDF, а учитывая его невысокую стоимость, представляется нам практически безальтернативным вариантом для повседневного применения дома и на работе.

Также приятно что продукт развивается, и разработчики учитывают пожелания пользователей при выборе направления развития.

Автоматическое развертывание 1С:Предприятие в небольших сетях

сб, 06/15/2019 - 18:44

Все новое - это хорошо забытое старое. В данном случае эта поговорка подходит как нельзя лучше. Методика автоматического развертывания программ пакета 1С:Предприятие по сети, она же "административная установка", известна давно и хорошо описана в документации, но почему-то довольно редко используется на практике. Возможно, имеет место некоторое "разделение труда", специалисты по 1С не занимаются установкой, а системные администраторы не читают документацию 1С. Поэтому будет не лишним еще раз вернуться к этому вопросу.

Данная методика рассчитана в первую очередь на небольшие сети без Active Directory и позволяет существенно облегчить работу системного администратора и повысить комфорт работы с системой 1С:Предприятие.

Типичная ситуация: специалист по 1С (чаще всего приходящий), обновляет конфигурацию, которая требует новую версию платформы и администратор, отложив в сторону все дела (или сам специалист), начинает бегать по компьютерам пользователей устанавливая новую версию. Хорошо если компьютеров два или три, а если около десятка и разбросаны они по всему зданию?

Еще одна поговорка гласит, что дурная голова ногам покоя не дает. Если администратор не хочет думать головой, то ему придется бегать ногами, но это совершенно не наш метод, поэтому будем экономить собственное время и время пользователей, настроив автоматическое развертывание. Тем более что делается это очень быстро и просто.

Вам потребуется только общая папка на файловом сервере, которая будет иметь следующую структуру:

Вам потребуется расположить в ней файл запуска 1С 1cestart.exe, желательно от последней версии платформы, его можно взять в C:\Program Files (x86)\1cv8\common. Конфигурационный файл 1cescmn.cfg со следующим содержимым:

CommonInfoBases=ibcommon.v8i
DistributiveLocation=\\debian-smb\distr-1c
InstallComponents=DESIGNERALLCLIENTS=1 THINCLIENT=0 WEBSERVEREXT=0 SERVER=0 CONFREPOSSERVER=0 CONVERTER77=0 SERVERCLIENT=0 LANGUAGES=RU

Первая строка указывает на файл со списком общих баз, это необязательный параметр, имя файла также может быть произвольным. Вторая - сетевой путь к папке с дистрибутивами, т.е. нашему общему ресурсу. Последняя строка определяет компоненты пакета программ 1С:Предприятие, которые будут установлены. Ознакомимся с перечнем более подробно:

  • DESIGNERALLCLIENTS - все клиенты и конфигуратор.
  • THINCLIENT - тонкий клиент для клиент-серверного варианта работы.
  • THINCLIENTFILE - тонкий клиент с возможностью работы с файловыми информационными базами.
  • SERVER - сервер 1С:Предприятия. Если программа установки запускается из программы запуска, то сервер будет установлен как приложение.
  • WEBSERVEREXT - компоненты расширения для веб-сервера.
  • CONFREPOSSERVER - сервер хранилища конфигураций.
  • SERVERCLIENT - компоненты для администрирования кластера серверов.
  • CONVERTER77 - конвертер информационных баз из версии 1С:Предприятия 7.7.
  • LANGUAGES - список языков интерфейса для установки. Если указано несколько языков, они перечисляются через запятую.

Список общих баз, в нашем случае ibcommon.v8i, определяет перечень баз, которые будут подключены всем пользователям, это могут быть сетевые или клиент-серверный базы, обязательное условие - их доступность с любого ПК на которые будет устанавливаться платформа. Для его формирования можно воспользоваться файлом ibases.v8i, который расположен в %USERPROFILE%\AppData\Roaming\1C\1CEStart. Просто скопируйте оттуда необходимые секции.

Примерное содержимое файла:

[Информационная база]
Connect=File="\\debian-smb\1c_bases\base1";
ID=fdca4a8a-2875-4800-8200-6244f7e0bb93
OrderInList=551.492455418379
Folder=/
OrderInTree=1425664
External=0
ClientConnectionSpeed=Normal
App=Auto
WA=1
Version=8.3
[Информационная база #1]
Connect=Srvr="server1c";Ref="acc30";
ID=c3c7f1f3-eb72-4874-9fcc-8ca78ee052e5
OrderInList=16640
Folder=/
OrderInTree=16640
External=0
ClientConnectionSpeed=Normal
App=Auto
WA=1
Version=8.3

В нашем случае указаны две базы: файловая по сети и серверная. Если вы использовали файл-источник с ПК где базы расположены локально, то просто замените их пути на сетевые, остальные настройки трогать не надо. Кроме параметра Version=8.3, с его помощью можно указать требуемую платформу для запуска, например, Version=8.3.11 означает, что база должна использовать последнюю доступную версию платформы 8.3.11, а Version=8.3.10.2252 - работать только с платформой 8.3.10.2252.

Теперь разместим на сервере сами платформы, для этого нам потребуется распаковать архивы с Портала 1С и переименовать папку точно по номеру платформы, скажем, 8.3.10.2252. Кроме последней актуальной версии следует также разместить там выпуски платформ, используемые отдельными пользователями или базами. В нашем случае получилось так:

Общий ресурс готов, посмотрим, как это работает. Для первоначальной установки запустим файл 1cestart.exe с общего ресурса, это может сделать как администратор, так и сам пользователь. Это единственный раз, когда пользователю потребуется самостоятельно заходить на наш общий ресурс. Сразу после запуска начнется процесс установки платформы, который не задает вопросов и проходит полностью в автоматическом режиме.

При этом всегда устанавливается самая последняя доступная в общем каталоге версия платформы. Хорошо, но, если нам вдруг потребуется другая? Не проблема. Давайте укажем для одной из баз использовать только выпуск 8.3.11 и запустим ее.

Как видим, установка нужной платформы началась автоматически (при условии ее наличия на общем ресурсе).

После выхода новой версии платформы достаточно добавить еще одну папку на общий ресурс, обновление на клиентских ПК будет происходить автоматически при следующем запуске 1С. Т.е. если вы обновили платформу в разгар рабочего дня вам нужно всего лишь попросить пользователей выйти и снова зайти в программу.

Как видим, данный способ отлично подходит для использования в небольших сетях, избавляя администратора или специалиста по обслуживанию 1С от большого количества рутинной работы. Но есть и недостатки, один из них - наличие у пользователя прав для установки ПО, но в небольших сетях это, как правило, неактуально.

В крупных организациях с AD программное обеспечение разворачивается с помощью групповых политик и данная методика там просто не нужна. В тех случаях, когда пользователи без AD не имеют административных полномочий, для них следует включить политику Конфигурация пользователя - Административные шаблоны - Компоненты Windows - Установщик Windows - Всегда устанавливать с повышенными правами.

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

ROSA Linux - продолжаем знакомиться с российскими ОС

ср, 06/12/2019 - 23:55

Раз уж мы начали обзоры российских систем, то никак нельзя обойти стороной ROSA Linux. Пожалуй, это один из самых универсальных дистрибутивов, который изначально не "заточен" на применение в государственных учреждениях и может быть использован любым желающим. Версия Fresh распространяется именно как домашний дистрибутив и занимает на момент написания статьи 61-е место в рейтинге DistroWatch, что достаточно неплохо и говорит о том, что система интересна не только разработчикам.

В основе ROSA лежит достаточно популярный и известный в свое время дистрибутив Mandriva Linux, который, к сожалению, фактически прекратил свое существование в 2011 году. Mandrake, а позже Mandriva, можно смело назвать одной из ключевых систем в истории Linux. Именно с него начался "Linux с человеческим лицом", ярким представителем которого стала вышедшая позже Ubuntu. Да, не все было гладко, но это был один из первых дистрибутивов рассчитанный на домашнего пользователя. Дружелюбный, многоязычный, с поддержкой мультимедиа, с графическими инструментами настройки.

Впоследствии одним из совладельцев компании разработчика стал фонд NGI, с российскими владельцами, компания переживала не лучшие времена, к которым еще добавились разногласия между акционерами, что привело впоследствии к ее ликвидации. В итоге разработка дистрибутива была выведена в Россию, а большая часть французских разработчиков создало и развивают свой форк - Mageia. На этом пути проектов разошлись, и они продолжают развиваться самостоятельно.

Сегодня ROSA - полностью самостоятельный дистрибутив, разработка которого ведется в России, включая сборку в собственной среде.

В линейке продуктов представлено достаточно большое количество версий: бесплатный Fresh, коммерческий Enterprise Desktop и сертифицированные версии для госорганов Кобальт и Никель. Также существует собственная серверная линейка и системы виртуализации. Но они выходят за рамки нашего обзора.

ROSA Desktop Fresh R11

Начнем со свободной версии дистрибутива, который предлагается в разных вариантах с окружениями рабочего стола KDE4, KDE Plasma 5, XFCE и LXQt. Основным окружением является KDE 4, оно стоит первое в списке и на нем основана корпоративная версия. Поэтому мы взяли для обзора именно его.

Инсталлятор прост и минималистичен, ничего лишнего, способного запутать пользователя.

Все сделано в лучших традициях Windows, систему действительно можно установить в несколько кликов мыши, но и опытные пользователи не забыты, там, где это может быть необходимо есть возможность ручной настройки.

Затем можно откинуться на спинку кресла и полюбоваться слайдами, интерфейс предельно лаконичен - просто полоса прогресса.

В завершении установки потребуется ввести пароль суперпользователя и создать собственную учетную запись. Весь процесс вполне доступен пользователю, который видит Linux первый раз и не имеет никаких специфических знаний.

При входе в систему нас встречает окно приветствия классического вида, внешне напоминающее такое у Windows 7.

И рабочий стол KDE, эту среду трудно с чем-либо спутать.

Стартовое меню собственной разработки, по современной моде разворачивается на весь экран, но при этом достаточно удобное, с возможностью поиска.

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

Отдельный раздел TimeFrame выводит документы и мультимедийное содержимое домашней папки на временной шкале, это довольно удобно, если скажем, нужно найти фотографию, созданную две недели назад или документ, про который вы помните только то, что дело было в декабре...

Набор софта стандартный для Linux-систем: LibreOffice в качестве офисного пакета, GIMP, программы для работы со звуком и видео, для игр предлагается установить Steam. Установку можно выполнить прямо со стартового экрана. Аналогичным образом можно быстро установить Skype, Viber и некоторое другое ПО.

Сетевой принтер без проблем нашелся и был подключен, а вот для сетевого сканера, в отличие от Астры, пришлось поколдовать в консоли, хотя для домашнего применения это не самый типовой сценарий, а в организациях это работа системного администратора.

Несмотря на то, что ROSA базируется на пакетной базе RPM, в ней используется собственная система управления пакетами urpmi, доставшаяся в наследство от Mandriva. Это не хорошо и не плохо, просто надо иметь ввиду, что администраторам придется освоить работу с еще одной утилитой и нигде, кроме как в ROSA это знание ему не пригодится. Учитывая не самое широкое распространение дистрибутива, хотелось бы видеть в качестве альтернативы привычный RPM-пользователям YUM.

Магазина приложений как такового нет, вместо него имеется утилита Rpmdrake, в которой есть фильтр для приложений с графической оболочкой. Это стандартная утилита классического вида, для неподготовленного пользователя работать с ней будет тяжеловато, современный пользователь избалован магазинами с красивыми иконками. Утилита обновления самая обычная, каких-либо вопросов к ней нет.

Панель управления в целом стандартная для Linux-систем, многие настройки явно рассчитаны на неподготовленного пользователя. На наш взгляд это правильно, потому что именно сложность настроек отпугивает от Linux начинающих, а опытные линуксоиды все равно предпочитают выполнять настройки через консоль.

Из собственных разработок представлен достаточно неплохой медиаплеер, с поддержкой IP-TV, онлайн радио и прочих современных технологий, программа для создания загрузочных флешек из ISO-образов и довольно интересная утилита ROSA Freeze - для "замораживания" системы. Это позволяет проводить смелые эксперименты, не боясь за работоспособность ОС, после перезагрузки состояние системы откатится к исходному, но все пользовательские файлы останутся. Если же результат устраивает - то систему можно "разморозить", сохранив текущее состояние.

В общем работать с системой нам понравилось, хотя автор этих строк и не любитель KDE. На высоте также и поддержка, у ROSA неплохие русскоязычные ресурсы (вики, форум), сообщества в соцсетях и достаточно активная база пользователей. В общем чувствуется присутствие жизни.

ROSA Enterprise Desktop X3

ROSA Enterprise Desktop (RED) - это коммерческая версия системы с длительной поддержкой для бизнеса и организаций. Дистрибутив предоставляется по запросу и с ним два месяца бесплатной поддержки. Модель RED более всего похожа на LTSB выпуски Windows - это более старая, но более стабильная и отлаженная кодовая база, дополненная длительным сроком поддержки. RED X3 основана на Fresh 8.1, фактически это та же самая Fresh, но с дополнительной платной поддержкой от разработчиков.

Как видно из лицензионного соглашения, сам RED X3 бесплатен, вы покупаете именно поддержку, хотя дистрибутив в свободном доступе отсутствует. Но вы можете получить его по запросу, хотя большого смысла в этом нет, если вам не нужна коммерческая поддержка - используйте Fresh.

По большому счету RED X3 ничем принципиально от Fresh не отличается, не считая более темной цветовой гаммы и немного иного набора ПО, с большим количеством офисного ПО, предустановленной Java и отсутствием Steam.

Ну и ожидаемо более старые версии ПО.

Так как RED X3 направлен на корпоративное применение, то нас интересовали офисные функции. C Samba у RED дела обстоят отлично - мы без проблем получили доступ к общим ресурсам в сети Windows. Также мы опробовали сборку Wine и остались довольны, без труда запустив в ROSA некоторые специфические Windows-приложения для работы с государственными органами.

Что касается популярной учетной системы 1С:Предприятие - также нет никаких проблем, более того инструкция по ее установке есть в официальной Wiki. Кроме того, ROSA поддерживает все используемые в России токены и крипопровайдеры: Rutoken, CryptoPro и т.д.

Выводы

Как и Astra, ROSA опровергает расхожий миф, что ничего нормального в России сделать не могут. Мол сначала все украдут, а потом студенты за три копейки напишут что-нибудь для отвода глаз. ROSA зрелый и самодостаточный дистрибутив с собственным сообществом и неплохим рейтингом на DistroWatch, а в СПО сообщество административными методами не организуешь.

Да, есть определенные недочеты, что-то местами выглядит несовременно, но недостатки можно найти везде. В целом же ROSA проста, удобна, дружелюбна к пользователю. Для корпоративных пользователей есть RED, с официальной поддержкой. И то, что RED платный не должно вас смущать, без поддержки этот дистрибутив не представляет никакого интереса, так как никаких существенных отличий от Fresh в нем нет.

А вот что нам не понравилось, так это отсутствие, мы хотели написать "ярких", но нет, отличительных черт системы. Скажем, бросив беглый взгляд на любой из дистрибутивов Ubuntu вы тут же его опознаете, также трудно не узнать Mint или SUSE, Astra так же имеет характерную индивидуальность.

А в ROSA, да, есть индивидуальные черты, но все равно слишком много KDE, беглый взгляд скорее определит ее как "еще один дистрибутив с KDE", а не как "да это же ROSA". Так что двигаться дальше есть куда и мы надеемся, что ROSA продолжит развиваться.

Тем более что знакомство с ROSA вызвало у нас светлые ностальгические чувства, так как автор этих строк начинал свое знакомство с Linux с дистрибутива Mandrake 7.2, точнее не именно с него, но он первый из Linux который прижился. А потом была Ubuntu, но это уже совсем другая история...

Настройка файлового сервера Samba на платформе Debian / Ubuntu

вс, 06/09/2019 - 00:32

Файловый сервер можно без преувеличения назвать средством первой необходимости, даже в сетях без выделенного сервера вы всегда обнаружите папки с общим доступом, но по мере роста объемов данных появляется потребность в отдельном решении. Вариантов его организации множество, одним из которых является служба Samba на Linux-сервере, это простое, недорогое, но в тоже время мощное решение по организации общего доступа к файлам и папкам в Windows сетях. В данной статье мы рассмотрим настройку простого сервера на основе Samba 4 работающего в ОС Debian / Ubuntu.

Несмотря на то, что в данной статье в качестве ОС мы использовали Debain 9 все сказанное будет справедливо для любой ОС на базе Debian или Ubuntu, а с поправкой на работу пакетного менеждера - для любого Linux-дистрибутива. Также мы предполагаем, что читатель имеет базовые навыки работы с Linux-системами на базе Debian.

Подготовка системы

Прежде чем приступать к работе продумайте схему хранения данных и доступа к ним. Существую разные типы данных, которые мы будем характеризовать по интенсивности доступа к ним, скажем "холодные данные" отличаются тем, что обращения к ним происходят крайне редко (а к некоторым вообще никогда), но при этом они могут занимать значительные объемы. Это прежде всего резервные копии, инсталляционные пакеты, образа дисков и т.д. и т.п.

Противоположность им "горячие данные" - это данные которые интенсивно используются и изменяются, для файлового сервера примером таких данных может служить файловая информационная база 1С:Предприятия. Между ними находятся обычные данные, характер доступа к которым не имеет каких-либо особенностей.

Исходя из типа данных следует выбирать диски для хранения, для "горячих данных" это должны быть быстрые диски или SSD, а для "холодных" подойдут экономичные модели с упором на большой объем. Также не забывайте про RAID, для защиты данных от аппаратного выхода дисков из строя.

Также продумайте структуру директорий и прав доступа к ним. Разумно будет исходить из следующих соображений: разделяйте диски с данными и системой, чтобы при необходимости можно было заменить их без лишних затруднений или перенести на другой сервер. Храните разные типы данных на разных дисках или разделах, скажем, если на разделе для резервных копий закончится свободное место, то это никак не повлияет на работу баз 1С.

В нашем примере мы будем использовать виртуальную машину с двумя жесткими дисками, один для системы, второй для данных, точку монтирования диска для данных мы указали как /samba, вы можете использовать другое имя и расположение.

Также обратите внимание на имя компьютера, Samba 4 будет использовать его в качестве NetBIOS имени.

После установки ОС следует изменить настройку лимита на количество одновременно открытых файлов, в Linux это 1024, а в Windows 16384. Для этого откройте файл /etc/security/limits.conf и добавьте в конце две строки:

* - nofile 16384
root - nofile 16384

После чего сервер следует перезагрузить.

Установка и базовая настройка Samba 4

Установка Samba предельно проста:

apt install samba

После чего откроем файл /etc/samba/smb.conf и выполним общие настройки. Большинство указанных опций в файле уже есть, многие из них даже не потребуется менять, но их назначение будет полезно знать, поэтому мы прокомментируем наиболее важные из них.

За общие настройки сервера отвечает секция [global], которая, кстати, прекрасно прокомментирована. Обратите внимание на два вида комментариев опций, если для этого используется символ # - то указанное значение применяется по умолчанию, а символ ; обозначает предлагаемый вариант настройки.

Начнем, опции перечисляются в порядке их следования в файле:

workgroup = WORKGROUP

Обозначает рабочую группу Windows, по умолчанию WORKGROUP.

; interfaces = 127.0.0.0/8 eth0

Предлагаемая опция, которые определяет интерфейсы или подсети, с которыми будет работать Samba. Допускается смешанная запись, как в примере выше, либо можно указать только интерфейсы:

interfaces = lo ens33

Или только подсети:

interfaces = 127.0.0.0/8 192.168.16.0/24

Но само по себе указание интерфейсов не ограничивает Samba, для того чтобы ограничения начали действовать нужно включить следующую опцию:

bind interfaces only = yes

Следующая опция указывает расположение логов:

log file = /var/log/samba/log.%m

По умолчанию лог выключен, для того чтобы его включить добавьте в файл опцию:

log level = 1

Если вам нужен более подробный лог - установите более высокий уровень, минимальное значение - 1, максимальное - 5.

Также закомментируйте опцию:

# syslog = 0

В настоящий момент она является не рекомендованной (deprecated).

server role = standalone server

Обозначает простой файловый сервер, не требующий подключения к домену.

map to guest = bad user

Определяет способ определения гостевого доступа, при указанном значении гостем будет считаться любой пользователь, который отсутствует в базе Samba. Также могут использоваться значения never - не использовать гостевой доступ и bad password - в этом случае гостем будет считаться в том числе, и существующий пользователь если он неправильно введет пароль. Данное значение использовать не рекомендуется, так как при ошибке в пароле пользователь все равно получит доступ, но с гостевыми правами.

На этом общая настройка сервера закончена. Проверим конфигурацию на ошибки:

testparm

И перезапустим сервер

service smbd restart Настройка общего ресурса с гостевым доступом

Начнем с самого простого варианта - создадим общий ресурс, доступ к которому может иметь любой пользователь. Для этого добавим в конец файла /etc/samba/smb.conf следующие строки.

[public]
comment = Shared for all
path = /samba/public
read only = no
guest ok = yes

В квадратных скобках задаем имя ресурса, все что ниже скобок - секция этого ресурса. В ней мы указали следующие опции:

  • comment - описание ресурса, необязательный параметр;
  • path - путь к директории;
  • read only - режим только чтения, указываем no;
  • guest ok - разрешен ли гостевой доступ, указываем yes;

Теперь создадим саму директорию:

mkdir /samba/public

и установим на нее необходимые права, для гостевого ресурса это 777:

chown 777 /samba/public

Перезапускаем Samba и пробуем получить доступ с любого Windows-клиента.

Если все сделано правильно, то сервер появится в сетевом окружении, и вы без проблем получите доступ к созданной нами общей папке.

Настройка общего ресурса с парольным доступом

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

Снова откроем конфигурационный файл и добавим в него две секции:

[buch]
path = /samba/buch
read only = no
guest ok = no

[adm]
path = /samba/adm
read only = no
guest ok = no

Они предельно просты и отличаются запретом гостевого доступа - guest ok = no. Для того, чтобы разделить доступ к ресурсам будем использовать группы пользователей, создадим две новые группы для наших подразделений:

groupadd smbbuch
groupadd smbadm

Теперь создадим каталоги:

mkdir /samba/buch
mkdir /samba/adm

и изменим группу владельца:

chgrp smbbuch /samba/buch
chgrp smbadm /samba/adm

Затем установим права:

chmod 2770 /samba/buch
chmod 2770 /samba/adm

Значение 2770 обозначает что мы предоставляем полные права владельцу и группе, для остальных доступ запрещен. А первая двойка устанавливает SGID для каталога, что обеспечивает присвоение группы каталога каждому создаваемому в нем файлу.

В некоторых случаях определенный интерес представляет выставление дял каталога sticky bit, который означает, что удалить или переименовать файл может только его владелец, но работать с ним, в том числе изменять, может любой пользователь, имеющий права записи в каталог. Для этого вместо набора прав 2770 используйте права 3770.

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

Начнем с уже существующих пользователей, в нашем случае это пользователь andrey, который является главным администратором и должен иметь доступ к обоим ресурсам. Поэтому добавим его в обе группы:

usermod -aG smbbuch andrey
usermod -aG smbadm andrey

Затем добавим его в базу Samba:

smbpasswd -a andrey

При этом потребуется установить пароль для доступа к Samba-ресурсам, он должен совпадать с основным паролем пользователя. После чего включим эту учетную запись:

smbpasswd -e andrey

Проверяем, после ввода пароля мы должны получить доступ к созданным нам ресурсам. Также обратите внимание, после аутентификации в списке общих ресурсов появилась папка с именем пользователя, подключенная только на чтение.

С настройками по умолчанию Samba предоставляет каждому существующему пользователю доступ только на чтение к его домашнему каталогу. На наш взгляд это довольно удобно и безопасно. Если вас не устраивает такое поведение - удалите из конфигурационного файла секцию [homes].

Теперь о других пользователях. Скажем у нас есть бухгалтер Иванова и админ Петров, каждый из которых должен иметь доступ к своему ресурсу. В тоже время иметь доступ к самому Samba-серверу им необязательно, поэтому создадим новых пользователей следующей командой:

useradd -M -s /sbin/nologin ivanova
useradd -M -s /sbin/nologin petrov

Ключ -M заводит пользователя без создания домашнего каталога, а -s /sbin/nologin исключает возможность входа такого пользователя в систему.

Поместим каждого в свою группу:

usermod -aG smbbuch ivanova
usermod -aG smbadm petrov

Затем добавим их в базу Samba, при этом потребуется установить им пароли:

smbpasswd -a ivanova
smbpasswd -a petrov

И включим эти учетные записи

smbpasswd -e ivanova
smbpasswd -e petrov

Если все сделано правильно, то пользователь будет иметь доступ к своим ресурсам и не иметь к чужим.

Также обратите внимание, что несмотря на то, что общий ресурс с именем пользователя создан, доступ он к нему получить не сможет, так как физически его домашняя директория не существует.

Настройка корзины для общего ресурса

Полезность корзины на файловом сервере, пожалуй не будет отрицать никто. Человеку свойственно ошибаться и будет очень обидно, если ценой ошибки окажется несколько часов работы, но, к счастью Samba позволяет помещать удаленные файлы в корзину.

Для активации корзины добавьте в секцию к общему ресурсу следующие строки:

vfs objects = recycle
recycle:repository = .recycle
recycle:versions = yes
recycle:keeptree = yes

Первая опция добавит в общий ресурс новый объект - корзину, вторая укажет ее расположение - скрытая папка в корне. Две следующих включают сохранение структуры папок при удалении и сохранение нескольких версий файла с одним и тем же именем. Это нужно в тех случаях, когда разные пользователи удалят разные файлы с одним и тем же именем.

Перезапустим Samba и попробуем что-нибудь удалить.

Несмотря на грозное предупреждение Проводника удаляемые файлы перемещаются в корзину, откуда мы их можем восстановить.

Как видим, работать с Samba не просто, а очень просто, при том, что мы оставили за кадром многие возможности тонкой настройки, многие из которых требуют отдельных статей. Надеемся, что данный материал окажется вам полезным и поможет быстро и без проблем развернуть файловый сервер на Linux.

Админу на заметку - 25. CMDKEY или вы до сих пор вводите пароли?

сб, 06/08/2019 - 01:02

Операционные системы семейства Windows содержат много небольших утилит, делающих жизнь администратора проще и удобнее. Но не все из них на слуху, многие незаслуженно обделены вниманием, и, как показал читательский отклик, cmdkey - одна из них. Основная задача этой утилиты - управление учетными данными для доступа по сети и ее возможности трудно переоценить, особенно в одноранговых сетях. Поэтому, если вы или ваши пользователи испытывают затруднения с паролями, теряют доступ к сетевым ресурсам - то вам пора начать применять cmdkey, а как это сделать мы расскажем в данной статье.

Отношения пользователей и паролей в одноранговых сетях обычно бывают напряженными. Поэтому чаще всего используется гостевая модель доступа, но есть ряд сценариев, когда она неприемлема. Чтобы не быть голословными, приведем пару примеров из жизни.

На компьютере главного бухгалтера установлена 1С, доступ к базе, расположенной на общем ресурсе, должны иметь только бухгалтера, при этом они не должны знать пароля главного бухгалтера. Или у вас есть файловый сервер, доступ к ресурсам которого должен быть разделен между сотрудниками, скажем, чтобы менеджеры отдела продаж не имели доступа к папкам бухгалтерии. Также часто возникает вопрос доступа к различным ресурсам с админскими правами, например, для оснастки управления Hyper-V Server.

Обычно эти вопросы решаются двумя путями: завести на нужном узле все учетные записи пользователей, либо войти с нужного ПК с нужными учетными данными и запомнить пароль. Первый способ подходит в основном для серверов, а второй не отличается стабильностью, система время от времени начинает "забывать" пароли. При этом ситуация может осложняться тем, что пользователь не должен знать используемый пароль (скажем, главбух не хочет, чтобы бухгалтера в ее отсутствие могли войти в систему на ее ПК).

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

Во всех этих и подобных случаях на выручку придет небольшая утилита командной строки cmdkey. Она позволяет задать учетные данные для доступа к определенному узлу сети. Синтаксис ее прост, для добавления учетных данных используйте:

cmdkey /add:SERVER /user:Ivanov /pass:MyPa$$word

где SERVER - имя сетевого узла, в зависимости от условий вы можете использовать как плоское имя, так и FQDN, следующие две опции задают имя пользователя и пароль, в особых пояснениях не нуждаясь. Для доменных сетей имя пользователя следует указывать вместе с именем домена. Скажем так:

cmdkey /add:srv-01.interface31.lab /user:INTERFACE31.LAB\Ivanov /pass:MyPa$$word

или так:

cmdkey /add:srv-01.interface.lab /user:Ivanov@interface31.lab /pass:MyPa$$word

Ключ add задает учетные данные для сетевого входа в систему, если же вам нужно добавить учетные данные для иных сервисов, скажем терминального сервера, то следует использовать ключ generic:

cmdkey /generic:termsrv/SRV-RDP /user:Ivanov /pass:RdpPa$$word

Все учетные данные, введенные при помощи cmdkey хранятся в системном хранилище и недоступны пользователю. Это безопасно и дает в руки администратора определенную гибкость. Он может на ПК бухгалтеров указать учетные данные для доступа к компьютеру главбуха, но ее пароль останется для них неизвестным.

Посмотреть список сохраненных учетных данных можно командой:

cmdkey /list

Удалить учетные данные можно следующим образом:

cmdkey /delete:srv-01.interface.lab

Также cmdkey позволяет быстро удалить учетные данные для всех коммутируемых соединений (PPPoE, VPN и т.д.):

cmdkey /delete /ras

Как видим, статья получилась очень даже короткой, в отличие от широких возможностей, которые предоставляет небольшая утилита cmdkey. Надеемся, что данный материал будет полезен широкому кругу администраторов и поможет им в их повседневной деятельности.

Мечта об универсальных приложениях UWP мертва

вт, 06/04/2019 - 00:56

У Microsoft была мечта о Windows 8, которая включала бы универсальные приложения Windows, распространяющиеся на телефоны, планшеты, ПК и даже консоли Xbox. План состоял в том, чтобы разработчики могли написать одно приложение для всех этих устройств, и оно волшебным образом работало бы везде. Эта мечта начала разваливаться после провала Windows Phone, с тех пор прошлом много времени, и похоже, что теперь все закончено.

Microsoft потратила годы на то, чтобы подтолкнуть разработчиков к созданию специальных приложений для универсальной платформы Windows (Universal Windows Platform, UWP), но сегодня она забила последний гвоздь в гроб UWP.

Компания наконец-то разрешила разработчикам добавлять полностью нативные игры Win32 в Microsoft Store, а это значит, что многие игры, публикуемые разработчиками в других популярных магазинах, таких как Steam, теперь не нужно перестраивать для UWP.

«Мы понимаем, что Win32 -- это формат приложений, который любят использовать разработчики игр, а геймеры любят играть, поэтому мы рады сообщить, что мы обеспечим полную поддержку нативных игр Win32 для Microsoft Store в Windows», - пояснил глава Microsoft по играм Фил Спенсер. «Это откроет больше возможностей как для разработчиков, так и для геймеров, предоставляя возможности контроля и настройки которые они ожидают от открытой игровой экосистемы Windows».

Фил Спенсер, глава игрового подразделения Microsoft

Это большой шаг вперед для магазина приложений Windows, учитывая, что игры являются одними из самых загружаемых программ из магазинов. Ранее разработчики были вынуждены публиковать игры для Windows 10 через универсальную платформу Windows, которая просто не имеет того уровня возможностей, которые привыкли видеть в Windows на протяжении многих лет.

Недавно Microsoft объявила о своих планах по переводу браузера Edge на движок Chromium и отказе от UWP, чтобы сделать его доступным для Windows 7, Windows 8 и macOS. Джо Бельфиоре из Microsoft признался в интервью The Verge в начале прошлого месяца, что UWP только «вставлял палки в колеса» для Edge. «Дело не в том, что UWP -- это плохо, но UWP не является зрелой 35-летней платформой, для которой написано огромное количество приложений», - сказал тогда Бельфиоре.

Я слышал много историй, когда инженеры и разработчики Microsoft жаловались на то, что UWP накладывает ограничения на свои приложения, и сторонним разработчикам часто приходилось выбирать между созданием приложения UWP для Windows 10 или традиционным настольным приложением, которое будет работать в Windows 7, Windows 8 и Windows 10.

Джо Бельфиоре, вице-президент Microsoft и руководитель разработки Windows

Microsoft постоянно расширяла свое определение UWP, чтобы позволить разработчикам переупаковывать настольные приложения в Microsoft Store, но первоначальное видение приложений нового стиля, которые будут работать на ПК, телефонах, планшетах, Xbox и HoloLens становилось все более маловероятным.

Microsoft также приостановила работы над своей версией Office с поддержкой сенсорного ввода, предпочитая вместо этого сосредоточиться на облачных решениях, iOS, Android и настольных приложениях. Office всегда был центральным элементом UWP и хорошим примером того, как можно создать большое и требовательное приложение на новой платформе. Microsoft наконец прислушалась к разработчикам и больше не пытается навязывать им UWP.

«Вы сказали, что хотите, чтобы мы продолжили разделять многие части универсальной платформы, чтобы их можно было применять отдельно», - пояснил Кевин Галло, руководитель платформы Microsoft для разработчиков Windows, в начале прошлого месяца. Это означает, что со временем разработчики смогут использовать некоторые из положительных сторон UWP.

В отдельном интервью ZDNet Галло рассказал, что «к тому времени, когда мы закончим, останутся только «приложения для Windows». Еще не все готов, но компания стремится сделать каждую функцию UWP доступной для разработчиков.

В конечном итоге, это хорошая новость как для разработчиков, так и для пользователей Windows. Теперь мы должны увидеть больше игр в Магазине Microsoft, которые работают так, как того ожидают геймеры, и, надеемся, больше приложений. Магазин Windows был полон барахла на протяжении многих лет, и Microsoft с трудом привлекала туда разработчиков.

Старый подход Microsoft к магазину вызывал резкую критику закрытой платформы в Windows 10 и попыток компании заставить разработчиков распространять приложения через Microsoft Store. Microsoft даже создала версии Windows S и Windows RT в которых установка обычных приложений была заблокирована.

Новый шаг Microsoft по добавлению своих игр в Steam - это хороший признак того, что Спенсер меняет внутри Microsoft больше, чем просто консоль Xbox. Теперь нам нужно подождать, чтобы увидеть, что разработчики приложений и игр на этот раз сделают с Microsoft Store и платформой приложений Windows, которая станет гораздо менее ограничена.

Автор: Том Уоррен (Tom Warren)

Источник: Microsoft's Universal Windows Platform app dream is dead and buried

Настраиваем сеть NAT в Hyper-V

вс, 06/02/2019 - 22:35

Долгое время Hyper-V не имел возможности организации NAT собственными средствами, что в ряде случаев сильно ограничивало сетевые возможности гипервизора. Особенно остро это чувствовалось в лабораторных и тестовых средах, которые требовалось отделить от локальной сети, обеспечив при этом выход в интернет. С введением поддержки контейнеров потребность в сетях NAT только возросла, что сделало закономерным добавление функции преобразования сетевых адресов в гипервизор. Более подробно о настройке и особенностях применения NAT в Hyper-V мы расскажем в данной статье.

Создание сетей NAT возможно в Windows Server 2016, Hyper-V Server 2016 и более поздних версиях, а также Windows 10. На одном гипервизоре может быть создана только одна сеть NAT. Также обратите внимание, что в отличие от средств настольной виртуализации, таких как VMWare Workstation или VirtualBox, служба NAT в Hyper-V не предоставляет дополнительных сетевых служб, таких как DHCP или DNS, поэтому сетевые настройки виртуальным машинам вам придется назначить самостоятельно.

Также настройка NAT производится исключительно в консоли PowerShell и недоступна в графическом интерфейсе, однако это не представляет никаких сложностей.

Подключимся к нужному нам гипервизору, перейдем в командную строку и запустим консоль PowerShell:

powershell

Цвет консоли при этом не изменится, останется черным, но в начале строки приглашения появятся буквы PS.

Теперь создадим новый виртуальный коммутатор с типом сети Внутренняя:

New-VMSwitch -SwitchName "VM_NAT" -SwitchType Internal

где VM_NAT - имя нашего виртуального коммутатора, которое можно задать произвольно.

При создании сети данного типа автоматически создается виртуальный сетевой адаптер на хосте, поэтому просмотрим список адаптеров командой:

Get-NetAdapter

Из полученной информации нам нужно выяснить и запомнить индекс сетевого интерфейса, в нашем случае 16. Следующим шагом мы настроим на нем шлюз. Перед этим следует определиться с адресацией будущей сети NAT, выделив ей свою подсеть и указав адрес шлюза. В нашем случае это будут 192.168.192.0/24 и 192.168.192.1, теперь можно настраивать шлюз:

New-NetIPAddress -IPAddress 192.168.192.1 -PrefixLength 24 -InterfaceIndex 16

Где IPAddress - адрес шлюза, PrefixLength - префикс сети, префикс 24 соответствует маске 255.255.255.0, InterfaceIndex - индекс интерфейса, для которого мы выполняем настройку.

Ну и наконец создадим NAT:

New-NetNat -Name "vNAT" -InternalIPInterfaceAddressPrefix 192.168.192.0/24

где Name - имя нашей сети NAT, в нашем случае vNAT, задается на ваше усмотрение, InternalIPInterfaceAddressPrefix - внутренняя сеть NAT.

Теперь можно вернуться в оснастку управления Hyper-V, в Диспетчере виртуальных коммутаторов у нас появится новая сеть - VM-NAT.

Чтобы ее использовать, просто укажите этот коммутатор в настройках виртуальной машины:

Также вам потребуется выполнить ручную настройку сети внутри виртуальной машины, ей нужно выдать адрес и указать шлюз из внутренней сети NAT, а также любые доступные DNS:

Просмотреть существующие сети NAT, напоминаем, она должна быть только одна, можно командой:

Get-NetNat

Для удаления используйте:

Get-NetNat | Remove-NetNat

После этого вам также потребуется удалить назначенный шлюзу IP-адрес:

Remove-NetIPAddress -IPAddress 192.168.192.1 -InterfaceIndex 16

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

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

Remove-VMSwitch -SwitchName "VM_NAT"

Связанный с коммутатором виртуальный сетевой адаптер будет удален автоматически.

Автоматическое резервное копирование настроек Mikrotik на FTP

пт, 05/31/2019 - 20:38

Резервное копирование - это одно из наиболее важных мероприятий в работе системного администратора, но по иронии судьбы о нем обычно вспоминают тогда, когда ничто иное помочь уже не способно. Роутеры Mikrotik не исключение. Широкие возможности RouterOS предполагают гораздо более сложные сетевые конфигурации, нежели у обычных, "бытовых", роутеров, поэтому восстановить все заново бывает весьма и весьма затруднительно, даже если вы точно помните все тонкости настройки. А чтобы до этого не дошло, стоит позаботиться о резервных копиях уже сейчас.

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

В каких случаях вам может понадобиться восстанавливать Mikrotik из резервной копии? Самое очевидное - физический выход устройства из строя или критический сбой, в результате которого прошивка будет повреждена. Затем идет неудачное обновление (хотя это случается довольно редко) и ошибки администрирования.

Например, не так давно один мой коллега случайно выключил внутренний мост, при том, что снаружи доступ к устройству был запрещен. Управление устройством было потеряно, сеть оказалась отрезана от внешнего мира. Но благодаря наличию резервных копий восстановление заняло считанные минуты: сбросить конфигурацию устройства и залить в него последний бекап. Большинство пользователей даже ничего не заметило.

Итак, нам нужно организовать резервное копирование конфигурации Mikrotik. На помощь нам придет скриптовый язык RouterOS, возможность создавать и выполнять собственный скрипты на всей линейке роутеров трудно переоценить. Но хранить бекапы нужно отдельно от самого устройства и здесь нам доступны два варианта: отправлять их на почту или FTP-сервер.

Вариант с почтой можно назвать условно приемлемым если у вас одно-два устройства. Если же счет им идет на десятки, то вы получите форменное захламление почтового ящика и очень сложный контроль за наличием актуальных копий.

В этом плане FTP выглядит гораздо более привлекательно. Не нужно гадать, выполнил ли роутер бекап, или это антиспам "балуется", если в директории нет свежих бекапов - значит есть какие-то проблемы и нужно действовать.

Еще один тонкий момент. Mikrotik предлагает нам два варианта резервного копирования :выгрузка резервной копии устройства, которую можно восстановить только на аналогичном устройстве, и экспорт настроек в текстовом формате, которые можно импортировать полностью или частично на любое устройство.

Полный бекап содержит в себе все ключи, сертификаты, админские пароли и т.д, поэтому его крайне нежелательно выгружать в незашифрованном виде. Экспортированный текстовый файл критически важных данных не содержит, но в нем открытым текстом содержатся пароли к Wi-Fi, коммутируемым соединениям и т.д. Поэтому при его хранении тоже следует соблюдать определенные меры безопасности.

Исходя из этих соображений мы будем выгружать и хранить оба варианта. Для этих целей мы написали небольшой и достаточно простой скрипт, несмотря на то что подобных скриптов доступно достаточно большое количество, мы постарались сделать его наиболее понятным и универсальным.

#Резервное копирование конфигурации Mikrotik
#Получаем дату в формате дд-мм-гггг

:local tmpdate [/system clock get date];
:local months ("jan","feb","mar","apr","may","jun","jul","aug","sep","oct","nov","dec");
:local month [ :pick $tmpdate 0 3 ];
:local mm ([ :find $months $month -1 ] + 1);
:if ($mm < 10) do={ :set mm ("0" . $mm); }
:local date ([:pick $tmpdate 4 6] ."-" . $mm ."-" . [:pick $tmpdate 7 11])

#Задаем переменные и параметры доступа к FTP

:local myname "M2-hAP-ac-lite"
:local fname ($myname."_".$date);
:local bname ($myname."_".$date.".backup");
:local ename ($myname."_".$date.".rsc");
:local ftpuser "mikrotik";
:local ftppass "mYPa$$word";
:local ftpaddr "203.0.113.21";

#Выгружаем настройки

/system backup save name=$fname password=BackPa$$word;
:delay 10;
/export file=$fname
:delay 10;

#Загружаем конфигурацию на FTP

/tool fetch address=$ftpaddr src-path=$name user=$ftpuser password=$ftppass port=21 upload=yes mode=ftp dst-path=$bname
:delay 15;
/tool fetch address=$ftpaddr src-path=$ename user=$ftpuser password=$ftppass port=21 upload=yes mode=ftp dst-path=$ename
:delay 15;

#Удаляем файлы с устройства

/file remove $bname;
/file remove $ename;

Первый блок может показаться избыточно сложным, но это связано с тем, что Mikrotik возвращает месяц в виде трехбуквенной аббревиатуры, а для хранения бекапов лучше использовать полностью цифровые значения даты.

Затем задаем переменные. Как можно заметить, мы задали несколько переменных с именами файлов. Этого можно было не делать и формировать нужные имена прямо в скрипте, но в этом случае сильно страдает его читабельность. Мы не советуем этим пренебрегать, потому что впоследствии, когда подробности уже забудутся, разобраться с сложном скрипте будет сложнее, нежели в простом.

Далее должно быть все понятно, во многом благодаря нашим немного избыточным переменным. Выгружаем полный бекап и экспортируем конфигурацию, отправляем на FTP, удаляем с устройства.

Теперь перейдем на целевое устройство: System - Scripts и создадим новый скрипт:

Прежде всего укажем имя скрипта, так как нам потребуется вызывать его в дальнейшем, пробелов в имени быть не должно. Выставляем политики как на скриншоте, хотя это не особо критично, и копируем в поле Source наш скрипт.

Для того, чтобы отличать конфигурации друг от друга задайте уникальную переменную myname. Лично мы используем следующий шаблон:

[идентификатор организации/места нахождения устройства] - [наименование устройства]

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

После того, как вы создали скрипт его следует проверить, нажмите Run Script и убедитесь, что он делает все как вам надо. Обязательно проверьте со стороны FTP что файлы приходят и их можно восстановить.

Все работает? Отлично! Самое время добавить его в планировщик. Откроем System - Scheduler и добавим новое задание:

Имя задания может быть любым, а вот остальные опции нуждаются в пояснениях. Прежде всего определимся, с какой частотой мы хотим делать копии. Лично мы делаем резервное копирование раз в неделю, по воскресениям. Поэтому в Start Date указываем дату прошлого воскресения, в Start Time - время начала выполнения задания, в нашем случае - десять минут после полуночи. В поле Interval указываем периодичность повторения задания - ровно 7 дней.

Выставляем политики как на скриншоте, что снова некритично, и в поле On Event указываем команду запуска созданного нами скрипта:

/system script run backup_to_ftp

где backup_to_ftp - его имя.

Теперь каждое воскресение в указанное время ваше устройство будет делать две резервные копии конфигурации и отправлять их на FTP-сервер. Если устройств несколько, то мы советуем разнести их по времени, чтобы их задания не пересекались.

Подключаем ККТ ШТРИХ-М к 1С:Предприятие 8.3

пт, 05/31/2019 - 17:27

Продолжая тему подключения онлайн-касс, сегодня мы рассмотрим подключение устройств второго популярного производителя кассовой техники - компании ШТРИХ-М. В отличие от своего конкурента, у ШТРИХа не все так гладко при подключении касс через USB и даже официальная документация не отличается полнотой, предлагая только один, не самый удачный вариант настройки. Он не отличается стабильностью и справедливо вызывает множество нареканий, тем не менее при грамотной настройке онлайн-кассы ШТРИХ-М способны вполне стабильно работать в данном режиме. Как это сделать - мы расскажем в данной статье.

В очередной раз сделаем небольшое отступление и сразу предупредим вас: онлайн-кассы - это сложное и специфическое оборудование, которое требует для своего обслуживания наличия специальных знаний и опыта. Поэтому мы настоятельно не рекомендуем заниматься прошивкой и регистрацией касс самостоятельно, цена ошибки здесь может быть гораздо выше, чем стоимость услуг сервисных организаций. Тем более у некоторых моделей ШТРИХ-М превратить кассу в "кирпич" можно было при полностью штатной процедуре прошивки, т.е. не совершив со своей стороны ошибок в этом процессе.

Второе предупреждение связано с 1С:Предприятие, в силу определенных особенностей реализации драйвера эта связка чувствительна к соответствию версий всех составляющих комплекса: версии прошивки ККТ, драйвера ШТРИХ-М и драйвера 1С (входит в состав конфигурации). При несовпадении версий касса либо будет работать с ошибками, либо вы ее подключите вообще. Комбинации новая прошивка - старый драйвер - старая конфигурация или старая прошивка - новый драйвер - новая конфигурация будут приводить к ошибкам при работе с кассой в 1С, а сочетания новый драйвер - старая конфигурация или старый драйвер - новая конфигурация не дадут подключить кассу вообще.

Основная линейка ККТ ШТРИХ невелика, всего три модели:

Младшая - ШТРИХ-ON-LINE, как и полагается бюджетной модели, предполагает только USB или RS-232 подключение:

Слева направо: денежный ящик, RS-232, USB.

На старших моделях присутствует дополнительно сетевой интерфейс, также кассы могут иметь на борту Wi-Fi адаптер. Но подключать ККТ по беспроводной сети, разве что кроме младшей модели, мы бы не рекомендовали, в реальных условиях такое подключение характеризуется большим временем отклика, что делает работу кассы "задумчивой".

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

Будем считать, что у вас на руках касса ШТРИХ с последней прошивкой, а также актуальная конфигурация 1С. Свежий драйвер ШТРИХ-М всегда можно скачать с сайта производителя. Если же вы перешли не по нашей ссылке, то просто выполните в разделе Скачать поиск по фразе "Драйвер ККТ", в противном случае его поиск может превратиться в "увлекательный" квест.

При установке драйвера обязательно выберите два компонента: Драйверы и тесты и Служба ofdconnect.

Теперь подключим к USB саму кассу, здесь может быть два варианта: касса уже переведена в RNDIS-режим и в этом случае у вас в системе появится новый сетевой адаптер, либо находится в режиме VCOM. Мы не будем пока касаться RNDIS, рассмотрим подключение устройства в режиме VCOM.

Перейдем в Тест драйвера ФР - Настройка свойств. В открывшемся окне заполним параметры подключения: Локально с указанием используемого COM-порта и скорости. Затем нажмите Проверка связи и внизу вы должны увидеть наименование ККТ и ее серийный номер.

Если подключиться не удается или вы сомневаетесь в правильности указания обмена, то нажмите Поиск оборудования, утилита определит нужные параметры автоматически:

Имейте ввиду, что после технологического обновления ККТ имеет скорость порта 4800, а не 115200, если вы неправильно укажете скорость - связи с ККТ не будет. Поэтому обязательно обращайте внимание на этот параметр, а не только на номер порта.

Все настройки кассы хранятся в Таблицах, которые доступны по одноименной кнопке в окне Свойства. При их редактировании будьте внимательны, если не уверенны в своих действиях - предварительно сделайте экспорт. Ну а если совсем ничего не помогает или вы взяли кассу бывшую в эксплуатации, то лучшим решением будет сбросить таблицы на значения по умолчанию кнопкой Инициализировать.

Из всего множества настроек практический интерес представляет таблица 1 - Тип и режим кассы, где сосредоточено большинство самых востребованных настроек. Большинство опции интуитивно понятны, в остальных случаях следует обратиться к документации на вашу ККТ.

Обратите внимание, что структура таблиц общая для всех моделей ККТ, поэтому часть опций могут быть неприменимы к вашей модели. Скажем, если в ней нет отрезчика, то настраивать его опции бесполезно, несмотря на то что они есть.

В таблице 4 - Текст в чеке можно отредактировать клише.

Ненадолго вернемся в сам Тест драйвера. Пункт 01. Состояние позволяет получить разнообразную информацию о кассе: статус смены, наличие бумаги, состояние датчиков и т.д. и т.п.

В разделе 03. Отчеты можно выполнить открытие / закрытие смены, снять отчет без гашения.

Для работы с фискальным накопителем перейдите в 11. ФН, однако здесь нужно быть предельно осторожным, так как вам будут доступны потенциально деструктивные операции с накопителем.

Закладка Данные позволяет получать информацию из фискального накопителя, например, мы можем получить содержимое документа (чека) по номеру и распечатать копию при необходимости.

Закладка ОФД позволяет контролировать обмен с оператором фискальных данных и позволяет получить квитанцию по номеру фискального документа.

Отдельного разговора заслуживает раздел 17. Прочее - Команда, который позволяет отправлять на кассу низкоуровневые команды. Очевидно, что использовать эту возможность надо осмотрительно, но в ряде случаев она способна сильно облегчить жизнь. Например, для удаленной перезагрузки ККТ ШТРИХ следует послать команду:

FE F3 00 00 00 00

Перевод ККТ в режим RNDIS

Теперь, когда мы рассмотрели основные возможности драйвера, перейдем к настройке нашей кассы. Прежде всего переведем ее в режим RNDIS. Для этого откроем таблицу 21 - Сетевые интерфейсы и установим значение опции 9 - Rndis равным 1. После чего ККТ следует перезагрузить.

После чего порт VCOM пропадет, но появится новый сетевой адаптер с типом Remote NDIS based Internet Sharing Device, по умолчанию ККТ имеет адрес 192.168.137.111, поэтому присваиваем адаптеру любой иной адрес из этой подсети, в нашем случае 192.168.137.1.

Если вам необходимо изменить IP-адрес ККТ, от откорректируйте значения в таблице 16 - Сетевой адрес. Будьте внимательны, если вы введете некорректные значения, то получить доступ к кассе можно будет только через физический COM-порт или делать технологическое обнуление (требует вскрытия корпуса).

Снова откроем Тест драйвера и укажем следующие параметры подключения: TCP-сокет, Адрес - 192.168.137.111, порт - 7778. Если все сделано правильно - связь с ККТ будет.

Аналогичным образом будут выглядеть настройки ККТ ШТРИХ и для сетевого подключения. Для касс, работающих по Wi-Fi может потребоваться увеличить таймаут, если связь с ними будет нестабильной или ее не будет вообще (при условии видимости устройства в сети).

Подключение ККТ к 1С:Предприятие

Необходимый для работы ККТ ШТРИХ драйвер торгового оборудования поставляется в составе конфигурации и никаких дополнительных действий выполнять не надо. Создаем новый экземпляр оборудования, тип оборудования - ККТ с передачей данных, драйвер оборудования - ШТРИХ-М:ККТ с передачей данных в ОФД.

Сохраним его и перейдем к настройкам, где укажем тип подключения TCP socket, а также IP-адрес и порт. В общем все тоже самое, что и в Тесте драйвера.

Дальнейшая настройка зависит от используемой вами конфигурации и выходит за рамки данной статьи. Но в любом случае не забудьте указать адрес в настройках торговой точки и физическое лицо для пользователя, который будет работать с кассой. В противном случае при попытке пробить чек вы получите ошибку с сообщением что один из реквизитов не заполнен (Адрес или Кассир).

Настройка работы с ОФД через службу OFDConnect

В большинстве руководств обычно советуют расшарить на основном сетевом адаптере интернет. Но это не всегда возможно, да и работает такая связка нестабильно, поэтому компания ШТРИХ-М выпустила специальную службу - OFDConnect, которая теперь поставляется в составе драйвера, но документацию обновить не спешит, и многие, в том числе работники сервисных организация продолжают подключать ШТРИХи по-старинке.

Откроем Тест драйвера и перейдем Настройка свойств - Дополнительные параметры - Настройка RNDIS/ОФД.

Теперь важно правильно соблюсти последовательность действий:

Прежде всего включим и запустим службу: кнопки Включить передачу данных и Активировать, по умолчанию служба будет использовать порт 7878, можете изменить это значение. Следующим шагом прочитаем необходимые настройки из ККТ одноименной кнопкой. Будет получен сетевой адрес кассы и параметры подключения к ОФД. Затем определим адрес RNDIS-адаптера, либо заполните это поле вручную. После чего нажмите Записать в ККТ, это изменит значения таблицы 19 - Параметры ОФД, заменив адрес сервера ОФД на адрес службы OFDConnect. Ниже показаны значения до и после.

И наконец нажмем Применить изменения, что внесет необходимые изменения в конфигурацию службы, ККТ после этого будет необходимо перезагрузить.

Сама служба находится в C:\Program Files (x86)\SHTRIH-M\DrvFR 4.14\Bin\OFDConnect и состоит из исполняемого файла и двух конфигурационных.

Файл Settings.ini содержит настройки самой службы:

[settings]
ServerPort=7878
Log=1
LogErrorsOnly=0
LogFileCount=10

Как видим, настроек ровно столько, сколько было в графическом интерфейсе, каких-либо скрытых опций нет. Настройки касс хранятся в KKTProfiles.ini:

[KKT1]
KKTAddress=192.168.137.111
OFDAddress=connect.ofd-ya.ru
OFDPort=7779
OFDConnectionTimeout=25000
OFDReadTimeout=25000
KKTReadTimeout=15000

Таким образом мы можем и не использовать графический интерфейс для настройки, достаточно внести изменения в таблицу 19 и два конфигурационных файла, затем перезапустить службу (не забыв установить автоматический запуск) и перезагрузить кассу.

Проконтролировать обмен с ОФД можно в логах, которые находятся здесь же в отдельной папке. Логи ведутся в текстовом формате и отображают процесс получения службой данных от ККТ, передачу их в ОФД, получение и запись в ККТ ответа от оператора.

Дополнительный контроль можно осуществлять в личном кабинете ОФД, где должны появиться все пробитые чеки и документы открытия и закрытия смены.

Как видим настройка ККТ ШТРИХ совместно с OFDConnect не представляет существенной сложности, не требует изменения сетевой конфигурации компьютера и обеспечивает стабильное, управляемое и диагностируемое решение. Данная схема неоднократно была опробована на практике и проверена длительным сроком работы, поэтому мы можем смело рекомендовать ее к применению.

Astra Linux 2.12 Orel - избавляемся от стереотипов о российском ПО

пн, 05/27/2019 - 00:26

Хорошо говорить об отечественном ПО у нас почему-то не принято. Да, многие образцы ведомственных программ представляют шедевры криворукости, но это не повод мазать всю отрасль одной краской. Сегодня существует определенный ажиотаж вокруг отечественной ОС и темы импортозамещения. Если отбросить отсюда всю информационную мишуру, то мы не видим в данной затее ничего плохого, особенно если речь идет об информационных структурах государственных и силовых ведомств. Сегодня мы решили рассмотреть отечественную ОС Astra Linux, недавно получившую допуск для работы с данными высшей степени секретности.

В отличие от недавно рассмотренного нами Эльбруса, который был выложен в виде мало к чему пригодного полуфабриката, Astra Linux является завершенным коммерческим продуктом. Существуют две основных редакции ОС: общего назначения (Common Edition) - релиз "Орел" и специального назначения (Special Edition) - релиз "Смоленск". Понятно, что все доступы и сертификаты имеет ОС специального назначения и просто так получить ее не представляется возможным, в то же время "Орел" доступен всем желающим и бесплатен для некоммерческого применения.

Чтобы сразу пресечь спекуляции по поводу платного Linux, скажем, что свободное ПО не ставит знак равенства с бесплатным. Хотя мы и считаем, что финансирование отечественной ОС должно производиться государством, коммерческая модель здесь тоже имеет место и если деньги за систему пойдут отечественным разработчикам - ничего плохого в этом не будет. Тем более основные заказчики Astra Linux - это силовые ведомства, а там свои методы финансирования и взаимоотношений с подрядчиками.

С учетом того, что Astra Linux в полной мере поддерживает отечественную криптографию, цена лицензии на ОС общего назначения не так уж велика.

Но не будем долго растекаться мыслью по дереву, а собственными глазами посмотрим на продукт отечественных разработчиков. Astra Linux основан на базе Debian, поэтому уже становится понятно, что нам следует ожидать и как должна работать данная ОС. Debian - хорошая система, стабильная, с большим набором ПО и документации, а также наиболее свободная из основных дистрибутивов (никакая зарубежная корпорация за ней не стоит), поэтому ее выбор за основу вполне обоснован.

Инсталлятор представляет собой стандартный инсталлятор Debian, поэтому мы не будем подробно на нем останавливаться, все привычно и понятно. Сразу обратим внимание на предлагаемый выбор ПО, а именно на графическую оболочку Fly, которая является собственной разработкой. Это сразу ставит Astra Linux несколько особняком от других дистрибутивов на базе Debain, собственными графическими оболочками могут похвастаться немногие из них.

Что касается набора ПО, то для рабочей станции он достаточно сбалансирован, а что-то специализированное всегда можно поставить отдельно, специалисты обычно знают, что им нужно, а простому пользователю обилие "непонятных" пакетов ни к чему.

Отдельно предлагается ряд специфичных настроек, скажем, возможность использовать ядро Hardened, включающее в себя дополнительные настройки безопасности или возможность использовать службу ALD (Astra Linux Directory). Про нее следует сказать отдельно, это не очередная свободная реализация Active Directory, а полностью самостоятельная разработка с прицелом на создание собственной доменной системы. Процитируем разработчиков:

При разработке ALD задача имитации контроллера домена Microsft Windows не решалась. Таким образом, включение машины ОС Microsft Windows в домен ALD штатными средствами ОС Microsft Windows невозможно. Установив в ОС Microsft Windows клиента MIT Kerberos вы сможете получить билеты Kerberos на сервере ALD. Далее вы получите доступ к серверам печати, СУБД, WEB и электронной почты в сеансе с нулевыми мандатными атрибутами. Если вам необходимо получать доступ к ресурсам серверов, работающих под управлением Astra Linux, в ненулевом мандатном контексте, то вам необходимо самостоятельно разработать клиента ALD под Microsft Windows.

Может показаться, что разработчики изобретают очередной велосипед, но это не так, обычные, "гражданские" системы, в том числе и Active Directory, применяют дискреционное (избирательное) управление доступом. Это предполагает, что у каждого объекта системы есть свой владелец, который и устанавливает права доступа к нему, также может быть суперпользователь (Администратор, root и т.д.) который может изменить владельца и права доступа к любому объекту.

В структурах с конфиденциальной и секретной информацией применяется иной подход - мандатное (принудительное) управление доступом, основанное на имеющихся у субъекта уровнях доступа.

Простой пример: допустим Василий на некоторое время был переведен в отдел A, получил на файловом сервере свою папку и работал в ней с документами, потом вернулся в отдел B. При избирательном доступе Василий потеряет доступ к папкам отдела А, но сохранит доступ к собственной папке и файлам, так как является их владельцем. При мандатном доступе, покинув отдел А от потеряет право доступа к документам с отметкой "для служебного использования", в том числе и к тем, что он создал.

Astra Linux Directory как раз представляет реализацию домена с мандатной системой и никоим образом не заменяет и не подменяет Active Directory, представляя систему с принципиально иным подходом к разграничению прав доступа.

В остальном процесс установки ничем не отличается от Debian и каких-либо затруднений не вызывает. Окно входа в систему выполнено достаточно аккуратно, преимущественно в плоском стиле, в строгой цветовой гамме.

После входа в систему нас встречает рабочий стол. От былой аляповатости не осталось и следа, все строго и выверено. И если встречать по одежке, то здесь у Astra Linux все хорошо, а сам рабочий стол чем-то напоминает KDE и Windows одновременно, представляя собой классическое рабочее пространство, что не должно вызвать сложностей с его освоением.

Меню Пуск также выполнено в классическом стиле и ему не хватает интерактивного поиска, но в остальном впечатления только приятные. Набор прикладного софта преимущественно стандартный, входящий в актуальный Debain, подобран хорошо и закрывает большинство потребностей пользователя из коробки.

Терминал также собственный, с поддержкой вкладок, вкладки можно называть по собственному усмотрению, что весьма удобно. Также система имеет собственные репозитории, выше на скриншоте мы как раз запустили процесс обновления.

Файловый менеджер довольно прост, на уровне простых оболочек вроде XFCE или LXDE, но понятен и удобен в работе.

Но есть и интересные "фишки" вроде двухпанельного режима:

Также обращает внимание довольно скромное потребление системных ресурсов, на виртуальной машине с 2 ГБ памяти Astra Linux чувствует себя достаточно комфортно.

В качестве офисного пакета используется LibreOffice с плоской темой, отлично вписываясь в общий вид системы, некоторое недоумение вызвал только калькулятор. Нет, он очень крутой, но большинству этого не надо.

Даже если говорить за себя, то такой калькулятор нам нужен, но не на каждый день. Тем более что в репозиториях мы нашли более привычный вариант:

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

Панель управления также несет в себе сильное влияние Windows и в данном случае это хорошо, пользователь получает более-менее привычные инструменты, что позволяет решать многие задачи просто по аналогии.

Скажем настройка автозагрузки:

Или переменных окружения:

Понятные русские описания опций заслуживают отдельного внимания. Вроде бы мелочь, но из таких мелочей и складывается впечатление о продукте.

Одним из недостатков системы некоторые обозреватели ставят отсутствие магазина приложений. Да это так, и это можно было бы записать в недостаток, если бы не четкое позиционирование данной системы для государственных и силовых учреждений. Спросите любого системного администратора что он думает о магазине в Windows 10, узнаете много интересного, скорее всего в непечатной форме. Исходя из этого, отсутствие магазина становится не столь критичным. Нужное ПО установит администратор, а у пользователей будет меньше соблазнов.

Из графических инструментов доступен привычный Synaptic и простая утилита для обновления:

Второй из озвучиваемых недостатков - слабая поддержка Samba из коробки. Действительно, ее нужно настраивать руками. Хотя, учитывая стремление разработчиков к собственной экосистеме со своим доменом, это выглядит вполне обоснованным. Там, где будет применяться Astra Linux, особенно специальный выпуск, взаимодействие с Windows машинами будет далеко не самой главной задачей, а скорее наоборот.

Ну а при необходимости нормальный администратор все быстро настроит, Samba она везде одинаковая. Также можно скачать из репозитория графический инструмент управления, который поможет быстро расшарить папку.

В целом же система очень приятна, как по внешнему виду, так по комфорту работы. Существенных недостатков мы не обнаружили, а описанные выше явно притянуты за уши, особенно если учитывать назначение системы.

Так как у нас система общего назначения, то попробуем установить что-нибудь со стороны, для этого выпуска это вполне допустимо, в отличии от систем специального назначения. Попробуем скачать и установить Google Chrome. Никаких проблем у нас при этом не возникло, а все зависимости подтянулись из собственных репозиториев дистрибутива.

Как видим, система не ставит никаких палок в колеса и позволяет без проблем ставить сторонние пакеты, подключать сторонние репозитории и вам доступны все возможности экосистемы Debian.

Но мы пошли дальше, попробовав установить клиентскую часть 1С:Предприятие, что не вызвало у нас ни малейших затруднений.

За все время работы в Astra Linux у нас не возникло каких-либо серьезных проблем. По большинству ощущений это все тот же Debain, если вы умеете работать с ним или его производными, то и с Astra проблем не возникнет. Но в тоже время Astra Linux не просто еще один Debian, многие пакеты, такие как SSH, OpenVPN, веб-сервера скомпилированы с поддержкой отечественной криптографии, что важно для определенных сфер применения.

В заключение хочется сказать, что Astra Linux нам понравился. Это хорошая отечественная система с довольно специфичными областями применения, но в тоже время она выглядит очень достойно и в качестве дистрибутива общего назначения. И особенно приятно, что она идет против всех сложившихся стереотипов о российском ПО, представляя пример отличного современного дистрибутива с собственной графической оболочкой и внимательным подходом к мелочам.

Настраиваем роутер NAT + DHCP + Squid3 с поддержкой фильтрации SSL-трафика

сб, 05/25/2019 - 23:15

Решения на базе Squid пользуются заслуженной популярностью у системных администраторов как мощное и гибкое средство контроля за интернет трафиком. Отдельного внимания заслуживают богатые возможности фильтрации, позволяющие ограничить доступ для определенных групп пользователей к нежелательным интернет ресурсам. Широкое внедрение шифрования в последние годы сделало процесс фильтрации несколько затруднительным, но и здесь Squid придет нам на помощь, как это сделать мы расскажем в этой статье.

Данный материал во многом повторяет нашу предыдущую инструкцию Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3, благо никаких принципиальных изменений в процессе настройки с тех пор не произошло. Поэтому мы не будем подробно останавливаться на повторяющихся настройках, а просто приведем необходимые участки конфигурационных файлов с минимальными пояснениями. В нашем случае использовался Debian 9, но данная статья будет справедлива для любого основанного на Debian / Ubuntu дистрибутиве.

Настройка сети

В данном примере у нас будет статическая настройка внешнего сетевого интерфейса, если же вы используете динамические подключение, такие как PPPoE или PPTP, то для их настройки обратитесь к соответствующим инструкциям (по ссылкам).

Для настройки сети откроем файл /etc/network/interfaces:

nano /etc/network/interfaces

И внесем в него следующие изменения (названия интерфейсов и адреса указаны только для примера):

auto ens33
iface ens33 inet static
address 172.18.0.106
netmask 255.255.240.0
gateway 172.18.0.1
dns-nameservers 172.18.0.1

auto ens34
iface ens34 inet static
address 192.168.187.1
netmask 255.255.255.0

post-up /etc/nat

Если внешний интерфейс получает настройки по DHCP, то используйте следующие настройки:

auto ens33
allow-hotplug ens33
iface ens33 inet dhcp

Сразу создадим файл для хранения настроек брандмауэра и сделаем его исполняемым:

touch /etc/nat
chmod +x /etc/nat

Перезапустим сеть:

service networking restart

После чего у вас на сервере должен появиться интернет, сразу следует обновить систему и установить необходимый минимум утилит для администрирования:

apt update
apt upgrade
apt install mc ssh Настройка NAT и брандмауэра

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

Откроем созданный нами файл /etc/nat и внесем в него следующие строки:

#!/bin/sh

# Включаем форвардинг пакетов
echo 1 > /proc/sys/net/ipv4/ip_forward

# Сбрасываем настройки брандмауэра
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

# Разрешаем доступ из локальной сети
iptables -A INPUT -i ens34 -j ACCEPT

# Разрешаем инициированные нами подключения извне
iptables -A INPUT -i ens33 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Разрешаем подключения по SSH
iptables -A INPUT -i ens33 -p tcp --dport 22 -j ACCEPT

#Запрещаем входящие извне
iptables -A INPUT -i ens33 -j DROP

# Разрешаем инициированные нами транзитные подключения извне
iptables -A FORWARD -i ens33 -o ens34 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Запрещаем транзитный трафик извне
iptables -A FORWARD -i ens33 -o ens34 -j DROP

# Включаем маскарадинг для локальной сети
iptables -t nat -A POSTROUTING -o ens33 -s 192.168.187.0/24 -j MASQUERADE

Чтобы применить изменения просто запустим измененный файл:

/etc/nat

Убедиться, что правила применились мы можем командами:

iptables -L -vn
iptables -t nat -L -vn

Если теперь вручную настроить сеть на рабочей станции, указав роутер в качестве шлюза с использованием DNS-сервера провайдера (или публичного), вы должны попасть в интернет.

Настройка DHCP и кеширующего DNS

В наших решениях эту роль обычно исполняет dnsmasq, не будем отступать от традиций и в этот раз. Установим данный пакет:

apt install dnsmasq

Для настройки откроем файл /etc/dnsmasq.conf и внесем некоторые изменения. Прежде всего ограничим адреса, которые будут слушать наши службы:

listen-address=127.0.0.1, 192.168.187.1

Затем зададим пул для выдачи адресов через DHCP и срок аренды:

dhcp-range=192.168.187.120,192.168.187.199,255.255.255.0,12h

Для одноранговой сети будет неплохо указать DNS-суффикс, чтобы избежать сложностей с разрешением плоских имен:

local=/interface31.lab/

Перезапустим службу:

service dnsmasq restart

Теперь проверим получение адреса на клиенте и возможность доступа с него в интернет, если вы не допустили ошибок, то все должно работать.

Просмотреть список выданных в аренду адресов можно командой:

cat /var/lib/misc/dnsmasq.leases Настройка прокси-сервера Squid3 с поддержкой SSL

К сожалению, в репозиториях нет пакета squid с поддержкой SSL, поэтому потребуется собрать его самому, как это сделать мы рассказывали в статье Сборка Squid 3.5 с поддержкой SSL из исходных кодов для Debian / Ubuntu, поэтому будем считать, что вы уже выполнили эту процедуру, либо используете уже собранные нами пакеты.

Будем считать, что собранные пакеты squid скачаны и располагаются в отдельной директории. Перейдем в нее и установим пакеты командой:

dpkg -i squid*.deb

В процессе установки вы получите сообщения о неудовлетворенных зависимостях, поэтому разрешим их командой:

apt install -f

Чтобы наши пакеты не были перезаписаны пакетами из репозитория при обновлении их следует зафиксировать:

apt-mark hold squid
apt-mark hold squid-common
apt-mark hold squidclient

Если у вас был уже установлен squid, то просто удалите его и установите наши пакеты, все настройки при этом будут подхвачены автоматически, хотя на всякий случай сохраните куда-нибудь файл конфигурации:

cp /etc/squid/squid.conf /root/squid.conf.back

Установив пакеты с поддержкой SSL, перейдем к конфигурированию нашего прокси. Для этого откроем файл /etc/squid/squid.conf, все указанные ниже опции надо либо найти и раскомментировать, приведя к указанному виду, либо создать.

Следующий блок, задающий стандартные ACL-элементы присутствует по умолчанию:

acl localnet src 192.168.187.0/24 # RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

В нем мы должны изменить только опцию acl localnet src - указав диапазон собственной локальной сети.

Затем добавим несколько своих списков, прежде всего укажем диапазон адресов офисных ПК, которые мы раздаем по DHCP, это будут основные кандидаты на применение к ним правил фильтрации:

acl office src 192.168.187.120-192.168.187.199

Затем идет элемент со списком значений "черного списка", который хранится в виде regex-выражений в файле /etc/squid/blacklist:

acl blacklist url_regex -i "/etc/squid/blacklist"

В принципе, мы можем использовать общий список для фильтрации HTTP и HTTPS, но лучше будет разделить списки. Во-первых, HTTP позволяет фильтровать по части URL, блокируя не весь сайт, а только некоторые его страницы или разделы. Во-вторых, чем больше список - тем выше нагрузка, а так как сайты редко работают сразу по обоим протоколам, то логично будет иметь свои варианты списков для каждого из них.

Также помните, что фильтровать защищенные соединения мы можем только по имени домена, никакие параметры URL учитываться не будут. Для того, чтобы заблокировать домен часто используют следующее выражение:

vk\.com

Но это заблокирует не только vk.com, но и все сайты с окончанием на vk.com, скажем mvk.com. Чтобы этого избежать, при этом надежно заблокировав домен с поддоменами, следует использовать конструкцию:

^([A-Za-z0-9.-]*\.)?vk\.com

Для проверки созданных вами регулярных выражений мы рекомендуем использовать онлайн-сервис Regex101.

Следующий блок также является стандартным, просто контролируем его наличие:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager

После чего добавим свое правило для фильтрации HTTP-трафика:

http_access deny blacklist office

Которое запретит для всех ПК офиса доступ к ресурсам перечисленным в черном списке. Далее следует стандартный набор списков доступа:

http_access allow localnet
http_access allow localhost
http_access deny all

Это самый простой вариант, но тем не менее достаточный в качестве примера.

Теперь укажем порты для работы с шифрованным и нешифрованным трафиком, для прозрачного режима это должно выглядеть так:

http_port 3128 intercept
https_port 3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squid.pem

Для непрозрачного:

http_port 3128
https_port 3129 ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squid.pem

В параметрах HTTPS-порта задаются рекомендованные опции (ALL) и выключаются небезопасные устаревшие протоколы SSLv2 и SSLv3, также указывается сертификат squid, который мы создадим позже.

Ниже укажем ряд необходимых опций:

always_direct allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

Первая опция указывает направлять весь трафик сразу в интернет, без использования вышестоящих кешей, а последние две разрешают соединение даже с ошибками проверки сертификата, так как окончательно решение о посещении такого ресурса должен осуществлять пользователь, а не сервер.

Зададим черный список для SSL:

acl blacklist_ssl ssl::server_name_regex -i "/etc/squid/blacklist_ssl"

Как было сказано выше, мы будем использовать раздельные списки, данный список будет хранится в файле /etc/squid/blacklist_ssl и также содержать регулярные выражения, описывающие блокируемые домены.

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

acl step1 at_step SslBump1

А теперь укажем, что делать с защищенным трафиком:

ssl_bump peek step1
ssl_bump terminate blacklist_ssl office
ssl_bump splice all

Действие peek "заглядывает" в соединение на указанную нами глубину, terminate блокирует соединения по совпадению условий (черный список + офисный диапазон адресов) и наконец splice разрешает все остальные соединения, не вмешиваясь в них.

Следующая опция также необходима для работы squid с SSL:

sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB

Также обязательно укажем DNS-сервер, который следует использовать squid, он должен обязательно совпадать с DNS-сервером, используемым клиентами, в нашем случае это dnsmasq, в доменной сети следует указать доменные DNS:

dns_nameservers 127.0.0.1

Ниже приведены параметры кеша:

cache_mem 512 MB
maximum_object_size_in_memory 512 KB
memory_replacement_policy lru
cache_dir aufs /var/spool/squid 2048 16 256

И настройка логов:

access_log daemon:/var/log/squid/access.log squid
logfile_rotate 7

В нашем случае используется 7 ротаций (неделя), поэтому установите нужное вам значение.

Сохраняем конфигурационный файл, но не будем пока перезапускать squid, так как у нас отсутствуют некоторое объекты, перечисленные в конфигурации. Прежде всего создадим файл черного списка:

touch /etc/squid/blacklist_ssl

Либо можем скопировать уже существующий:

cp /etc/squid/blacklist /etc/squid/blacklist_ssl

Для примера мы заблокировали две популярные соцсети использовав следующие записи:

^([A-Za-z0-9.-]*\.)?vk\.com
^([A-Za-z0-9.-]*\.)?ok\.ru

Затем создадим сертификат для squid:

openssl req -new -newkey rsa:1024 -days 3650 -nodes -x509 -keyout squid.pem -out squid.pem

Так как он нужен сугубо для прокси и ни на что не влияет, то мы указали срок его действия в 10 лет, что позволит забыть о нем в обозримом будущем (с учетом того, что про него и так забудут).

Вот теперь можем проверить конфигурацию:

squid -k check

Остановим прокси, перестроим кеш (так как мы изменили его параметры) и запустим заново:

service squid stop
squid -z
service squid start

Если вы используете прозрачный режим, то в конец файла /etc/nat добавьте следующие строки:

# Заворачиваем http на прокси
iptables -t nat -A PREROUTING -i ens34 ! -d 192.168.187.0/24 -p tcp --dport 80 -j REDIRECT --to-ports 3128

# Заворачиваем https на прокси
iptables -t nat -A PREROUTING -i ens34 ! -d 192.168.187.0/24 -p tcp --dport 443 -j REDIRECT --to-ports 3129

Для непрозрачного режима следует настроить WPAD, для автоматической настройки параметров прокси на клиентах (прописывать настройки руками в 21 веке дурной тон).

Проверим доступ к запрещенному ресурсу, как видим - все работает:

Ошибка "local IP does not match any domain IP"

Внешне данная ошибка проявляется в том, что squid в прозрачном режиме разрывает соединение с защищенным сайтом, регистрируя ошибку с указанным текстом в лог. Фактически такое поведение squid не является ошибкой, а связано со старой уязвимостью CVE-2009-0801, которая позволяла в прозрачном режиме обходить систему контроля доступа путем изменения HTTP-заголовков.

Коротко суть проблемы состоит в следующем: один и тот же ресурс на клиенте и на сервере разрешается в разные IP-адреса, этому в основном подвержены крупные ресурсы, имеющие несколько адресов для одного домена, а также сайты, использующие различные CDN (например, CloudFlare). Для squid такая ситуация равносильна попытке подмены заголовка, и он разрывает соединение.

Некоторые инструкции в сети советуют при сборке наложить патч client_side_request.patch, который по сути вернет уязвимость обратно. Заявления автора патча, что он не несет угрозы безопасности с отсылкой к одному из разработчиков squid не совсем верно отражают суть проблемы. Действительно, данная уязвимость никак не отражается на безопасности самого прокси-сервера, она позволяет клиентам, при определенных условиях, обойти его систему контроля доступа.

Как избежать данной ситуации? Использовать общий DNS-сервер как для клиента, так для прокси-сервера, мы обращали на это ваше внимание при описании соответствующей опции. Но не все так просто, ситуацию осложняет локальный DNS-кеш, который присутствует на любом клиенте и может содержать иную запись, нежели локальный кеш сервера. И добиться полной синхронизации кешей будет довольно сложно.

Однако данная проблема встречается не так часто, поэтому вполне будет достаточно очистить клиентский кеш и начать использовать общий DNS-сервер, но 100% гарантией избавления от проблемы это не будет.

Как решить вопрос окончательно? Ответ прост: не использовать прозрачный режим. Если трезво глянуть на ситуацию, то его достоинства по большей части преувеличены, у прозрачного прокси нет никаких существенных преимуществ, кроме простоты настройки. Протокол WPAD не только позволяет автоматически настраивать параметры прокси на клиентах, но и предоставляет большую гибкость в определении того, какой трафик пускать через прокси, а какой напрямую, прост во внедрении и поддерживается всеми типами клиентов.

Надеемся, что данная статья окажется вам полезна и поможет начать эффективно фильтровать защищенные соединения при помощи прокси-сервера squid.

Расширенная настройка DNS и DHCP в роутерах Mikrotik

пн, 05/20/2019 - 00:55

Со службами DHCP и DNS знакомы, пожалуй все, ведь это базовые службы для сетей любого размера. Но их настройка обычно сводится к установке базовых параметров и затем о них забывают. Действительно, ну что может быть в них интересного, особенно если это неполноценные сервера, а службы роутера. Это так, если говорить о бытовых роутерах, где пользователю стараются не давать в руки лишних инструментов, но RouterOS рассчитана на иную аудиторию и предоставляет широкий спектр возможностей, которыми глупо не воспользоваться.

DNS (Domain Name System)

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

Как работает система DNS мы рассказывали в одной из наших статей, рекомендуем ее к прочтению, особенно если вы не до конца разбираетесь в вопросе. Основное, на что нужно обратить внимание - это иерархичность системы. Данные зон хранятся на собственных серверах и для получения информации из них следует прибегать к рекурсии. Это достаточно затратный процесс, поэтому многие сервера кешируют запросы и отвечают на повторные обращения самостоятельно.

Скорость ответа на DNS-запрос очень важна для комфортного использования интернета. Внешне это может проявляться как "задумчивость" браузера, который некоторое время "думает", а только потом начинает грузить страницу. При этом сама скорость канала может быть высокой, а пинг к требуемому серверу небольшим. Неопытного админа такая ситуация может сильно озадачить, но все просто - это долго отвечает используемый DNS-сервер. Ведь прежде, чем начать взаимодействие с сервером, браузер должен получить от DNS-клиента его адрес, передав последнему доменное имя.

Mikrotik дает нам возможность использовать кеширующий DNS-сервер прямо на роутере и если вы настроили использование роутера в качестве DNS - то вы его уже используете. Еще раз перейдем в IP - DNS и внимательно посмотрим на настройки:

В самом низу расположены настройки кеша: его размер (Cache Size) и максимальное время хранения записей (Cache Max TTL). Еще ниже располагается показатель использования кеша - Cache Used - который показывает его текущий размер. Если он начинает приближаться к размеру кеша, то последний следует увеличить. Просмотреть кеш можно нажав на кнопку Cache.

Глядя на значение TTL, можно подумать, что это очень много, целая неделя. Но это - максимальное время хранения записи, реальное время хранения определяется временем TTL в SOA-записи домена, причем Mikrotik использует минимальное значение - Minimum TTL. В этом несложно убедиться, мы очистили кеш и посетили один из своих сайтов, минимальный TTL которого равен 4 часам:

Как видим, Mikrotik использовал значение TTL из SOA-записей, ни о каких 7 днях речи не идет. Тогда для чего нужна эта настройка? Вы можете обновлять кеш чаще, чем это указано в TTL-домена. Если значение максимального TTL Mikrotik будет меньше, чем указанное в SOA-домена, то будет использоваться именно оно.

Это может быть полезным, если вы внесли какие-либо изменения во внешнюю зону и желаете быстрее обновить кеш. Как показывает практика, публичные сервера, такие как Google, OpenDNS или Яндекс тоже часто игнорируют TTL из SOA и обновляют свой кеш чаще.

Очистить кеш можно кнопкой Flush Cache в окне Cache или командой в терминале:

ip dns cache flush

Но это еще не всё, изучение кеша может быть полезным для изучения сетевой активности пользователей, если они используют в качестве DNS ваш роутер - то вся их сетевая активность отразится в кеше. Говорите, никто не сидит в соцсетях?

Поэтому, если у вас нет иных инструментов логирования и статистики, то изучение записей кеша вполне позволит получить картину сетевой активности ваших пользователей.

На этом закончим с кешем и перейдем к другому разделу - Static. Он позволяет создавать нам собственные записи типа A (и больше ничего кроме них). Не густо, но основную часть потребностей это перекрывает. Перенесли сайт на новый сервер? Не нужно ждать пока обновятся DNS-записи, заходим в раздел Static и создаем собственную запись:

Проверим, как это работает. Выполним разрешение имени на клиенте:

Как видим - все работает отлично.

Отдельный разговор - плоские имена. В одноранговой сети часто бывает нужно указать имя узла, который не поддерживает NetBIOS, скажем ноду Hyper-V Server или машину с Linuх. Аналогично создаем запись:

Но имейте ввиду, работать такое разрешение имен будет только на Windows машинах, на Linux вы получите ошибку:

Но так как большинство сетей имеет преимущественно Windows ПК, то особых проблем плоские имена не доставят, и вы можете смело добавлять их записи на DNS Mikrotik вместо того, чтобы прописывать в hosts на каждой машине.

Так так, скажет внимательный читатель, это же можно использовать для блокировки нежелательных ресурсов и будет прав. Если мы не хотим, чтобы пользователи сидели в соцсетях, то добавим на сервер записи, который будут разрешать такие запросы в 127.0.0.1:

Проверим?

Вроде бы работает, но недостаток такого метода, что мы заблокировали только основной домен и пользователь легко сможет зайти через мобильный поддомен:

Чтобы этого избежать следует использовать регулярные выражения. К сожалению, в большинстве инструкций в интернете приводятся неправильные выражения, с которыми фильтр работать не будет, поэтому мы советуем использовать для создания и проверки регулярных выражений ресурс regex101.com. Это избавит вас от ошибок и вопросов в стиле "я сделал все как написано в статье, но ничего не работает".

Скажем, чтобы заблокировать домен vk.com со всеми поддоменами, но при этом не затронуть иные домены, которые могут заканчиваться на vk.com нам потребуется выражение:

\.?vk\.com

Внесем его в соответствующее поле Mikrotik:

И проверим, теперь любое, даже заведомо не существующее имя в домене vk.com будет разрешаться в 127.0.0.1, что нам и требовалось.

Но в небольших сетях, где пользователи имеют достаточно прав, всю эту идиллию можно быстро перечеркнуть, вручную прописав собственные DNS. Как с этим бороться? Решение в лоб - заблокировать прохождение DNS-запросов в цепочке FORWARD, но тогда у "продвинутого" пользователя вообще перестанет работать интернет, поэтому мы поступим по-другому.

Откроем IP - Firewall - NAT и добавим правило: Chain: dstnat, protocol: udp, Dst. Port: 53 и на закладке Action выберем действие redirect.

Потом создаем точно такое же правило для протокола tcp. Эти же самые действия можно быстро выполнить в терминале:

ip firewall nat
add chain=dstnat protocol=udp dst-port=53 action=redirect
add chain=dstnat protocol=tcp dst-port=53 action=redirect

Теперь любые DNS-запросы от пользователей сети будут перенаправляться на наш DNS-сервер на роутере, что сделает любые попытки обойти локальный DNS бессмысленными.

Как видим, DNS-сервер роутера Mikrotik, несмотря на кажущуюся простоту, в общем не так уж и прост и дает в руки администратора достаточно широкие возможности.

DHCP (Dynamic Host Configuration Protocol)

Когда речь заходит о DHCP, то обычно имеют ввиду автоматическое присвоение сетевых параметров, таких как IP-адрес, маска, шлюз и DNS-сервера. Но на самом деле возможности протокола намного шире и позволяют настроить очень многие сетевые параметры. Все возможности протокола описаны в RFC 2132, но мы не будем забираться столь глубоко, а рассмотрим в качестве примера только несколько наиболее популярных опций.

Прежде всего это Option 15 (DNS Domain Name) - которая позволяет автоматически настроить DNS-суффикс подключения, что позволяет снять определенный ряд проблем, связанный с использованием плоских имен.

Чтобы создать любую DHCP опцию потребуется перейти в IP - DHCP Server - Options и добавить там новую запись:

Поле Name содержит имя опции, можем задать его произвольно, так чтобы нам потом было понятно, что это такое и для чего нужно. Code - код опции, в нашем случае 15, Value - значение, в нашем случае это строка, поэтому обрамляем ее одиночной кавычкой. Тоже самое можно быстро сделать в терминале:

ip dhcp-server option
add name="DNS Suffix" code=15 value="'interface31.lab'"

Обратите внимание, что значение value берется в кавычки два раза, в двойные и одинарные.

Опции можно (и нужно) объединять в наборы - Option Set, даже несмотря на то, что во многих сценариях их можно указывать непосредственно. Если в будущем вы надумаете что-то поменять, то достаточно будет просто изменить состав набора, в противном случае вам нужно будет вспомнить все места, где вы использовали некую опцию и заменить ее на новую (или удалить / добавить). Перейдем на одноименную закладку и создадим новый набор. Пока в него будет входить только одна опция:

Наборам желательно давать осмысленные названия, чтобы впоследствии вы легко могли понять для чего он предназначен. Теперь назначим его для применения на всю область DHCP-сервера. Перейдем на закладку DHCP и откроем запись нашего сервера, в поле DHCP Option Set укажем имя созданного нами набора.

Теперь обновим параметры DHCP и сразу увидим полученный DNS-суффикс:

После этого все плоские имена, которые вы добавили на DNS-сервер следует дополнить до FQDN, т.е. вместо HV-CORE-01 написать hv-core-01.interface31.lab (регистр записи значение не имеет).

Проверим:

Как видим, одной проблемой стало меньше, плоские имена нормально дополняются до FQDN и нормально разрешаются на нашем DNS вне зависимости от используемой ОС.

Также довольно часто используются опции: 42 (NTP Servers), 60, 66 (TFTP Server Name), 67 (Bootfile-Name). Имейте ввиду, что ОС Windows не запрашивает у DHCP-сервера опцию 42 и для нее установить таким образом сервер времени не удастся.

Отдельно коснемся того, как указывать IP-адреса. Протокол предусматривает передачу значений в шестнадцатеричном (Hex) формате, но RouterOS позволяет использовать и строковые значение, для этого значение Value должно содержать привычное написание адреса, взятое в одинарные кавычки:

'192.168.186.1'

или его шестнадцатеричное значение, которое должно начинаться с префикса 0х:

0xc0a8ba01

Если адресов несколько, то указываем каждый, взяв в одинарные кавычки, без пробелов между ними:

'192.168.186.1''192.168.186.2'

В шестнадцатеричном виде мы добавляем второе значение в конец строки, также без пробелов:

0xc0a8ba01c0a8ba02

В терминале это будет выглядеть так:

ip dhcp-server option
add name="NTP1" code=42 value="'192.168.186.1'"

или

add name="NTP1" code=42 value="0xc0a8ba01"

Для перевода значений IP-адреса в шестнадцатеричное значение, можно использовать любой онлайн-калькулятор, мы при подготовке данного материала использовали этот.

Еще одна интересная возможность открывается в выдаче отдельным узлам своего набора опций. Следующий сценарий подойдет домашним пользователям, как достаточно простой и эффективный способ обеспечить безопасность ребенка в интернет.

Суть ее состоит в следующем: мы выборочно изменяем DNS-сервера детских сетевых устройств на безопасные DNS, например, Яндекс Семейный, SkyDNS, AdGuard и т.д. Тем, кто захочет реализовать этот сценарий в сети предприятия следует иметь ввиду, что в этом случае таким клиентам будут недоступны возможности собственного DNS-сервера, т.е. все то, о чем мы говорили в первой части статьи.

Итак, сначала создадим новую DHCP опцию с кодом 6 и укажем в значении сервера Яндекс Семейного:

ip dhcp-server option
add name="YandexDNS" code=6 value="'77.88.8.7''77.88.8.3'"

или

add name="YandexDNS" code=6 value="0x4d5808034d580807"

Теперь создадим новый набор опций и добавим туда опцию YandexDNS.

Теперь перейдем на закладку Leases, где находится список выданных в аренду адресов и найдем там детское устройство, после чего откроем запись и выполним резервирование адреса, нажав Make Static:

Закроем и заново откроем эту запись и в поле DHCP Option Set укажем созданный нами набор с безопасными серверами:

Теперь проверим на клиенте, какие DNS-сервера он получил:

Все верно, это семейные сервера Яндекса. Попробуем посетить какой-нибудь сайт "для взрослых":

Отлично, фильтрация работает, теперь можно гораздо меньше переживать, что ребенок увидит неподобающий контент, в тоже время взрослые члены семьи могут использовать интернет без ограничений.

В прошлой части статьи мы рассказывали, как предотвратить подмену DNS на клиентском ПК, данное решение совместно с этими правилами работать не будет. Можно, конечно, добавить исключение, но мы подойдем с другой стороны. Наша основная цель в этом сценарии - это оградить ребенка от посещения ненадлежащих ресурсов, поэтому при попытке подмены DNS мы должны направлять все запросы не на роутер, а на безопасные DNS, в противном случае попытка обхода фильтрации достигнет своей цели.

Поэтому заменим в правилах действие redirect на действие dst-nat, в поле To Addresses указываем один из серверов семейного Яндекса, а в поле To Ports - порт 53.

Также можно быстро добавить нужные правила командой:

ip firewall nat
add chain=dstnat protocol=udp dst-port=53 action=dst-nat to-addresses=77.88.8.7 to-ports=53
add chain=dstnat protocol=tcp dst-port=53 action=dst-nat to-addresses=77.88.8.7 to-ports=53

Напоследок рассмотрим опции 121 (Classless Static Routes) и 249 (MS Routes), которые предназначены для передачи статических маршрутов. Первая опция предусмотрена RFC 2132, вторая является "художественной самодеятельностью" Microsoft, поэтому следует указывать обе из них с одинаковым содержимым.

Во избежание ошибок мы советуем задавать маршруты в HEX-формате, синтаксис предусмотрен следующий:

[маска сети назначения][сеть назначения][шлюз]

Если маршрутов несколько - добавляем значения к конец строки, без пробелов. Допустим, мы хотим добавить маршрут в сеть 192.168.4.0/22 через 192.168.186.92 и в сеть 10.8.0.0/24 через 192.168.186.94. Чтобы правильно получить шестнадцатеричное значение маски следует использовать такое представление: 0.0.0.22 или 0.0.0.24, забьем все значения в онлайн калькулятор и получим:

А вот теперь начнется небольшая магия, прежде всего обратим внимание на то, что количество символов в шестнадцатеричном числе всегда должно быть четным, но в строке, соответствующей 10.8.0.0 - нечетное количество символов, так как калькулятор отбросил ведущий ноль, поэтому вместо a080000 мы должны использовать 0a08000. Имеем это ввиду, так как разные калькуляторы могут по-разному обрабатывать ведущий ноль.

Затем от адреса сети, мы должны отбросить столько нулевых октетов, сколько нулей содержится в маске, в HEX-значении это по два нуля. Проще говоря для сетей /24 - /17 мы должны убрать в HEX-значении сзади два нуля, для сетей /16 - /9 - четыре нуля, для сетей /8 - /1 - шесть нулей. Таким образом 0a08000 должно превратиться в 0a0800, а c0a80400 в c0a804.

Таким образом первый маршрут должен выглядеть так:

16c0a804c0a8ba5c

а второй так:

180a0800c0a8ba5e

Итоговое значение будет (не забываем про 0x вначале):

0x16c0a804c0a8ba5c180a0800c0a8ba5e

Добавим опции командами:

ip dhcp-server option
add name="my route" code=121 value="0x16c0a804c0a8ba5c180a0800c0a8ba5e"
add name="my win route" code=249 value="0x16c0a804c0a8ba5c180a0800c0a8ba5e"

или через графический интерфейс:

Обновим параметры DHCP и проверим таблицы маршрутизации на клиентах. Windows-клиент:

Linux-клиент:

Как видим - все работает, маршруты добавились и еще одной заботой у администратора стало меньше.

В заключение хочется добавить, что данная статья не должна рассматриваться вами как догма, все пункты которой требуется обязательно применить. Данный материал имеет цель показать те скрытые возможности привычных сервисов, которые обычно не затрагиваются в руководствах по базовой настройке. После чего уже сам администратор должен решать, что он будет применять в своей сети и зачем. К сожалению, объем статьи не позволяет нам охватить все возможности DHCP, что-то из них мы отразим в будущих статьях, а что-то вам придется изучать самостоятельно. Но надеемся, что данный материал окажется вам полезен и даст дополнительный стимул к изучению всех возможностей используемых протоколов.

Microsoft: будущее Windows в Linux

сб, 05/18/2019 - 00:48

Представляем вашему вниманию очередной перевод зарубежной прессы сделанный нашим немецким коллегой. На этот раз затронута достаточно интересная тема: взаимодействие компании Microsoft с Linux и открытым ПО. Несмотря на то, что многие утверждения автора носят полемический характер, мы считаем, что статья будет представлять интерес для русскоязычной аудитории. К тому же хороший технический специалист должен иметь широкий кругозор, представление о тенденциях развития отрасли и перспективах. А в этих вопросах обычно нет общего мнения, но это и к лучшему, ведь в споре рождается истина.

Собственная ОС не так и важна -- фирма делает ставку на open source (ПО с открытым исходным кодом)

Перемены в компании Microsoft в последние годы весьма впечатляют. Вместо ненависти к Linux, фирма перешла к активной разработке программного обеспечения с открытым кодом. Уже позабыты те боевые времена, когда руководитель Microsoft Стив Баллмер обзывал свободную ОС то «раковой опухолью», то «коммунистической системой». С тех пор, как у руля предприятия стал Сатья Наделла, здесь стали ценить преимущества свободного ПО.

Теперь Microsoft Linux?

Интересная идея. Станет ли компания Microsoft сама предлагать линукс в качестве ОС для персональных компьютеров? Вроде дурацкий вопрос, но если посмотреть тенденции последних лет, то такие мысли вполне могут прийти в голову.

Уже заметна уменьшающаяся роль Windows в стратегии Microsoft. Сейчас фирма растёт за счёт предоставления сервисов Office 365 и облачных служб Azure. И там и тут вполне можно обойтись без Windows. Где пользователи будут применять программы из пакета Office: на компьютерах с Windows или планшетах с Android - Microsoft как-то безразлично. А уж в облаках Azure и вовсе доминируют Linux-системы.

Стив Баллмер такого не ожидал

Утрата бизнес-модели

Ко всему прочему стоимость, которую сегодня можно взять за ОС с частных клиентов уверенно стремится к нулю. Google и Apple позаботились об этом, и получают деньги на разработку софта из других источников. Это дошло и до Microsoft, вот уже и новая «десятка» фактически раздавалась даром. Ну а попытка заработать немного денег на рекламе прямо в Windows -- это говорит, скорее, о внутренних метаниях, потому этот способ годится только чтобы разогнать своих клиентов в то время, когда значение ОС для пользователя постоянно снижается.

Бизнес не пропадёт

Не стоит заблуждаться, бизнес Microsoft по продаже лицензий ещё годами будет приносить компании прибыль. Хотя-бы на том основании, что позиции Windows достаточно сильны в компаниях и госучреждениях. Однако уже достаточно хорошо проглядывается будущее, где ОС перестает играть ту значительную роль, которую ей уделяли ранее.

Куда ни глянь -- везде Linux

Чтобы увидеть куда идёт Microsoft, тому достаточно обратить внимание на самую растущее подразделение фирмы: облачные службы. Именно там Microsoft давно приспособилась к реальности. Вместо бессмысленной борьбы с Linux, принята стратегия поддержки этой ОС. Мало того, весной 2019 года вышла собственная система на Linux-ядре - Azure Sphere и уже вполне можно представить направление дальнейших разработок в этой отрасли.

Примечание переводчика: немного ранее Microsoft впервые выпустил Linux-версию одного из ключевых корпоративных продуктов - SQL Server 2017.

Следующий логичный шаг - серверная ОС на основе Linux. Это проверенное временем серверное решение сечас становится стандартной основой для облачных служб. В тоже время Linux для персональных компьютеров вряд ли будет входить в список приоритетов Microsoft, по причине снижающейся значимости ОС в этой области.

Растут шансы, что Microsoft озадачится покупкой какого-нибудь крупного разработчика ОС на основе Linux. IBM только что купил Red Hat, что мешает Microsoft заинтересоваться Ubuntu или SUSE?

Ну а пока что Microsoft углубляет личную заинтересованность в работе с Linux, второй выпуск подсистемы Linux для Windows будет включать полное ядро. Следовательно потребность Microsoft в технологиях Linux только продолжает расти.

Всё больше открытого ПО

Даже если в Редмонде и не создадут свой Linux, то нет никаких сомнений в том, что открытый исходный код будет играть решающую роль в будущем Microsoft. К чему идёт дело стало ясно после покупки Microsoft самой важной в мире платформы для разработчиков свободного программного обеспечения Github. Но и на настольном компьютере свободное ПО начинает выходить на центральные позиции: браузер Edge переходит на основу свободного движка Chromium.

Становится очевидно: Microsoft будет применять открытое ПО везде, где это будет иметь стратегическое или коммерческое значение. Урок от Google был хорошо усвоен. Свободное ПО служит транспортом для передачи коммерческих программ, за счет которых и образуется прибыль.

С этой точки зрения закрывать платформу ОС будет нерационально. Именно там, где нет прямого финансового интереса, сотрудничество с другими разработчиками приносит больше выгоды, чем владение собственной операционной системой. Вполне вероятно, что Microsoft понемногу сделает открытым код своей Windows, если, конечно, приведёт накопившийся за десятилетия код в презентабельный вид.

Linux выигрывает

Проще говоря: Microsoft все больше живет в мире Linux. То, что раньше выглядело для производителя Windows как явная угроза, сегодня стало реальностью, в которой фирма может чувствовать себя вполне хорошо.

Автор: Andreas Proschofsky

Источник: Microsoft: Linux ist die Zukunft des Windows-Herstellers

Перевод: Виктор Хартманн, Берлин.

Страницы