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

Сказка о прилегшем Честном знаке

- Здравствуйте, продайте мне хлеба и молока.

- Здравствуйте, хлеб берите, а молока не дадим, Честный знак не работает!

- Ну минералки тогда…

- И минералки тоже не дадим!

- Сока или квасу?

- Они тоже в Честном знаке, не дадим!

- Ну ладно, пива!

- И пиво тоже!

- И безалкогольное?

- И безалкогольное!

- А…

- А еще масла намазать на хлеб мы вам тоже не дадим, ни сливочного, ни подсолнечного!

- Так что же мне, сухой хлеб жевать?

- Именно так, сыра тоже не дадим, творога и кефира тоже, даже не смотрите туда!

- Вот блин!

- Водки возьмите, она через ЕГАИС, он сегодня работает.

- Ну как бы завтра работать еще…

- Ну тогда жуйте хлеб без водки.

- Ладно, уговорили, давайте! Запить бы чем…

- Все напитки в Честном знаке, кильки тоже не дадим, не тяните руки, она промаркирована!

- О, колбаска, она без маркировки!

- ВетИС уже неделю лежит, не будет вам колбаски!

- Ладно, давайте хлеб и водку!

- Водки тоже не дадим! Пока вы думали, ЕГАИС прилег!

​​Подборка публикаций на тему VPN 2

🔶 Mikrotik

🔹 Настройка OpenVPN-сервера на роутерах Mikrotik в RouterOS 6
🔹 Настройка OpenVPN-сервера на роутерах Mikrotik в RouterOS 7
🔹 Настройка WireGuard VPN на роутерах Mikrotik
🔹Настраиваем IPsec-туннель между офисами на оборудовании Mikrotik
🔹 Настройка туннелей GRE и IPIP на роутерах Mikrotik
🔹 Настройка SSTP VPN-сервера на роутерах Mikrotik
🔹 Настройка PPTP или L2TP VPN-сервера на роутерах Mikrotik
🔹 Настраиваем IKEv2 VPN-сервер на роутерах Mikrotik с аутентификацией по сертификатам
🔹 Настройка VPN-подключения на роутерах Mikrotik если подсети клиента и офиса совпадают
🔹 Настройка Proxy ARP для VPN-подключений на роутерах Mikrotik

🔶 Общие вопросы, теория

🔹 Настраиваем VPN. Часть 1 - Общие вопросы
🔹 Настраиваем VPN. Часть 2 - Cтруктура сети
🔹 Организация VPN каналов между офисами. Маршрутизация

🔶 OpenVPN дополнительно

🔹 Создание ключей и сертификатов для OpenVPN при помощи Easy-RSA 3
🔹 Почему тормозит OpenVPN? Размер буферов приема и отправки
🔹 OpenVPN и инфраструктура открытых ключей (PKI)
🔹 OpenVPN объединяем ключи и конфигурацию клиента в один файл
🔹 Отзыв сертификатов пользователей в OpenVPN

🔶 WireGuard дополнительно

🔹 Создаем готовые клиентские конфигурации для WireGuard

​​Подборка публикаций на тему VPN

🔶 Windows

🔹 Организация каналов между офисами при помощи OpenVPN с дополнительной парольной защитой
🔹 Как настроить несколько одновременных OpenVPN подключений в Windows
🔹 Настраиваем PPTP или L2TP VPN-сервер при помощи RRAS в Windows Server
🔹 Автоматическое добавление маршрутов для VPN-соединения в Windows
🔹 Управляем VPN-соединениями в Windows при помощи PowerShell

🔶 Linux

🔹 Организация каналов между офисами при помощи OpenVPN на платформе Linux
🔹 Настройка OpenVPN-сервера для доступа в интернет
🔹 Настройка двух и более OpenVPN-серверов на одном сервере
🔹 Настраиваем L2TP VPN-сервер на платформе Linux (Debian / Ubuntu)
🔹 Настройка туннелей GRE и IPIP в Debian и Ubuntu
🔹 Организация каналов между офисами через WireGuard VPN на платформе Linux
🔹 Настройка WireGuard VPN для доступа в интернет
🔹 Настраиваем OpenConnect - совместимый с Cisco AnyConnect VPN сервер на платформе Linux
🔹 Установка и настройка Рутокен VPN Community Edition

🔶 Не VPN, но тоже полезно

🔹 SSH-туннели на службе системного администратора
🔹 Защищаем сетевые службы при помощи stunnel

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

​​Про крутые госы

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

Ну да «по плодам их узнаете их», из этого и будем исходить. А ходить нам далеко не придется:

👉 17.06.2025 в 22:00 Федеральная государственная информационная система в области ветеринарии (ФГИС «ВетИС») подверглась вирусной атаке, в следствие чего 18.06.2025 в 00:30 переведена в аварийный режим работы.

По текущей оценке, работы по восстановлению будут проводиться до 23.06.2025, компоненты ФГИС «ВетИС» будут вводиться в эксплуатацию по мере их готовности с 19.06.2025.

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

Кластера, горячий резерв, бекапы? Нет, не слышали. Кто-то подал заявление об отставке? Кого-то уволили? Начали проверки? Нет, не слышали. И не услышим.

А производители по стране несут вполне реальные, ощутимые убытки, так как продукция скоропортящаяся.

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

А остатки лежат, а сроки идут.

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

❗️ Честный знак – еще одна «крутая» система, которая тоже любит взять и прилечь, но в Честном знаке твердо знают первое правило госа – не важно, как оно на самом деле, важно красиво отчитаться.

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

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

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

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

Кто-то хоть раз признался? Извинился? Кого-то уволили? Провели проверку? Нет, не слышали.

В начале 20 чисел мая у розничных продавцов массово начали выбывать из оборота кеги сразу после перовой продажи. Т.е. открыли кегу на 30 литров, 1,5 литра продали. Кег выбыл. Официально его больше продавать нельзя, только вылить.

В отрасли серьезная проблема, Честный знак хранил молчание до 29 числа, когда наконец признался:

🤷‍♀️ В период с 21.05 по 22.05 была включена проверка на указанное значение в теге "ProductStatus" (2110) в чеках ... На текущий момент проверка была отключена и по новым кегах проблема воспроизводиться не будет.

Кому-то стало легче? Нет. А как быть с выбывшими кегами?

💁При необходимости быстрой корректировки кодов идентификации (выбывших из оборота), просьба сформировать официальный запрос на комиссию

И далее целое полотно о том, как этот запрос формировать, что туда включать, кем подписывать и куда подавать.

Только вся соль ситуации в том, что открытое пиво к 29 числу или было продано в обход Честного знака или прокисло.

По факту добросовестные пользователи Честного знака понесли убыток. Кто-то что-то компенсировал? Или хотя бы заикнулся? Кого-то наказали? Уволили? Хотя бы извинились? Нет, не слышали.

И не услышим. Потому что это госы, у них все хорошо. А если нехорошо, то все равно сами вы дураки. А мы снова красиво отчитаемся и снова у нас будет все хорошо.

​​Кадры решают все. Продолжение

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

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

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

Как быть в такой ситуации соискателю? А тут надо честно решить, что вам надо. Пересидеть несколько месяцев – устройтесь таксистом или курьером, не создавайте лишних сложностей ни себе, ни людям.

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

3️⃣ Напишу все что знаю. Я долго затруднялся подобрать заголовок к этому пункту, поэтому пусть будет такой. Резюме таких товарищей больше напоминают оглавление какого-нибудь справочника или список аббревиатур.

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

Подобные резюме вызывают только недоумение. К чему это все? Особенно применительно к текущей вакансии. И что именно хочет сказать этим соискатель? Что он, хотя бы на базовом уровне знает все вышеперечисленное? Так это не сложно выяснить на собеседовании, и я уверен, что 99,9% написавших это такую проверку не пройдут.

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

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

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

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

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

4️⃣ Возраст. Тема очень больная и очень остро воспринимаемая соискателями. Для многих вакансий возраст имеет не меньшее значение чем иные, сугубо профессиональные качества.

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

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

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

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

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

Продолжение следует...

​​Из пункта A в пункт Б

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

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

Но прежде посмотрим на схему внизу материала. Где:

🔹 A и F – конечные устройства в разных сетях
🔹 B и E – внутренние интерфейсы VPN-серверов (роутеры)
🔹 С и D – стороны туннеля
🔹 X и Y – внешние адреса серверов

Итак, наша задача попасть из пункта A в пункт F и для начала мы посмотрим, как должна выглядеть правильная трассировка. Нам должны ответить по очереди следующие узлы:

1️⃣ B

2️⃣ D

3️⃣ F

И никакие другие. Почему? Потому что пакет по дороге совершает три прыжка: от компьютера-источника A на VPN-сервер B, с него на противоположный конец туннеля – D и оттуда в пункт назначения F, интерфейсы С и E в передаче пакета не участвуют (точнее используются только как интерфейсы выхода).

Если у вас в трассировке появились другие узлы – следовательно вы неправильно настроили маршрутизацию.

Теперь начнем диагностику. Если наша трассировка не доходит даже до первого промежуточного узла B, то берем ping и проверяем его доступность. Если он недоступен – то тут все понятно.

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

В этом случае следует прописать маршрут к удаленной сети через узел B либо непосредственно на узле А, либо на основном шлюзе сети.

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

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

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

Интерфейс поднят и отвечает. Отлично. Теперь самое время разобраться в типе нашего VPN-подключения. Соединения на основе PPP, OpenVPN или AnyConnect строятся по клиент-серверной схеме.

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

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

Если мы сами сервер – то в первую очередь проверяем подключен ли к нам клиент со стороны D, далее точно также – маршруты и брандмауэр.

Другое дело stateless туннели, это GRE, IP-IP и WireGuard. Они ничего не знают о состоянии другой стороны и всегда подняты. В этом случае проверяем доступность узла противоположной стороны – Y, проверяем параметры туннеля с обоих сторон, правильность настроек.

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

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

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

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

​​Кадры решают все

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

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

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

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

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

1️⃣ Госы. Таких соискателей, надо сказать, много. Идут с аналогичных должностей из различных МУП, ГУП, администраций, учебных заведении и т.д. и т.п. Такие резюме сразу в мусорку. Ну разве что там будет молодой парень с первым и единственным местом работы, ну и тот станет в самый конец очереди.

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

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

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

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

Что делать? Для начала понять и принять, что гос – для большинства работодателей черная метка. А там решайте, готовы ли вы что-то менять, причем менять радикально, или лучше спокойно досидеть, где сидится.

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

2️⃣ Оверквалификация. Таких резюме поменьше, но тоже хватает, и кого там только нет, чуть ли не кандидаты наук. Бывшие инженеры, программисты, руководители направлений и отделов. Послужные списки многих впечатляют.

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

🐏 Вариант 1. Соискатель на самом деле туп как бревно, а все эти регалии приписаны по принципу «рядом стоял, через плечо глядел». Либо просиживал стул на руководящей должности, а работали подчиненные.

После чего следует закономерный вывод – а нафига он тут такой красивый нужен? Даже если его квалификации и хватает для закрытия вакансии в коллективе он явно не уживется, к месту и не к месту напоминая «кем был Паниковский до Революции».

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

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

Поэтому снова нет, вне зависимости от вариантов.

👉 Продолжение следует...

​​Вернемся к вчерашнему вопросу про OpenVPN и два маршрута.

Правильный ответ: препятствует переопределению нулевого маршрута

Почему так? Давайте разбираться. Пример таблицы маршрутов с активным OpenVPN соединением показан на рисунке ниже.

Сразу же в очередной раз вспоминаем, как идет поиск маршрута в таблице:

1️⃣ Сначала ищется маршрут к узлу назначения с самой узкой маской

2️⃣Затем определяется интерфейс выхода среди непосредственно присоединенных сетей, который позволяет достичь указанного в маршруте шлюза.

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

Теперь давайте смотреть: прежде всего обратим внимание на маршрут xx.xx.254.75/32 который указывает на сам OpenVPN сервер через основной шлюз. Так как это наиболее узкая из всех возможных масок, то поиск маршрута на этом прекращается и пакет к серверу уходит через основное подключение.

Затем у нас есть два маршрута к непосредственно присоединенным сетям 10.8.0.0/24 и 192.168.0.0/24. Эти маршруты обеспечат правильное направление пакетов для локальной сети и внутренней сети VPN.

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

В результате будет найдет один из двух маршрутов 0.0.0.0/1 или 128.0.0.0/1, которые делят пополам все доступное адресное пространство. И по совокупности представляют собой нулевой маршрут, куда будет уходить весь трафик, для которого не будет найдено отдельного маршрута.

А так как маска /1 уже маски /0, то поиск никогда не дойдет до маршрута 0.0.0.0/0, поэтому ответ «сохраняет для клиента нулевой маршрут» неверен.

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

Основной недостаток такого подхода – это переопределение нулевого маршрута другим подключением. Например, вы присоединили 4G модем, переподключились к другой беспроводной сети или подключили еще один VPN.

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

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

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

​​Свет мой зеркальце, скажи…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А нет ТЗ – результат ХЗ, это давно известно и полностью применимо к поиску при помощи нейросетей. Вы никогда не узнаете сказала ли вам сетка правду или что-то от себя добавила.

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

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

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

Почему OpenVPN при указании шлюза в VPN-сети (опция redirect-gateway) вместо нулевого маршрута добавляет два:

0.0.0.0/1 via ovpn
128.0.0.1/1 via ovpn

Для чего это сделано и что это дает?

👇👇👇 Ответы в опросе ниже

​​Сканируем сеть при помощи PowerShell

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

Думаю, все знают командлет Test-NetConnection, который позволяет проверить открытый TCP порт, например:

Test-NetConnection srv-01 -Port 443

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

Test-NetConnection srv-01 -Port 443 -InformationLevel "Quiet"

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

foreach ($ip in 1..254) {Test-NetConnection -Port 443 -InformationLevel "Detailed" 192.168.0.$ip}

Который просканирует адреса с 1 по 254 и выдаст подробный вывод по каждому узлу. Работает не быстро, но свою работу делает. Если нужно просто знать открыт порт или закрыт, то меняем

-InformationLevel "Detailed"

на

-InformationLevel "Quiet"

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

Не было печали – апдейтов накачали. Июньский вторник патчей

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

🔹 CVE-2025-33053— уязвимость удаленного выполнения кода в WEBDAV

🔹 CVE-2025-33073 — уязвимость повышения привилегий в SMB-клиенте Windows

Одновременно с этим выяснилось, что попутно сломали службу DHCP-сервера, которая перестает отвечать на запросы продления аренды клиентами. В настоящий момент исправления данной проблемы нет, Microsoft обещает выпустить исправления «как только – так сразу».

Проблемой затронуты следующие системы:

▫️ Windows Server 2025 – обновление KB5060842
▫️Windows Server 2022 - обновление KB5060526
▫️Windows Server 2019 - обновление KB5060531
▫️Windows Server 2016 - обновление KB5061010

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

​​Узкий профиль или болото? Заключение.

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

Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»

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

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

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

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

Я сам на заре трудовой деятельности отработал два года в сельскохозяйственном НИИ и прекрасно освоил процесс имитации бурной деятельности. А реальная работа могла сутками стоять, потому что есть «гораздо более важные» дела.

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

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

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

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

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

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

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

Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.

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

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

Вот сейчас поиск на HH по слову Linux показывает в Москве 7303 вакансии, по слову FreeBSD – всего 44. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.

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

​​IP-калькулятор в консоли

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

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

apt install ipcalc

Использовать его тоже очень просто, достаточно указать адрес и маску. Маску можно указывать всеми доступными вариантами:

ipcalc 192.168.2.52/24
ipcalc 192.168.2.52/255.255.255.0
ipcalc 192.168.2.52 255.255.255.0

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

ipcalc 192.168.2.52 /24 /22
ipcalc 192.168.2.52 /24 /25

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

ipcalc 10.8.8.1 -s 120 55 25

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

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

Более редкая, но тоже нужная задача – деагрегация диапазона адресов. Это если нам нужно разложить некое адресное пространство на набор сетей. Задача не самая простая, но калькулятор успешно справляется и с ней, просто укажите диапазон адресов, остальное он все сделает сам.

ipcalc 10.8.8.125 – 10.9.2.251

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

​​Узкий профиль или болото? Часть 2.

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

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

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

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

Обмен происходил штатными средствами 1С через РИБ, т.е. с задержкой в 15-20 минут. Но перед этим данные еще должны были попасть в 1С из нашей внутренней программы, которая взаимодействовала с 1С через COM и там тоже была задержка в 5-10 минут, в зависимости от объемов данных.

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

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

Со звонками, мол Маша, позвони ему и скажи пусть отгрузит, у меня лимит есть, мне сегодня этот объект закончить надо, там клей уже разведен… и т.д. и т.п.

А кладовщик: как накладная придет – так отгружу, извини, я материально ответственное лицо.

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

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

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

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

К виртуализации у меня долгое время было отношение как к чему-то не для простых смертных. Ну да, работая в основном на Server 2003 / 2008 было немудрено.

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

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

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

Но посмотрев на виртуалки и контейнеры в деле я стал понемногу внедрять виртуализацию у себя по принципу «один сервис – одна виртуалка». Процесс тоже был довольно непрост. Зато теперь можно гибко управлять всей инфраструктурой не боясь, что обновление сервиса А завалит сервисы Б, В, Г, Д и далее по алфавиту.

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

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

😎 БезопасноеХранилищеДанных в 1С такое безопасное...

Все знают про то, что не стоит верить написанному на заборе. Как оказалось написанному в 1С тоже.

Сегодня потребовалось узнать пароль от FTP сохраненный в 1С. Как оказалось - нет ничего проще, он открытым текстом лежит в регистре Безопасное Хранилище Данных.

Готовая обработка здесь: https://infostart.ru/public/1155324/

Хотя она за 5 минут пишется на коленке.

Это мы к чему? Да к тому, что любой, кто имеет доступ к базе и владеет программированием под 1С быстро и непринужденно вытащит ВСЕ сохраненные в базе пароли.