PortQry v 2.0 – консольный сканер портов для Windows
Инструментов для диагностики сети хватает, но лишних среди них не бывает, поэтому сегодня хотим рассказать о консольном сетевом сканере от Microsoft - PortQry v 2.0, получить его можно на официальной странице: https://www.microsoft.com/en-us/download/details.aspx?id=17148
Использовать ее довольно просто, нам потребуется указать несколько параметров:
-n – точка назначения – имя или адрес сетевого узла
-p – протокол, доступны значения: tcp, udp, both, по умолчанию tcp.
-e – порт назначения
-o – перечень портов через запятую
-r - диапазон портов через двоеточие
Например:
или
В зависимости от результата вы получите одно из значений:
Listening – если порт открыт и ответ от него получен
Not Listening – если на целевом узле не запущен процесс обслуживающий порт и система сообщает ICMP «Destination Unreachable - Port Unreachable» или получен TCP-пакет с флагом Reset.
Filtered – если система не направила никакого ответа или запрос был отфильтрован брандмауэром.
Но это далеко не все, иначе данный инструмент просто ничем не выбивался из категории себе подобных.
Основная проблема заключается в том, что многие сетевые службы могут не отвечать на неформатированный запрос, а отвечают только на сообщения, использующие определенный уровень сеанса или прикладной протокол.
Таким образом, чтобы определить, действительно ли порт открыт или фильтруется PortQry использует расширенные проверки для ряда протоколов, в их число входят: LDAP, RPC, SMTP/POP3/IMAP4, SNMP, FTP/TFTP, NetBIOS, MS SQL, L2TP и ряд других.
На картинке внизу показан запрос к порту MS SQL, утилита первоначально проверила порт и выдала предварительную оценку: LISTENING or FILTERED.
После чего выполнила расширенную проверку и убедилась, что на данном узле запущен экземпляр службы SQLEXPRESS и окончательный вердикт стал LISTENING.
В некоторых случаях может потребоваться использовать определенный порт источника, в этом случае используйте следующий ключ (указанный порт не должен использоваться другими процессами):
Кроме того, у утилиты существует локальный режим, в котором она работает с сетевыми процессами хоста, в этом варианте интересными могут быть ключи:
-local – показывает информацию обо всех активных портах и соединениях локального узла
-wport – мониторит сетевую активность указанного порта
- wpid – мониторит сетевую активность процесса с указанным PID
Данные возможность удобно использовать с записью в лог файл:
Где ключ -wt задает частоту опроса в секундах, доступные значение 1-1200, по умолчанию 60 сек, а ключ -l указывает файл журнала, при указании относительного пути журнал создается в директории с утилитой.
Размер заметки не позволяет перечислить все возможности, поэтому дадим ссылку на страничку официальной документации: https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/networking/portqry-command-line-port-scanner-v2
А также советуем взять утилиту на вооружение, особенно если вам приходится часто заниматься устранением неисправностей и диагностикой Windows сетей.
Инструментов для диагностики сети хватает, но лишних среди них не бывает, поэтому сегодня хотим рассказать о консольном сетевом сканере от Microsoft - PortQry v 2.0, получить его можно на официальной странице: https://www.microsoft.com/en-us/download/details.aspx?id=17148
Использовать ее довольно просто, нам потребуется указать несколько параметров:
-n – точка назначения – имя или адрес сетевого узла
-p – протокол, доступны значения: tcp, udp, both, по умолчанию tcp.
-e – порт назначения
-o – перечень портов через запятую
-r - диапазон портов через двоеточие
Например:
PortQry.exe -n 192.168.100.125 -p udp -e 1194
или
PortQry.exe -n 192.168.100.125 -o 80, 443
В зависимости от результата вы получите одно из значений:
Listening – если порт открыт и ответ от него получен
Not Listening – если на целевом узле не запущен процесс обслуживающий порт и система сообщает ICMP «Destination Unreachable - Port Unreachable» или получен TCP-пакет с флагом Reset.
Filtered – если система не направила никакого ответа или запрос был отфильтрован брандмауэром.
Но это далеко не все, иначе данный инструмент просто ничем не выбивался из категории себе подобных.
Основная проблема заключается в том, что многие сетевые службы могут не отвечать на неформатированный запрос, а отвечают только на сообщения, использующие определенный уровень сеанса или прикладной протокол.
Таким образом, чтобы определить, действительно ли порт открыт или фильтруется PortQry использует расширенные проверки для ряда протоколов, в их число входят: LDAP, RPC, SMTP/POP3/IMAP4, SNMP, FTP/TFTP, NetBIOS, MS SQL, L2TP и ряд других.
На картинке внизу показан запрос к порту MS SQL, утилита первоначально проверила порт и выдала предварительную оценку: LISTENING or FILTERED.
После чего выполнила расширенную проверку и убедилась, что на данном узле запущен экземпляр службы SQLEXPRESS и окончательный вердикт стал LISTENING.
В некоторых случаях может потребоваться использовать определенный порт источника, в этом случае используйте следующий ключ (указанный порт не должен использоваться другими процессами):
PortQry.exe -n 192.168.100.125 -sp 25 -e 25
Кроме того, у утилиты существует локальный режим, в котором она работает с сетевыми процессами хоста, в этом варианте интересными могут быть ключи:
-local – показывает информацию обо всех активных портах и соединениях локального узла
-wport – мониторит сетевую активность указанного порта
- wpid – мониторит сетевую активность процесса с указанным PID
Данные возможность удобно использовать с записью в лог файл:
PortQry.exe -wport 3389 -wt 5 -l rdplog.txt
Где ключ -wt задает частоту опроса в секундах, доступные значение 1-1200, по умолчанию 60 сек, а ключ -l указывает файл журнала, при указании относительного пути журнал создается в директории с утилитой.
Размер заметки не позволяет перечислить все возможности, поэтому дадим ссылку на страничку официальной документации: https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/networking/portqry-command-line-port-scanner-v2
А также советуем взять утилиту на вооружение, особенно если вам приходится часто заниматься устранением неисправностей и диагностикой Windows сетей.
👍36🔥5❤3⚡1
Forwarded from The IT Director | Авторский канал про IT & eCom
Denwer. Кто помнит — уже не джун
Напомнили сегодня про Denwer — тот самый джентльменский набор разработчика. Кто ставил — поймёт. Кто не ставил… ну вы просто молоды)) забавно было вспоминать про инструменты, которые выдают в тебе возвраст разработчика, и объяснять это тем, кто в IT недавно)
🔥 Кто помнит — ставим огоньки)
© TheITDirector - авторский канал ИТ директора про опыт и системность.
#webdev #php #алдытут
Реклама. Бархударян Э.Э. ИНН 771575954801. erid: 2W5zFK1Bi2t
Напомнили сегодня про Denwer — тот самый джентльменский набор разработчика. Кто ставил — поймёт. Кто не ставил… ну вы просто молоды)) забавно было вспоминать про инструменты, которые выдают в тебе возвраст разработчика, и объяснять это тем, кто в IT недавно)
🔥 Кто помнит — ставим огоньки)
© TheITDirector - авторский канал ИТ директора про опыт и системность.
#webdev #php #алдытут
Реклама. Бархударян Э.Э. ИНН 771575954801. erid: 2W5zFK1Bi2t
🔥149❤4👍3🤮2🤡2
Как узнать какие пакеты установлены из определенного репозитория
Очень часто, наводя порядок или планируя обновление системы встает вопрос о подключенных репозиториях, в частности о том, для чего они нужны и какие пакеты из них установлены.
Прямого способа сделать это нет, но Linux тем и хорош, что позволяет решить задачу различными способами, в нашем случае мы будем использовать
Чтобы получить интересующую нас информацию прежде всего выведем список подключенных репозиториев командой:
В ее выводе нас прежде всего будет интересовать опция «источник (origin)», которая выводится после ключа
Теперь мы можем получить полный список пакетов из этого репозитория командой:
В данном случае указываем наименование источника сразу после ключа
Если репозиторий небольшой, то этого достаточно. Вы можете быстро понять, что из него уже установлено, что вы можете установить и нужно ли это вам вообще в текущий момент времени.
В противном случае нужно будет добавить дополнительные отборы, например, добавим фильтр по только установленным пакетам:
Здесь мы соединили через логическое И два условия: пакет установлен
Также обратите внимание, что имя источника не обязательно указывать полностью, так как это регулярное выражение. Так для репозитория
Но здесь нас может поджидать несколько иная сложность, среди установленных пактов нам могут попасться пакеты со статусом [установлен, автоматически] и их может быть много, очень много.
Статус [установлен, автоматически] обозначает что мы не выбирали этот пакет для установки, и он был получен автоматически, по зависимостям. Для больших репозиториев таких пакетов может оказаться сильно много, и они серьезно ухудшают восприятие. Поэтом добавим еще одно условие:
Где параметр
Данные конструкции можно использовать не только с командой
Ну или обратившись к подобной информации в сети интернет.
Очень часто, наводя порядок или планируя обновление системы встает вопрос о подключенных репозиториях, в частности о том, для чего они нужны и какие пакеты из них установлены.
Прямого способа сделать это нет, но Linux тем и хорош, что позволяет решить задачу различными способами, в нашем случае мы будем использовать
apt-patterns, позволяющий использовать регулярные выражения с командами apt.Чтобы получить интересующую нас информацию прежде всего выведем список подключенных репозиториев командой:
apt policy
В ее выводе нас прежде всего будет интересовать опция «источник (origin)», которая выводится после ключа
o=. Теперь мы можем получить полный список пакетов из этого репозитория командой:
apt list ~Onginx
В данном случае указываем наименование источника сразу после ключа
~O, без пробела. Обратите внимание, что данная команда выводит все пакеты, содержащиеся в репозитории, установленные пакеты при этом помечены отдельно как [установлен].Если репозиторий небольшой, то этого достаточно. Вы можете быстро понять, что из него уже установлено, что вы можете установить и нужно ли это вам вообще в текущий момент времени.
В противном случае нужно будет добавить дополнительные отборы, например, добавим фильтр по только установленным пакетам:
apt list ?and\(~i\,~Oprox\)
Здесь мы соединили через логическое И два условия: пакет установлен
~i и пакет принадлежит определенному источнику ~O, также не забывайте использовать обратный слеш для экранирования служебных символов.Также обратите внимание, что имя источника не обязательно указывать полностью, так как это регулярное выражение. Так для репозитория
o=Proxmox мы использовали просто ~Oprox.Но здесь нас может поджидать несколько иная сложность, среди установленных пактов нам могут попасться пакеты со статусом [установлен, автоматически] и их может быть много, очень много.
Статус [установлен, автоматически] обозначает что мы не выбирали этот пакет для установки, и он был получен автоматически, по зависимостям. Для больших репозиториев таких пакетов может оказаться сильно много, и они серьезно ухудшают восприятие. Поэтом добавим еще одно условие:
apt list ?and\(~i\,\!~M\,~Oprox\)
Где параметр
!~M обозначает «кроме установленных автоматически». Теперь вывод команды покажет только пакеты, которые были установлены вручную из указанного репозитория. Данные конструкции можно использовать не только с командой
apt list, но и с любыми другими командами apt, например для установки или удаления пакетов. А больше информации вы можете получить при помощи: man apt-patterns
Ну или обратившись к подобной информации в сети интернет.
1👍21❤4⚡1
Узкий профиль или болото?
В комментариях недавно всплыл вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).
На аргументы, что данный софт уже много лет как снят с поддержки применяется контраргумент, что мол много таких систем, где все это живо до сих пор и жить будет еще долго.
Несомненно, что так оно и есть, особенно среди специфических промышленных систем. Но есть один тонкий момент – квалификация, точнее ее потеря. А чтобы было понятнее что под этим имеется ввиду я специально попросил написать эту заметку коллегу, который побывал в подобной ситуации.
Далее от его лица, моя только литературная обработка.
Довольно давно, еще в начале десятых я попал на одно торгово-производственное предприятие. Им нужен был программист для 1С с навыками этой самой 1С администрирования. Компания только-только перешла на «восьмерку», и старый программист не тянул.
Но зато он отлично тянул еще одно внутреннее приложение, которое отвечало за всю внутреннюю кухню, включая производство и даже расчет зарплаты. Понемногу втянулся в это дело и я. Приложение было полностью самописное, на базе FoxPro.
Шли годы, мой начальник ушел на пенсию, и я занял его место, по деньгам было неплохо, я стал обрастать жирком и в какое-то время перестал интересоваться делами в отрасли. Ну не до того. На работе своих дел хватает, а дома семья, дети, стройка.
Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.
Жизнь шла по налаженной стезе, и я даже немного гордился тем, что я достаточно редкий специалист, так как найти кого-то на этот стек было практически невозможно.
Первый звоночек прозвучал в короновирус, когда мы серьезно просели по выручке и несколько месяцев получали голый оклад. Стало, мягко говоря, тяжело, тем более что накоплений особо не было (все ушло на стройку), а кредиты сами себя не заплатят.
Когда жизнь снова стала входить в привычное русло меня пригласили на один проект хорошие знакомые. Они как раз мигрировали подобную внутреннюю систему с FoxPro на новую 1С и им нужен был человек разбирающийся в FoxPro.
И вот тут я понял, что жизнь прошла мимо меня и я все пропустил. Ребята говорили о каких-то абсолютно неведомых мне вещах: Linux, виртуализация, контейнеры, кластеры, веб-сервисы. При том, что «серверная» там составляла всего один небольшой шкафчик.
Также посмотрел я и на «новую» 1С, которая оказалось может и умеет гораздо большее, чем я мог себе представить.
А дальше я понял, что как специалист я представляю из себя практически полный ноль и никому кроме своего «дяди» я не нужен.
Но если придется менять работу, то максимум я могу претендовать на позицию «джуна», но «джун» возрастом под 40 лет – это не то, что способно заинтересовать работодателя.
В общем весь этот проект я активно вникал в используемые в нем технологии, много спрашивал про то, как, что и на чем. И все больше понимал, насколько я отстал и что с этим нужно срочно что-то делать.
Но что делать как-то в голову не приходило. Да, надо было учить, но когда?
Второй звоночек прозвенел, когда я уехал на месяц по семейным обстоятельствам и работать мог урывками и то удаленно. После чего и мне и дяде стало понятно, что никто кроме меня всю нашу кухню не тянет.
По приезду состоялся разговор, мол, а если тебе завтра кирпич на голову упадет? Я сказал, что тоже об этом думал и «покаялся», рассказал дяде про халтурку и то, как там было все устроено.
После чего дядя сказал, мол, а чего ты раньше молчал? Давай думай, предлагай, нужно двигаться вперед. Надо учиться – отправим, но мы не должны отставать от технологий.
Сейчас я второй год активно переделываю всю внутреннюю кухню, от старого приложения отказаться еще не получилось, но многое уже перевели на современные технологии.
В комментариях недавно всплыл вопрос эксплуатации откровенно старых систем. Мол все что вы пишете – хорошо, но попробуйте это применить на … (можете вписать любой устаревший софт).
На аргументы, что данный софт уже много лет как снят с поддержки применяется контраргумент, что мол много таких систем, где все это живо до сих пор и жить будет еще долго.
Несомненно, что так оно и есть, особенно среди специфических промышленных систем. Но есть один тонкий момент – квалификация, точнее ее потеря. А чтобы было понятнее что под этим имеется ввиду я специально попросил написать эту заметку коллегу, который побывал в подобной ситуации.
Далее от его лица, моя только литературная обработка.
Довольно давно, еще в начале десятых я попал на одно торгово-производственное предприятие. Им нужен был программист для 1С с навыками этой самой 1С администрирования. Компания только-только перешла на «восьмерку», и старый программист не тянул.
Но зато он отлично тянул еще одно внутреннее приложение, которое отвечало за всю внутреннюю кухню, включая производство и даже расчет зарплаты. Понемногу втянулся в это дело и я. Приложение было полностью самописное, на базе FoxPro.
Шли годы, мой начальник ушел на пенсию, и я занял его место, по деньгам было неплохо, я стал обрастать жирком и в какое-то время перестал интересоваться делами в отрасли. Ну не до того. На работе своих дел хватает, а дома семья, дети, стройка.
Стек технологий у меня оставался стабильным, точнее стабильно древним: FoxPro, Visual Basic 6, Windows, COM и 1С на обычных формах. Новая 1С, которая 8.3 и на управляемых формах как-то не зашла (там сильно переучиваться надо было) и стояла только в бухгалтерии, благо дорабатывать ее было не нужно.
Жизнь шла по налаженной стезе, и я даже немного гордился тем, что я достаточно редкий специалист, так как найти кого-то на этот стек было практически невозможно.
Первый звоночек прозвучал в короновирус, когда мы серьезно просели по выручке и несколько месяцев получали голый оклад. Стало, мягко говоря, тяжело, тем более что накоплений особо не было (все ушло на стройку), а кредиты сами себя не заплатят.
Когда жизнь снова стала входить в привычное русло меня пригласили на один проект хорошие знакомые. Они как раз мигрировали подобную внутреннюю систему с FoxPro на новую 1С и им нужен был человек разбирающийся в FoxPro.
И вот тут я понял, что жизнь прошла мимо меня и я все пропустил. Ребята говорили о каких-то абсолютно неведомых мне вещах: Linux, виртуализация, контейнеры, кластеры, веб-сервисы. При том, что «серверная» там составляла всего один небольшой шкафчик.
Также посмотрел я и на «новую» 1С, которая оказалось может и умеет гораздо большее, чем я мог себе представить.
А дальше я понял, что как специалист я представляю из себя практически полный ноль и никому кроме своего «дяди» я не нужен.
Но если придется менять работу, то максимум я могу претендовать на позицию «джуна», но «джун» возрастом под 40 лет – это не то, что способно заинтересовать работодателя.
В общем весь этот проект я активно вникал в используемые в нем технологии, много спрашивал про то, как, что и на чем. И все больше понимал, насколько я отстал и что с этим нужно срочно что-то делать.
Но что делать как-то в голову не приходило. Да, надо было учить, но когда?
Второй звоночек прозвенел, когда я уехал на месяц по семейным обстоятельствам и работать мог урывками и то удаленно. После чего и мне и дяде стало понятно, что никто кроме меня всю нашу кухню не тянет.
По приезду состоялся разговор, мол, а если тебе завтра кирпич на голову упадет? Я сказал, что тоже об этом думал и «покаялся», рассказал дяде про халтурку и то, как там было все устроено.
После чего дядя сказал, мол, а чего ты раньше молчал? Давай думай, предлагай, нужно двигаться вперед. Надо учиться – отправим, но мы не должны отставать от технологий.
Сейчас я второй год активно переделываю всю внутреннюю кухню, от старого приложения отказаться еще не получилось, но многое уже перевели на современные технологии.
👍59❤9⚡4🤡3💯1
Forwarded from The IT Director | Авторский канал про IT & eCom
Ошибки в eCommerce, которые не видны, но вы за них заплатите
Сайт был удобный, продажи шли, товар учитывался через 1С.
Но была одна тонкость:
когда клиент клал товар в корзину и оформлял заказ, товар уходил в резерв.
Если заказ не оплачивали — он так и оставался в резерве.
А в системе — числился как “уже выкуплен”.
На практике это выглядело так:
— товар лежит на складе
— система считает, что его нет
— клиенту он не показывается
— никто не понимает, почему он не продаётся
Сотрудники должны были вручную снимать такие заказы с резерва. Но, как и бывает, просто забывали.
В результате: остатки искажены, товар не участвует в продаже, реклама идёт в холостую, и бизнес теряет деньги.
Решили это просто:
— автоматическое снятие заказа из резерва, если не был оплачен в течение N часов
— уведомления в админку
— чистка “мертвых” резервов
— восстановление остатка без участия человека
Такие кейсы вытаскиваются в результате аудита: когда смотришь на связку сайт ↔ 1С ↔ склад, а не просто на “работает / не работает”.
Это то, с чего часто начинается реальная оптимизация в eCommerce. Не с редизайна и не с новой CMS. А с устранения глухих узлов, которые просто не видно в интерфейсе.
-------
Было интересно? Если вы — владелец бизнеса, руководитель, развиваете свой продукт или просто хотите работать системно и результативно — здесь будет полезно, нажимайте на ссылку ниже и подписывайтесь
© TheITDirector - авторский канал
#ecommerce #разбор
Реклама. Бархударян Э.Э. ИНН 771575954801. erid: 2W5zFHSkTqr
Сайт был удобный, продажи шли, товар учитывался через 1С.
Но была одна тонкость:
когда клиент клал товар в корзину и оформлял заказ, товар уходил в резерв.
Если заказ не оплачивали — он так и оставался в резерве.
А в системе — числился как “уже выкуплен”.
На практике это выглядело так:
— товар лежит на складе
— система считает, что его нет
— клиенту он не показывается
— никто не понимает, почему он не продаётся
Сотрудники должны были вручную снимать такие заказы с резерва. Но, как и бывает, просто забывали.
В результате: остатки искажены, товар не участвует в продаже, реклама идёт в холостую, и бизнес теряет деньги.
Решили это просто:
— автоматическое снятие заказа из резерва, если не был оплачен в течение N часов
— уведомления в админку
— чистка “мертвых” резервов
— восстановление остатка без участия человека
Такие кейсы вытаскиваются в результате аудита: когда смотришь на связку сайт ↔ 1С ↔ склад, а не просто на “работает / не работает”.
Это то, с чего часто начинается реальная оптимизация в eCommerce. Не с редизайна и не с новой CMS. А с устранения глухих узлов, которые просто не видно в интерфейсе.
-------
Было интересно? Если вы — владелец бизнеса, руководитель, развиваете свой продукт или просто хотите работать системно и результативно — здесь будет полезно, нажимайте на ссылку ниже и подписывайтесь
© TheITDirector - авторский канал
#ecommerce #разбор
Реклама. Бархударян Э.Э. ИНН 771575954801. erid: 2W5zFHSkTqr
👍8🤮4❤2🔥2🤣1
😎 БезопасноеХранилищеДанных в 1С такое безопасное...
Все знают про то, что не стоит верить написанному на заборе. Как оказалось написанному в 1С тоже.
Сегодня потребовалось узнать пароль от FTP сохраненный в 1С. Как оказалось - нет ничего проще, он открытым текстом лежит в регистре Безопасное Хранилище Данных.
Готовая обработка здесь: https://infostart.ru/public/1155324/
Хотя она за 5 минут пишется на коленке.
Это мы к чему? Да к тому, что любой, кто имеет доступ к базе и владеет программированием под 1С быстро и непринужденно вытащит ВСЕ сохраненные в базе пароли.
Все знают про то, что не стоит верить написанному на заборе. Как оказалось написанному в 1С тоже.
Сегодня потребовалось узнать пароль от FTP сохраненный в 1С. Как оказалось - нет ничего проще, он открытым текстом лежит в регистре Безопасное Хранилище Данных.
Готовая обработка здесь: https://infostart.ru/public/1155324/
Хотя она за 5 минут пишется на коленке.
Это мы к чему? Да к тому, что любой, кто имеет доступ к базе и владеет программированием под 1С быстро и непринужденно вытащит ВСЕ сохраненные в базе пароли.
😁14👀7👍4
Узкий профиль или болото? Часть 2.
Продолжаем рассказ, написанный по моей просьбе коллегой, повествование идет от его лица.
В общем, поговорив с дядей я занялся внедрением современных технологий, прежде всего на те участки, где у нас были узкие места. А они были, прежде всего в оперативном обмене информацией между подразделениями.
И именно это больше всего тревожило собственника. Интернет-торговля уже начинала наступать на пятки и нас выручало в основном то, что отделочные и строительные материалы люди предпочитают посмотреть и потрогать перед покупкой.
У нас же выставочный зал представлял в основном образцы, плюс тут же был небольшой склад с мелочевкой. Остальное или на первом складе, километрах в трех от нас, или на производственной площадке, на другом конце города.
Обмен происходил штатными средствами 1С через РИБ, т.е. с задержкой в 15-20 минут. Но перед этим данные еще должны были попасть в 1С из нашей внутренней программы, которая взаимодействовала с 1С через COM и там тоже была задержка в 5-10 минут, в зависимости от объемов данных.
Все это приводило к тому, что данные из центрального офиса могли попасть на склады с задержкой до получаса. И это начало создавать серьезные сложности, особенно с постоянными клиентами из числа строительных бригад, у которых были лимиты на отгрузку без оплаты, которые могли динамически меняться в зависимости от объемов и платежной дисциплины.
А теперь представьте, клиент неправильно посчитал плитку, бригада на объекте, нужно срочно еще ящик-другой. Бригадир берет кусок плитки и едет сразу на склад. Находят нужную партию и дальше начинаются качели длинной в полчаса.
Со звонками, мол Маша, позвони ему и скажи пусть отгрузит, у меня лимит есть, мне сегодня этот объект закончить надо, там клей уже разведен… и т.д. и т.п.
А кладовщик: как накладная придет – так отгружу, извини, я материально ответственное лицо.
И этот вопрос никак на текущем стеке технологий не решался. Поэтому первым делом стали внедрять веб-сервисы. Просто не было, пришлось практически все изучать с нуля, для меня и моих коллег это буквально была новая планета.
Но справились и когда мы это внедрили даже в зачаточном состоянии, то получили эффект разорвавшейся бомбы. Все сразу начали спрашивать: а что, так можно было, и почему вы раньше так не сделали?
Теперь при наличии связи любой заказ, лимит или баланс виден в режиме реального времени. Это очень сильно подняло и нашу самооценку, и наш рейтинг в глазах руководства. Потому что мы решили одну из главных проблем и сразу же получили зеленый свет на дальнейшие действия.
А после мы занялись внутренней инфраструктурой, потому что там было что-то просто ужасающее.
К виртуализации у меня долгое время было отношение как к чему-то не для простых смертных. Ну да, работая в основном на Server 2003 / 2008 было немудрено.
В итоге на физических серверах в итоге собрались такие причудливые сочетания служб, что сам уже не понимал как оно там все устроено и работает. В полный рост применялся принцип: работает – не трогай.
Я не говорю уже про профилактику или апдейты, все это приходилось делать в глубоко нерабочее время и постоянно думать об одном: лишь бы взлетело.
В итоге младший персонал просто боялся что-то там трогать, и я невольно стал «незаменимым», что не нравилось ни мне, ни руководству.
Но посмотрев на виртуалки и контейнеры в деле я стал понемногу внедрять виртуализацию у себя по принципу «один сервис – одна виртуалка». Процесс тоже был довольно непрост. Зато теперь можно гибко управлять всей инфраструктурой не боясь, что обновление сервиса А завалит сервисы Б, В, Г, Д и далее по алфавиту.
Кроме того, появилась возможность разделить роли между сотрудниками. Этот отвечает за почту, этот за сайт, а этот за базы данных. У каждого свои виртуалки, свой объем работ и свой уровень ответственности.
И да, теперь я специалист самого широкого профиля и не являюсь незаменимым. Зато я могу спокойно уехать на две недели к морю и пить пиво на пляже, не вздрагивая от каждого звука из телефона.
Продолжаем рассказ, написанный по моей просьбе коллегой, повествование идет от его лица.
В общем, поговорив с дядей я занялся внедрением современных технологий, прежде всего на те участки, где у нас были узкие места. А они были, прежде всего в оперативном обмене информацией между подразделениями.
И именно это больше всего тревожило собственника. Интернет-торговля уже начинала наступать на пятки и нас выручало в основном то, что отделочные и строительные материалы люди предпочитают посмотреть и потрогать перед покупкой.
У нас же выставочный зал представлял в основном образцы, плюс тут же был небольшой склад с мелочевкой. Остальное или на первом складе, километрах в трех от нас, или на производственной площадке, на другом конце города.
Обмен происходил штатными средствами 1С через РИБ, т.е. с задержкой в 15-20 минут. Но перед этим данные еще должны были попасть в 1С из нашей внутренней программы, которая взаимодействовала с 1С через COM и там тоже была задержка в 5-10 минут, в зависимости от объемов данных.
Все это приводило к тому, что данные из центрального офиса могли попасть на склады с задержкой до получаса. И это начало создавать серьезные сложности, особенно с постоянными клиентами из числа строительных бригад, у которых были лимиты на отгрузку без оплаты, которые могли динамически меняться в зависимости от объемов и платежной дисциплины.
А теперь представьте, клиент неправильно посчитал плитку, бригада на объекте, нужно срочно еще ящик-другой. Бригадир берет кусок плитки и едет сразу на склад. Находят нужную партию и дальше начинаются качели длинной в полчаса.
Со звонками, мол Маша, позвони ему и скажи пусть отгрузит, у меня лимит есть, мне сегодня этот объект закончить надо, там клей уже разведен… и т.д. и т.п.
А кладовщик: как накладная придет – так отгружу, извини, я материально ответственное лицо.
И этот вопрос никак на текущем стеке технологий не решался. Поэтому первым делом стали внедрять веб-сервисы. Просто не было, пришлось практически все изучать с нуля, для меня и моих коллег это буквально была новая планета.
Но справились и когда мы это внедрили даже в зачаточном состоянии, то получили эффект разорвавшейся бомбы. Все сразу начали спрашивать: а что, так можно было, и почему вы раньше так не сделали?
Теперь при наличии связи любой заказ, лимит или баланс виден в режиме реального времени. Это очень сильно подняло и нашу самооценку, и наш рейтинг в глазах руководства. Потому что мы решили одну из главных проблем и сразу же получили зеленый свет на дальнейшие действия.
А после мы занялись внутренней инфраструктурой, потому что там было что-то просто ужасающее.
К виртуализации у меня долгое время было отношение как к чему-то не для простых смертных. Ну да, работая в основном на Server 2003 / 2008 было немудрено.
В итоге на физических серверах в итоге собрались такие причудливые сочетания служб, что сам уже не понимал как оно там все устроено и работает. В полный рост применялся принцип: работает – не трогай.
Я не говорю уже про профилактику или апдейты, все это приходилось делать в глубоко нерабочее время и постоянно думать об одном: лишь бы взлетело.
В итоге младший персонал просто боялся что-то там трогать, и я невольно стал «незаменимым», что не нравилось ни мне, ни руководству.
Но посмотрев на виртуалки и контейнеры в деле я стал понемногу внедрять виртуализацию у себя по принципу «один сервис – одна виртуалка». Процесс тоже был довольно непрост. Зато теперь можно гибко управлять всей инфраструктурой не боясь, что обновление сервиса А завалит сервисы Б, В, Г, Д и далее по алфавиту.
Кроме того, появилась возможность разделить роли между сотрудниками. Этот отвечает за почту, этот за сайт, а этот за базы данных. У каждого свои виртуалки, свой объем работ и свой уровень ответственности.
И да, теперь я специалист самого широкого профиля и не являюсь незаменимым. Зато я могу спокойно уехать на две недели к морю и пить пиво на пляже, не вздрагивая от каждого звука из телефона.
👍61❤11🤡3⚡2🤮2
IP-калькулятор в консоли
Любой администратор рано или поздно сталкивается с необходимостью рассчитать ту или иную сеть по количеству хостов или маске. Обычно для этих целей используются IP-калькуляторы, чаше всего в виде онлайн сервисов.
Но для любителей работы в консоли и не только есть прекрасная альтернатива в виде консольного приложения, оно есть в стандартных репозиториях и для его установки просто введите:
Использовать его тоже очень просто, достаточно указать адрес и маску. Маску можно указывать всеми доступными вариантами:
Также вы можете сразу расширить или сузить сеть и сразу увидеть в какую сеть большего размера попадет ваша подсеть или, наоборот, на какие подсети она будет разделена:
Еще одна часто встречающаяся задача – нарезать некоторое адресное пространство на несколько подсетей с заданным количеством хостов. Все просто, указываем сеть или адрес нужной сети и перечисляем нужные пулы по количеству хостов:
Результат можно посмотреть на картинке ниже. Калькулятор поделил сеть на несколько подсетей с наиболее подходящим количеством хостов.
Кроме обычной информации калькулятор таже выводит все значения в двоичном виде, что довольно ценно для начинающих, так как позволяет собственными глазами увидеть, что такое маска и почему при указанном значении маски максимальные и минимальные адреса сети будут именно такими, а не другими.
Более редкая, но тоже нужная задача – деагрегация диапазона адресов. Это если нам нужно разложить некое адресное пространство на набор сетей. Задача не самая простая, но калькулятор успешно справляется и с ней, просто укажите диапазон адресов, остальное он все сделает сам.
Никакого заумного синтаксиса, никаких ключей. Все просто, понятно, наглядно. И не надо никаких онлайн сервисов, достаточно просто запустить терминал.
Любой администратор рано или поздно сталкивается с необходимостью рассчитать ту или иную сеть по количеству хостов или маске. Обычно для этих целей используются IP-калькуляторы, чаше всего в виде онлайн сервисов.
Но для любителей работы в консоли и не только есть прекрасная альтернатива в виде консольного приложения, оно есть в стандартных репозиториях и для его установки просто введите:
apt install ipcalcИспользовать его тоже очень просто, достаточно указать адрес и маску. Маску можно указывать всеми доступными вариантами:
ipcalc 192.168.2.52/24ipcalc 192.168.2.52/255.255.255.0ipcalc 192.168.2.52 255.255.255.0Также вы можете сразу расширить или сузить сеть и сразу увидеть в какую сеть большего размера попадет ваша подсеть или, наоборот, на какие подсети она будет разделена:
ipcalc 192.168.2.52 /24 /22ipcalc 192.168.2.52 /24 /25Еще одна часто встречающаяся задача – нарезать некоторое адресное пространство на несколько подсетей с заданным количеством хостов. Все просто, указываем сеть или адрес нужной сети и перечисляем нужные пулы по количеству хостов:
ipcalc 10.8.8.1 -s 120 55 25Результат можно посмотреть на картинке ниже. Калькулятор поделил сеть на несколько подсетей с наиболее подходящим количеством хостов.
Кроме обычной информации калькулятор таже выводит все значения в двоичном виде, что довольно ценно для начинающих, так как позволяет собственными глазами увидеть, что такое маска и почему при указанном значении маски максимальные и минимальные адреса сети будут именно такими, а не другими.
Более редкая, но тоже нужная задача – деагрегация диапазона адресов. Это если нам нужно разложить некое адресное пространство на набор сетей. Задача не самая простая, но калькулятор успешно справляется и с ней, просто укажите диапазон адресов, остальное он все сделает сам.
ipcalc 10.8.8.125 – 10.9.2.251Никакого заумного синтаксиса, никаких ключей. Все просто, понятно, наглядно. И не надо никаких онлайн сервисов, достаточно просто запустить терминал.
👍52🔥9❤8⚡1
Узкий профиль или болото? Заключение.
На этих выходных мы обсуждали ситуацию, когда используемый стек технологий негативно отражается на развитии специалиста и приводит к фактическому застою.
Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»
Если вы выпадаете на несколько лет из актуальной повестки, то можете уже не узнать окружающую вас реальность, все будут говорить о чем-то непонятном и смотреть на вас как на динозавра.
Хорошо, если вы сможете быстро адаптироваться и устранить пробелы, а если такой возможности нет? В таком случае вы выпадаете не только из технологий, но и с рынка труда, где уже не можете претендовать на серьезные вакансии, а на начальный уровень скорее возьмут молодого мальчика, чем взрослого дядьку.
На первое место среди кладбищ кадров я бы поставил бюджетные организации. Там не только прекращается развитие специалиста, но и вообще прививаются крайне вредные привычки, вроде имитации работы и написания красивых отчетов.
В бюджетке важно, чтобы все было прикрыто бумагами и худо-бедно работало. А если не работает, то обязательно по уважительной причине, отраженной в куче отчетов, докладных записок и т.д.
Я сам на заре трудовой деятельности отработал два года в сельскохозяйственном НИИ и прекрасно освоил процесс имитации бурной деятельности. А реальная работа могла сутками стоять, потому что есть «гораздо более важные» дела.
Второй бич бюджетки – это отношения «ты начальник – я дурак, я начальник – ты дурак» и связанные с ними бесконечные согласования, обсуждения и т.п. После того, как я ушел оттуда в частную фирму мой новый начальник еще с полгода закрывал лицо рукой и устало произносил: «ну когда ты начнешь работать самостоятельно???»
В коммерции все немного бодрее, но до поры до времени. После того как найдена некая оптимальная конфигурация IT-инфраструктуры наступает пора стабилизации и это нормально. Но очень часто она выливается в застой.
Появляется определенная зона комфорта. Действительно, а зачем учить что-то новое, если и так все работает? Зачем что-то внедрять, рисковать, тратить время и нервы, когда можно ничего не делать и получать те же деньги?
Вот так, незаметно, стабильность сменяется застоем, а некогда актуальная инфраструктура начинает стремительно устаревать. Причем чем дольше заметать пыль под ковер, делая вид что все хорошо, то тем хуже становится в последствии.
Обычно то, что с IT что-то не так до руководства доходит слишком поздно, когда начинают ломаться бизнес-процессы или возникает серьезная проблема с внедрением нововведений, как законодательных, так и сервисных, призванных улучшить обслуживание клиентов или внутренних подразделений.
В этом случае выясняется, что проще все сломать и построить заново, нежели приводить то, что есть в порядок и вряд ли ваша карьера в этом месте продолжит дальше катиться по накатанной.
Ну и третья категория, это «узкие» специалисты. Тут вообще разговор отдельный, более проходящий по теме религиозного фанатизма, нежели информационных технологий.
Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.
Проблемы начинаются, когда список задач выходит за пределы знаний и умений такого специалиста, а приглашенные со стороны либо умывают руки, либо выставляют космический прайс.
Я понимаю, что редкий стек – это греет душу и поднимает самооценку, но, будем смотреть правде в глаза – на рынке труда стоимость этих знаний близка к нулю.
Вот сейчас поиск на HH по слову Linux показывает в Москве 7303 вакансии, по слову FreeBSD – всего 44. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.
Поэтому, коллеги, трезво оцените свое положение и если вы все такие попали в описанное выше болото, то найдите силы это признать и начинайте из него выбираться.
На этих выходных мы обсуждали ситуацию, когда используемый стек технологий негативно отражается на развитии специалиста и приводит к фактическому застою.
Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»
Если вы выпадаете на несколько лет из актуальной повестки, то можете уже не узнать окружающую вас реальность, все будут говорить о чем-то непонятном и смотреть на вас как на динозавра.
Хорошо, если вы сможете быстро адаптироваться и устранить пробелы, а если такой возможности нет? В таком случае вы выпадаете не только из технологий, но и с рынка труда, где уже не можете претендовать на серьезные вакансии, а на начальный уровень скорее возьмут молодого мальчика, чем взрослого дядьку.
На первое место среди кладбищ кадров я бы поставил бюджетные организации. Там не только прекращается развитие специалиста, но и вообще прививаются крайне вредные привычки, вроде имитации работы и написания красивых отчетов.
В бюджетке важно, чтобы все было прикрыто бумагами и худо-бедно работало. А если не работает, то обязательно по уважительной причине, отраженной в куче отчетов, докладных записок и т.д.
Я сам на заре трудовой деятельности отработал два года в сельскохозяйственном НИИ и прекрасно освоил процесс имитации бурной деятельности. А реальная работа могла сутками стоять, потому что есть «гораздо более важные» дела.
Второй бич бюджетки – это отношения «ты начальник – я дурак, я начальник – ты дурак» и связанные с ними бесконечные согласования, обсуждения и т.п. После того, как я ушел оттуда в частную фирму мой новый начальник еще с полгода закрывал лицо рукой и устало произносил: «ну когда ты начнешь работать самостоятельно???»
В коммерции все немного бодрее, но до поры до времени. После того как найдена некая оптимальная конфигурация IT-инфраструктуры наступает пора стабилизации и это нормально. Но очень часто она выливается в застой.
Появляется определенная зона комфорта. Действительно, а зачем учить что-то новое, если и так все работает? Зачем что-то внедрять, рисковать, тратить время и нервы, когда можно ничего не делать и получать те же деньги?
Вот так, незаметно, стабильность сменяется застоем, а некогда актуальная инфраструктура начинает стремительно устаревать. Причем чем дольше заметать пыль под ковер, делая вид что все хорошо, то тем хуже становится в последствии.
Обычно то, что с IT что-то не так до руководства доходит слишком поздно, когда начинают ломаться бизнес-процессы или возникает серьезная проблема с внедрением нововведений, как законодательных, так и сервисных, призванных улучшить обслуживание клиентов или внутренних подразделений.
В этом случае выясняется, что проще все сломать и построить заново, нежели приводить то, что есть в порядок и вряд ли ваша карьера в этом месте продолжит дальше катиться по накатанной.
Ну и третья категория, это «узкие» специалисты. Тут вообще разговор отдельный, более проходящий по теме религиозного фанатизма, нежели информационных технологий.
Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.
Проблемы начинаются, когда список задач выходит за пределы знаний и умений такого специалиста, а приглашенные со стороны либо умывают руки, либо выставляют космический прайс.
Я понимаю, что редкий стек – это греет душу и поднимает самооценку, но, будем смотреть правде в глаза – на рынке труда стоимость этих знаний близка к нулю.
Вот сейчас поиск на HH по слову Linux показывает в Москве 7303 вакансии, по слову FreeBSD – всего 44. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.
Поэтому, коллеги, трезво оцените свое положение и если вы все такие попали в описанное выше болото, то найдите силы это признать и начинайте из него выбираться.
👍51❤7🤡3🤮2
Не было печали – апдейтов накачали. Июньский вторник патчей
В рамках июньского вторника патчей 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
Если эта проблема коснулась вас, то следует трезво взвесить все плюсы и минусы, так как простое удаление обновления делает систему уязвимой.
В рамках июньского вторника патчей 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
Если эта проблема коснулась вас, то следует трезво взвесить все плюсы и минусы, так как простое удаление обновления делает систему уязвимой.
👀13😱9🤷♂5👍4🤡4
Сканируем сеть при помощи PowerShell
Часто стоит задача узнать на каком узле сети запущен тот или иной сервис и доступен ли он. Можно, конечно, скачать какое-либо подходящее ПО, а можно воспользоваться 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 и мы можем продолжать обрабатывать результат дальше или вообще оформить все отдельным скриптом.
👍55
👍9
Свет мой зеркальце, скажи…
И снова наши любимые нейросети, которые сегодня просто везде и многие горячие головы рекомендуют использовать их вместо поиска. Хотя, на самом деле, они не оригинальны в своих начинаниях и поисковики давно на самом верху выдачи приводят компиляции по заданному вопросу от нейросетей.
Пока не касаешься этого вопроса глубоко, то может показаться что все не так и плохо и нейросети помогают нам получить выжимку и систематизировать ее, уменьшая время поиска необходимой информации.
Но это только на первый взгляд. Потому что у нейросетей есть один, но очень существенный недостаток – они не умеют молчать. Если человек может сказать – я не знаю, поисковик вернуть полупустую страницу по запросу, то нейросеть обязательно должна что-то вам рассказать. И не важно правду или вымысел, главное – рассказать.
Третьего дня задал нейросети простой вопрос, просто лень вспоминать было, и получил вполне нормальный ответ по существу. Но потом меня дернуло спросить, а нет ли каких-нибудь особенностей (хотя их там не было, вопрос был простой, о матрице совместимости)?
И тут сеть начала выдавать такую пургу, что любо-дорого. А когда я попросил привести первоисточник – дала ссылку на общую документацию, мол там, где-то есть, ищи как хочешь.
Когда я указал сетке на этот момент она спокойно ответила, что отдельной страницы в документации она не знает и посоветовала воспользоваться поиском по сайту.
Но я был настойчив и уведомил ее, что ничего подобного я там не нашел. И сетка тут же переобулась в воздухе, мол да, бывает, значит это было написано в документации к какому-то плагину или патчу, или вообще не было никогда написано…
И если бы на этом она остановилась, но нет, она тут же предложила альтернативу вывалив еще полотно пурги, правда на этот раз просто обильно разбавила водой исходную информацию.
И вот тут в полный рост встает вопрос доверия. И усугубляет его не то, что сетка иногда врет, а то, как именно она врет. А делает она это исключительно умело, подмешивая к достоверной информации собственные фантазии так, что у вас даже не закрадется сомнений.
Но погодите, скажет иной читатель, а как же с тем, что сетка пишет код, составляет тексты, рисует и вообще делает массу полезной работы.
Делает, но для того, чтобы сетка это делала нужно подробно и доходчиво пояснить ей чего вы хотите, чего не хотите и в каких рамках она должна держаться, в том числе насколько допускаются ее фантазии и предположения.
Если взять серьезные рабочие промпты, то, по сути, это готовые технические задания, составленные тем, кто в теме и кто четко знает какой результат надо получить. Однако составить такой промпт – это тоже серьезная работа.
И в этом случае сетка выступает не в роли кладезя мудрости, а в роли исполнительного, начитанного, но придурковатого помощника. Которому нужно все очень подробно разъяснить и пояснить, причем не только то, что надо сделать, но и то, чего делать не надо. Иначе, он как в той поговорке, лоб расшибет.
Но какое техзадание может быть при поиске информации, когда мы еще сами не знаем чего хотим? Плюс у нас полностью или практически полностью отсутствует критическая оценка результата, ровно по той же причине – отсутствия знаний.
А нет ТЗ – результат ХЗ, это давно известно и полностью применимо к поиску при помощи нейросетей. Вы никогда не узнаете сказала ли вам сетка правду или что-то от себя добавила.
Хотя самые первые и общие запросы как правило близки к правде, а вот как только вы захотите что-то уточнить, то тут можно столкнуться со всем чем угодно, бесконечно далеким от реальности.
А дальше вы так или иначе теряете время на проверку и перепроверку полученной информации и хорошо, если еще ничего не поломаете в процессе.
Поэтому будьте внимательны и критически подходите к тому, что сообщает вам сеть. А лучше всего начните с классических источников – официальной документации, так будет быстрее и проще. А сетку можете попросить пояснить непонятные вам моменты, это у нее получается неплохо.
И снова наши любимые нейросети, которые сегодня просто везде и многие горячие головы рекомендуют использовать их вместо поиска. Хотя, на самом деле, они не оригинальны в своих начинаниях и поисковики давно на самом верху выдачи приводят компиляции по заданному вопросу от нейросетей.
Пока не касаешься этого вопроса глубоко, то может показаться что все не так и плохо и нейросети помогают нам получить выжимку и систематизировать ее, уменьшая время поиска необходимой информации.
Но это только на первый взгляд. Потому что у нейросетей есть один, но очень существенный недостаток – они не умеют молчать. Если человек может сказать – я не знаю, поисковик вернуть полупустую страницу по запросу, то нейросеть обязательно должна что-то вам рассказать. И не важно правду или вымысел, главное – рассказать.
Третьего дня задал нейросети простой вопрос, просто лень вспоминать было, и получил вполне нормальный ответ по существу. Но потом меня дернуло спросить, а нет ли каких-нибудь особенностей (хотя их там не было, вопрос был простой, о матрице совместимости)?
И тут сеть начала выдавать такую пургу, что любо-дорого. А когда я попросил привести первоисточник – дала ссылку на общую документацию, мол там, где-то есть, ищи как хочешь.
Когда я указал сетке на этот момент она спокойно ответила, что отдельной страницы в документации она не знает и посоветовала воспользоваться поиском по сайту.
Но я был настойчив и уведомил ее, что ничего подобного я там не нашел. И сетка тут же переобулась в воздухе, мол да, бывает, значит это было написано в документации к какому-то плагину или патчу, или вообще не было никогда написано…
И если бы на этом она остановилась, но нет, она тут же предложила альтернативу вывалив еще полотно пурги, правда на этот раз просто обильно разбавила водой исходную информацию.
И вот тут в полный рост встает вопрос доверия. И усугубляет его не то, что сетка иногда врет, а то, как именно она врет. А делает она это исключительно умело, подмешивая к достоверной информации собственные фантазии так, что у вас даже не закрадется сомнений.
Но погодите, скажет иной читатель, а как же с тем, что сетка пишет код, составляет тексты, рисует и вообще делает массу полезной работы.
Делает, но для того, чтобы сетка это делала нужно подробно и доходчиво пояснить ей чего вы хотите, чего не хотите и в каких рамках она должна держаться, в том числе насколько допускаются ее фантазии и предположения.
Если взять серьезные рабочие промпты, то, по сути, это готовые технические задания, составленные тем, кто в теме и кто четко знает какой результат надо получить. Однако составить такой промпт – это тоже серьезная работа.
И в этом случае сетка выступает не в роли кладезя мудрости, а в роли исполнительного, начитанного, но придурковатого помощника. Которому нужно все очень подробно разъяснить и пояснить, причем не только то, что надо сделать, но и то, чего делать не надо. Иначе, он как в той поговорке, лоб расшибет.
Но какое техзадание может быть при поиске информации, когда мы еще сами не знаем чего хотим? Плюс у нас полностью или практически полностью отсутствует критическая оценка результата, ровно по той же причине – отсутствия знаний.
А нет ТЗ – результат ХЗ, это давно известно и полностью применимо к поиску при помощи нейросетей. Вы никогда не узнаете сказала ли вам сетка правду или что-то от себя добавила.
Хотя самые первые и общие запросы как правило близки к правде, а вот как только вы захотите что-то уточнить, то тут можно столкнуться со всем чем угодно, бесконечно далеким от реальности.
А дальше вы так или иначе теряете время на проверку и перепроверку полученной информации и хорошо, если еще ничего не поломаете в процессе.
Поэтому будьте внимательны и критически подходите к тому, что сообщает вам сеть. А лучше всего начните с классических источников – официальной документации, так будет быстрее и проще. А сетку можете попросить пояснить непонятные вам моменты, это у нее получается неплохо.
💯31👍19❤6🔥1🤔1
Кстати, картинка к тексту как раз таки прекрасная иллюстрация работы сетей. Я заутомился пояснять сетке, что в руках у персонажей не должно ничего быть. И каждый раз список приходилось увеличивать, так как не орех, так чашка, не чашка - так яблоко. Ну и некоторые иные фантазии начинали выглядеть пугающе, "так что пусть в этой песне все остается как было" (С) Юра Хой.
😁32👍5
Вернемся к вчерашнему вопросу про OpenVPN и два маршрута.
Правильный ответ: препятствует переопределению нулевого маршрута
Почему так? Давайте разбираться. Пример таблицы маршрутов с активным OpenVPN соединением показан на рисунке ниже.
Сразу же в очередной раз вспоминаем, как идет поиск маршрута в таблице:
1️⃣ Сначала ищется маршрут к узлу назначения с самой узкой маской
2️⃣Затем определяется интерфейс выхода среди непосредственно присоединенных сетей, который позволяет достичь указанного в маршруте шлюза.
Если к одному узлу назначения ведут несколько маршрутов с одинаковой шириной маски, то выбирается маршрут с лучшей метрикой .
Теперь давайте смотреть: прежде всего обратим внимание на маршрут
Затем у нас есть два маршрута к непосредственно присоединенным сетям
Остальной трафик не попадает ни под один из указанных выше маршрутов и поиск для него продолжается дальше.
В результате будет найдет один из двух маршрутов
А так как маска
Потому что даже если мы не будем делить маршруты на два диапазона и пропишем еще один нулевой, то в системе появится два нулевых маршрута с разными шлюзами и разными метриками. Но использоваться будет тот, чья метрика меньше.
Основной недостаток такого подхода – это переопределение нулевого маршрута другим подключением. Например, вы присоединили 4G модем, переподключились к другой беспроводной сети или подключили еще один VPN.
Как минимум это потребует переподключения OpenVPN, а в иных случаях ручного переопределения приоритетов маршрутов.
Чтобы избежать подобных ситуаций OpenVPN использует два маршрута с более узкой маской вместо одного нулевого, в этом случае даже при переопределении нулевого маршрута в системе трафик пользователя все равно будет уходить в VPN-туннель.
Правильный ответ: препятствует переопределению нулевого маршрута
Почему так? Давайте разбираться. Пример таблицы маршрутов с активным 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-туннель.
👍37❤5
Кадры решают все
Третьего дня попросил нас один заказчик помочь ему с подбором персонала. Задача для нас привычная, но последние несколько лет мы такими вещами как-то не занимались, поэтому оказалось достаточно интересно освежить свой опыт.
А коллегам, как мне кажется, будет полезно посмотреть на ситуацию глазами работодателя и, возможно, увидеть собственные ошибки при отклике на вакансии.
Сама вакансия предусматривает закрытие линейной должности системного администратора, основная задача которого – это обслуживание рабочих мест, включая офисное и торговое оборудование, а также поддержка пользователей (как удаленная, так и на месте).
Режим работы смешанный. Офис + удаленка. Плюс дежурства в выходные и праздничные дни, оплачиваются отдельно. Предлагаемая з/п по окладу в рынке, возможно даже и немного выше рынка для аналогичной должности.
На текущем этапе мы с представителем заказчика проработали только резюме, никаких личных контактов с соискателями не проводилось. Резюме было довольно много, но прошли не только лишь все. Вот именно о тех, кто сразу не прошел и поговорим.
1️⃣ Госы. Таких соискателей, надо сказать, много. Идут с аналогичных должностей из различных МУП, ГУП, администраций, учебных заведении и т.д. и т.п. Такие резюме сразу в мусорку. Ну разве что там будет молодой парень с первым и единственным местом работы, ну и тот станет в самый конец очереди.
Почему? Я уже давно и неоднократно писал, что госы – это кладбище кадров и человек проработавший там определенное время стремительно деградирует как специалист и командный сотрудник, но взамен приобретает многие иные качества, крайне нужные для выживания в госах, но бесполезные или даже откровенно вредные вне их.
При этом это не только мое мнение, но и мнение заказчика, где он несколько в ином ключе высказал практически аналогичные тезисы.
Даже если оставить сугубо профессиональные качества, то бывший сотрудник госов не способен к продуктивной командной работе, не умеет работать самостоятельно, предпочитает отлынивать от работы там, где это возможно, склонен к перекладыванию задач и ответственности, а также крайне негативно и разлагающе воздействует на рабочую атмосферу в коллективе.
😤 Написанное выше может вызвать массовое возгорание пятых точек, но увы, это так, во всяком случае со стороны коммерческого работодателя.
Что делать? Для начала понять и принять, что гос – для большинства работодателей черная метка. А там решайте, готовы ли вы что-то менять, причем менять радикально, или лучше спокойно досидеть, где сидится.
В противном случае берите подработки, просите рекомендации, ищите личные выходы. Через резюме найти работу будет достаточно затруднительно.
2️⃣ Оверквалификация. Таких резюме поменьше, но тоже хватает, и кого там только нет, чуть ли не кандидаты наук. Бывшие инженеры, программисты, руководители направлений и отделов. Послужные списки многих впечатляют.
Только вот с должностью, на которую они претендуют это соотносится крайне слабо. Что вызывает закономерные вопросы. На которые напрашиваются закономерные ответы.
🐏 Вариант 1. Соискатель на самом деле туп как бревно, а все эти регалии приписаны по принципу «рядом стоял, через плечо глядел». Либо просиживал стул на руководящей должности, а работали подчиненные.
После чего следует закономерный вывод – а нафига он тут такой красивый нужен? Даже если его квалификации и хватает для закрытия вакансии в коллективе он явно не уживется, к месту и не к месту напоминая «кем был Паниковский до Революции».
👋 Вариант 2. Соискатель действительно обладает всеми указанными квалификациями, но в силу определенных жизненных обстоятельств ищет любую работу. Это, конечно, с одной стороны похвально, но с другой создает работодателю массу иных проблем.
Основная из них – это временный сотрудник, как только он найдет работу, соответствующую его квалификации – он помашет вам ручкой. А вы снова будете искать себе сотрудника. Потом снова будете его учить и т.д. и т.п.
Поэтому снова нет, вне зависимости от вариантов.
👉 Продолжение следует...
Третьего дня попросил нас один заказчик помочь ему с подбором персонала. Задача для нас привычная, но последние несколько лет мы такими вещами как-то не занимались, поэтому оказалось достаточно интересно освежить свой опыт.
А коллегам, как мне кажется, будет полезно посмотреть на ситуацию глазами работодателя и, возможно, увидеть собственные ошибки при отклике на вакансии.
Сама вакансия предусматривает закрытие линейной должности системного администратора, основная задача которого – это обслуживание рабочих мест, включая офисное и торговое оборудование, а также поддержка пользователей (как удаленная, так и на месте).
Режим работы смешанный. Офис + удаленка. Плюс дежурства в выходные и праздничные дни, оплачиваются отдельно. Предлагаемая з/п по окладу в рынке, возможно даже и немного выше рынка для аналогичной должности.
На текущем этапе мы с представителем заказчика проработали только резюме, никаких личных контактов с соискателями не проводилось. Резюме было довольно много, но прошли не только лишь все. Вот именно о тех, кто сразу не прошел и поговорим.
1️⃣ Госы. Таких соискателей, надо сказать, много. Идут с аналогичных должностей из различных МУП, ГУП, администраций, учебных заведении и т.д. и т.п. Такие резюме сразу в мусорку. Ну разве что там будет молодой парень с первым и единственным местом работы, ну и тот станет в самый конец очереди.
Почему? Я уже давно и неоднократно писал, что госы – это кладбище кадров и человек проработавший там определенное время стремительно деградирует как специалист и командный сотрудник, но взамен приобретает многие иные качества, крайне нужные для выживания в госах, но бесполезные или даже откровенно вредные вне их.
При этом это не только мое мнение, но и мнение заказчика, где он несколько в ином ключе высказал практически аналогичные тезисы.
Даже если оставить сугубо профессиональные качества, то бывший сотрудник госов не способен к продуктивной командной работе, не умеет работать самостоятельно, предпочитает отлынивать от работы там, где это возможно, склонен к перекладыванию задач и ответственности, а также крайне негативно и разлагающе воздействует на рабочую атмосферу в коллективе.
😤 Написанное выше может вызвать массовое возгорание пятых точек, но увы, это так, во всяком случае со стороны коммерческого работодателя.
Что делать? Для начала понять и принять, что гос – для большинства работодателей черная метка. А там решайте, готовы ли вы что-то менять, причем менять радикально, или лучше спокойно досидеть, где сидится.
В противном случае берите подработки, просите рекомендации, ищите личные выходы. Через резюме найти работу будет достаточно затруднительно.
2️⃣ Оверквалификация. Таких резюме поменьше, но тоже хватает, и кого там только нет, чуть ли не кандидаты наук. Бывшие инженеры, программисты, руководители направлений и отделов. Послужные списки многих впечатляют.
Только вот с должностью, на которую они претендуют это соотносится крайне слабо. Что вызывает закономерные вопросы. На которые напрашиваются закономерные ответы.
🐏 Вариант 1. Соискатель на самом деле туп как бревно, а все эти регалии приписаны по принципу «рядом стоял, через плечо глядел». Либо просиживал стул на руководящей должности, а работали подчиненные.
После чего следует закономерный вывод – а нафига он тут такой красивый нужен? Даже если его квалификации и хватает для закрытия вакансии в коллективе он явно не уживется, к месту и не к месту напоминая «кем был Паниковский до Революции».
👋 Вариант 2. Соискатель действительно обладает всеми указанными квалификациями, но в силу определенных жизненных обстоятельств ищет любую работу. Это, конечно, с одной стороны похвально, но с другой создает работодателю массу иных проблем.
Основная из них – это временный сотрудник, как только он найдет работу, соответствующую его квалификации – он помашет вам ручкой. А вы снова будете искать себе сотрудника. Потом снова будете его учить и т.д. и т.п.
Поэтому снова нет, вне зависимости от вариантов.
👉 Продолжение следует...
👍47🤡20❤9😁2🤝2
Из пункта 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 с настройками брандмауэра по умолчанию этого не делает.
Как показывает практика – маршрутизация всегда была непростым вопросом, особенно если речь идет о маршрутизации между сетями. И чаще всего бывает так – я все сделал по инструкции, но ничего не работает.
Как быть, что делать, куда бежать? А бежать никуда не надо, надо просто взять в руки два простых инструмента и заняться диагностикой. Эти инструменты всем известны: пинг и трассировка.
Но прежде посмотрим на схему внизу материала. Где:
🔹 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 с настройками брандмауэра по умолчанию этого не делает.
👍28❤6