Про помогаторов
И в заключение нашего новогоднего цикла «за жизнь» рассмотрим еще один феномен – как помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиента, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет иметь мозги как у него все плохо и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть ни у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность, это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
И в заключение нашего новогоднего цикла «за жизнь» рассмотрим еще один феномен – как помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиента, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет иметь мозги как у него все плохо и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть ни у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность, это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет.
50👍78❤6👏4🌭2💯1
Ошибка: Не удалось записать RSA сертификат. Попробуйте еще раз
Достаточно редкая ошибка ЕГАИС и не все знают куда бежать и что делать. Прежде всего смотрим в лог, файл utm/transport/l/transport_info.log
И находим там строки:
Вместо трех может стоять другое число, по числу ошибочных сертификатов.
Проблема достаточно редкая и найти ее описание не просто, хотя оно есть в базе знания Рутокен: https://dev.rutoken.ru/display/KB/RU1009
Суть проблемы в том, что при формировании нового RSA-ключа старый не удаляется и возникает задвоение ключей, о чем и написано в логе. В результате на ключе оказывается три объекта: ГОСТ и 2 RSA ключа. Попытка ручного удаления RSA-ключей также завершается ошибкой.
Если вы будете продолжать попытки формирования ключа с помощью УТМ ЕГАИС дублей станет больше (и число в сообщении лога увеличится).
Решение простое – скачать и применить утилиту, указанную на странице базы знаний Рутокен.
Достаточно редкая ошибка ЕГАИС и не все знают куда бежать и что делать. Прежде всего смотрим в лог, файл utm/transport/l/transport_info.log
И находим там строки:
java.security.KeyStoreException: invalid KeyStore state: found 3 private keys sharing
Вместо трех может стоять другое число, по числу ошибочных сертификатов.
Проблема достаточно редкая и найти ее описание не просто, хотя оно есть в базе знания Рутокен: https://dev.rutoken.ru/display/KB/RU1009
Суть проблемы в том, что при формировании нового RSA-ключа старый не удаляется и возникает задвоение ключей, о чем и написано в логе. В результате на ключе оказывается три объекта: ГОСТ и 2 RSA ключа. Попытка ручного удаления RSA-ключей также завершается ошибкой.
Если вы будете продолжать попытки формирования ключа с помощью УТМ ЕГАИС дублей станет больше (и число в сообщении лога увеличится).
Решение простое – скачать и применить утилиту, указанную на странице базы знаний Рутокен.
👍43🔥4❤1🤮1🌭1
Еще раз про «соединения» WireGuard
Очень часто от коллег, да и в материалах в сети можно встретить упоминания о «соединениях», «подключениях» или «переподключениях» относительно WireGuard, что создает неправильное и искаженное восприятие происходящих процессов.
Это сильно мешает пониманию работы протокола, отладке и поиску неисправностей. Поэтому давайте разберемся как работает WireGuard на самом деле.
Протокол изначально разрабатывался с прицелом на простоту и эффективность, поэтому он делает одно дело, но делает его хорошо – а именно устанавливает защищенный туннель между двумя узлами.
Туннель WireGuard относится к туннелям без сохранения состояния (stateless), так же, как и туннели GRE или IP-IP. Это означает, что он не запоминает предыдущего состояния и не имеет никакого представления о состоянии противоположного узла.
Тем более, что в качестве транспорта используется UDP – транспортный протокол без подтверждения доставки.
В момент запуска службы WireGuard читает конфигурационные файлы и создает туннельные интерфейсы, если конфигурация не содержит ошибок, то интерфейс переходит в состояние Активен (UP) вне зависимости от состояние противоположной стороны.
И это произойдет даже в том случае, если противоположный узел выключен или недоступен. Косвенно о работе туннеля можно судить по времени с последнего рукопожатия (handshake), однако это очень и очень косвенный признак.
Например, при блокировках данного протокола у операторов связи рукопожатия могут проходить, но сам трафик в туннеле не ходит, но сам интерфейс будет показывать вам что все отлично и с точки зрения WireGuard это действительно так.
Его задача получить пакет, попадающий под одно из правил криптографической маршрутизации (не путать с маршрутизацией пакетов L3), зашифровать нужным ключом и отправить противоположному узлу (peer).
А дойдет пакет или не дойдет локальный экземпляр WireGuard не волнует, у него все хорошо, он работает. Точно также и с входящими пакетами, если пакет подпадает под правила – расшифровываем, нет – отбрасываем.
Погодите, погодите, а как же «WireGuard-сервер», адрес которого мы указываем в настройках «клиента»?
Мы не даром взяли эти термины в кавычки, на самом деле их использование некорректно. Все узлы WireGuard равнозначны и самодостаточны. Тот узел, который инициирует подключение называется инициатором, тот, который его принимает – ответчиком или респондером.
Один и тот же узел может быть и ответчиком и респондером одновременно. Но классического соединения в понимании сеанса связи не устанавливается.
Инициатор и ответчик выполняют рукопожатие, формируют общий ключ и забывают друг о друге.
Затем, получив пакет попадающий под правила криптографической маршрутизации узел проверяет срок действия ключа, при необходимости выполняет повторное рукопожатие и формирование нового ключа и отправляет пакет противоположному узлу, после чего полностью забывает про него.
Получили ответ хорошо, нет – тоже хорошо. WireGuard это не волнует, эти вопросы должно решать сетевое ПО, которое использует туннель.
А как же опция persistent-keepalive? Но она также никак не связана с «поддержанием» соединения. Ее задача совсем в ином. Если инициатор находится за NAT, то при первом обращении к ответчику в брандмауэре создается установленное соединение (ESTABLISHED) и формируются таблицы трансляции NAT.
Если после этого в туннеле не было активности, то соединение в брандмауэре будет закрыто по истечению таймаута, также будет очищена таблица трансляции и все входящие пакеты от ответчика будут отброшены, также ответчик не сможет инициировать новое рукопожатие.
Внешне это будет выглядеть как отвал пира инициатора со стороны ответчика. При первом же пакете от инициатора к ответчику связь снова будет восстановлена.
Для сохранения состояния брандмауэра и таблиц трансляции WireGuard может отправлять ответчику нулевой пакет через промежуток времени указанный в опции persistent-keepalive.
Очень часто от коллег, да и в материалах в сети можно встретить упоминания о «соединениях», «подключениях» или «переподключениях» относительно WireGuard, что создает неправильное и искаженное восприятие происходящих процессов.
Это сильно мешает пониманию работы протокола, отладке и поиску неисправностей. Поэтому давайте разберемся как работает WireGuard на самом деле.
Протокол изначально разрабатывался с прицелом на простоту и эффективность, поэтому он делает одно дело, но делает его хорошо – а именно устанавливает защищенный туннель между двумя узлами.
Туннель WireGuard относится к туннелям без сохранения состояния (stateless), так же, как и туннели GRE или IP-IP. Это означает, что он не запоминает предыдущего состояния и не имеет никакого представления о состоянии противоположного узла.
Тем более, что в качестве транспорта используется UDP – транспортный протокол без подтверждения доставки.
В момент запуска службы WireGuard читает конфигурационные файлы и создает туннельные интерфейсы, если конфигурация не содержит ошибок, то интерфейс переходит в состояние Активен (UP) вне зависимости от состояние противоположной стороны.
И это произойдет даже в том случае, если противоположный узел выключен или недоступен. Косвенно о работе туннеля можно судить по времени с последнего рукопожатия (handshake), однако это очень и очень косвенный признак.
Например, при блокировках данного протокола у операторов связи рукопожатия могут проходить, но сам трафик в туннеле не ходит, но сам интерфейс будет показывать вам что все отлично и с точки зрения WireGuard это действительно так.
Его задача получить пакет, попадающий под одно из правил криптографической маршрутизации (не путать с маршрутизацией пакетов L3), зашифровать нужным ключом и отправить противоположному узлу (peer).
А дойдет пакет или не дойдет локальный экземпляр WireGuard не волнует, у него все хорошо, он работает. Точно также и с входящими пакетами, если пакет подпадает под правила – расшифровываем, нет – отбрасываем.
Погодите, погодите, а как же «WireGuard-сервер», адрес которого мы указываем в настройках «клиента»?
Мы не даром взяли эти термины в кавычки, на самом деле их использование некорректно. Все узлы WireGuard равнозначны и самодостаточны. Тот узел, который инициирует подключение называется инициатором, тот, который его принимает – ответчиком или респондером.
Один и тот же узел может быть и ответчиком и респондером одновременно. Но классического соединения в понимании сеанса связи не устанавливается.
Инициатор и ответчик выполняют рукопожатие, формируют общий ключ и забывают друг о друге.
Затем, получив пакет попадающий под правила криптографической маршрутизации узел проверяет срок действия ключа, при необходимости выполняет повторное рукопожатие и формирование нового ключа и отправляет пакет противоположному узлу, после чего полностью забывает про него.
Получили ответ хорошо, нет – тоже хорошо. WireGuard это не волнует, эти вопросы должно решать сетевое ПО, которое использует туннель.
А как же опция persistent-keepalive? Но она также никак не связана с «поддержанием» соединения. Ее задача совсем в ином. Если инициатор находится за NAT, то при первом обращении к ответчику в брандмауэре создается установленное соединение (ESTABLISHED) и формируются таблицы трансляции NAT.
Если после этого в туннеле не было активности, то соединение в брандмауэре будет закрыто по истечению таймаута, также будет очищена таблица трансляции и все входящие пакеты от ответчика будут отброшены, также ответчик не сможет инициировать новое рукопожатие.
Внешне это будет выглядеть как отвал пира инициатора со стороны ответчика. При первом же пакете от инициатора к ответчику связь снова будет восстановлена.
Для сохранения состояния брандмауэра и таблиц трансляции WireGuard может отправлять ответчику нулевой пакет через промежуток времени указанный в опции persistent-keepalive.
👍90❤7⚡1😁1
Довольно поучительная история про GPL и коммерческих производителей.
Правозащитная организация Software Freedom Conservancy (SFC), предоставляющая юридическую защиту свободным проектам и отстаивающая необходимость соблюдения лицензии GPL, объявила об успешном завершении судебного разбирательства с компанией AVM, связанного с невыполнением условий лицензии LGPL в прошивках маршрутизаторов. Дело было открыто в немецком суде по иску Себастьяна Штека (Sebastian Steck), потребовавшего предоставить исходный код компонентов прошивки, распространяемых под лицензией LGPLv2.1, а также скриптов, используемых для их компиляции и установки.
Поводом для подачи иска стал отказ компании AVM предоставить полный исходный код библиотек, задействованных в прошивке беспроводного маршрутизатора AVM FRITZ!Box 4020. Как потребитель, купивший данное устройство, Себастьян запросил доступ к коду компонентов, основанных на открытых библиотеках uClibc, libblkid, libexif и libosip2, изначально распространяемых под лицензией LGPL и, среди прочего, применяемых в прошивке для организации ведения журнала передачи данных. В ответ компания AVM предоставила неполные исходные тексты библиотек, которые не могли быть скомпилированы и использованы в прошивке.
В досудебном порядке было предпринято несколько попыток убедить AVM выполнить условия лицензии LGPL, но компания отказалась предоставлять полный код. В июле 2023 года был подан судебный иск, который летом 2024 года был удовлетворён судом, так как ответчик не смог обосновать свой отказ выполнить условия LGPL. Две недели назад истёк срок подачи апелляции. Компания AVM не стала оспаривать решение, передала истцу код запрошенных компонентов прошивки и оплатила судебные издержки.
В суде компания AVM заявляла, что кода, предоставленного в ответ на первый запрос, достаточно для внесения изменений в оперативной памяти. Истец настаивал на том, что потребитель должен иметь возможность установки изменений на уровне прошивки, хранящейся во Flash-памяти. Суд встал на сторону истца, и компания AVM предоставила информацию, необходимую для внесения изменений, сохраняемых после перезагрузки.
В целом и у нас есть непаханое поле, особенно на фоне импортозамещения, только вот правоприменительная практика совсем другая 😢
Правозащитная организация Software Freedom Conservancy (SFC), предоставляющая юридическую защиту свободным проектам и отстаивающая необходимость соблюдения лицензии GPL, объявила об успешном завершении судебного разбирательства с компанией AVM, связанного с невыполнением условий лицензии LGPL в прошивках маршрутизаторов. Дело было открыто в немецком суде по иску Себастьяна Штека (Sebastian Steck), потребовавшего предоставить исходный код компонентов прошивки, распространяемых под лицензией LGPLv2.1, а также скриптов, используемых для их компиляции и установки.
Поводом для подачи иска стал отказ компании AVM предоставить полный исходный код библиотек, задействованных в прошивке беспроводного маршрутизатора AVM FRITZ!Box 4020. Как потребитель, купивший данное устройство, Себастьян запросил доступ к коду компонентов, основанных на открытых библиотеках uClibc, libblkid, libexif и libosip2, изначально распространяемых под лицензией LGPL и, среди прочего, применяемых в прошивке для организации ведения журнала передачи данных. В ответ компания AVM предоставила неполные исходные тексты библиотек, которые не могли быть скомпилированы и использованы в прошивке.
В досудебном порядке было предпринято несколько попыток убедить AVM выполнить условия лицензии LGPL, но компания отказалась предоставлять полный код. В июле 2023 года был подан судебный иск, который летом 2024 года был удовлетворён судом, так как ответчик не смог обосновать свой отказ выполнить условия LGPL. Две недели назад истёк срок подачи апелляции. Компания AVM не стала оспаривать решение, передала истцу код запрошенных компонентов прошивки и оплатила судебные издержки.
В суде компания AVM заявляла, что кода, предоставленного в ответ на первый запрос, достаточно для внесения изменений в оперативной памяти. Истец настаивал на том, что потребитель должен иметь возможность установки изменений на уровне прошивки, хранящейся во Flash-памяти. Суд встал на сторону истца, и компания AVM предоставила информацию, необходимую для внесения изменений, сохраняемых после перезагрузки.
В целом и у нас есть непаханое поле, особенно на фоне импортозамещения, только вот правоприменительная практика совсем другая 😢
👍25👀8🔥2🤔2
Поддержим молодых авторов
Не так давно на дружественном нам канале https://t.me/srv_admin автор выступил с инициативой поддержки молодых авторов. Мы также изъявили желание принять посильное участие в этом проекте.
На самом деле проблема качественного технического контента в русскоязычном сегменте сети стоит достаточно остро. Количество авторских сайтов, самостоятельно производящих уникальный контент можно буквально посчитать по пальцам.
Причин этому много, в первую очередь то, что любой подобный проект начинается на энтузиазме, но очень скоро «любовная лодка разбивается о быт». Подготовка качественных материалов требует много времени и его придется забирать либо у работы, либо у семьи.
Поэтому важно вовремя найти баланс и подвести под данный вид деятельности экономическую базу. Проще говоря – монетизировать проект.
Ничего зазорного в этом нет. Человек тратит свое время, делится своими знаниями, причем делает это в удобной и понятной для восприятия читателями форме. И получать разумное вознаграждение за такую деятельность – это нормально. Вы приносите пользу читателям, читатели благодарят вас материально.
Как отблагодарить? Прежде всего добавьте сайт в закладки и отключите блокировщик рекламы. Нравится вам она или нет, но именно реклама является основным источником дохода статейного сайта.
При этом и я, и большинство моих коллег размещаем только белую рекламу и только в приемлемых формах. Которая не мешает просмотру контента или которую можно легко закрыть.
Просто уважайте труд авторов, баннеры есть не просят и ни к чему вас не обязывают. А автор в конце месяца получит небольшую прибавку к семейному бюджету и избавится от назойливых вопросов жены «что ты там сидишь за своим компьютером, вынеси наконец елку».
Что еще можно сделать? Отправить донат. Но как показывает практика, данная схема у нас не работает. Культуры донатов как таковой у нас нет. Мы прикола ради каждый новый год считаем сумму донатов и она не превышает за год 5-6 тысяч рублей.
Если вы не готовы поддержать автора материально, то подпишитесь на его каналы и группы, а также включитесь в обсуждение или оценку материалов.
Потому как кроме материальной составляющей очень важна обратная связь от читателя, не важно, восторженная или критическая. Без такой связи появляется ощущение того, что пишешь в стол, что резко снижает, точнее даже убивает желание писать что-то дальше.
Просто подпишитесь, комментируйте, задавайте вопросы, ставьте реакции. Это важно, особенно для начинающих авторов. На этом этапе признание важнее, чем материальная часть и это видно по многим ресурсам, которые мы вам представим.
Но и материальная часть важна. Без рабочей бизнес-модели сайт очень скоро станет обузой и с очень большой долей вероятности будет заброшен и забыт. Примеров тому множество.
Не так давно на дружественном нам канале https://t.me/srv_admin автор выступил с инициативой поддержки молодых авторов. Мы также изъявили желание принять посильное участие в этом проекте.
На самом деле проблема качественного технического контента в русскоязычном сегменте сети стоит достаточно остро. Количество авторских сайтов, самостоятельно производящих уникальный контент можно буквально посчитать по пальцам.
Причин этому много, в первую очередь то, что любой подобный проект начинается на энтузиазме, но очень скоро «любовная лодка разбивается о быт». Подготовка качественных материалов требует много времени и его придется забирать либо у работы, либо у семьи.
Поэтому важно вовремя найти баланс и подвести под данный вид деятельности экономическую базу. Проще говоря – монетизировать проект.
Ничего зазорного в этом нет. Человек тратит свое время, делится своими знаниями, причем делает это в удобной и понятной для восприятия читателями форме. И получать разумное вознаграждение за такую деятельность – это нормально. Вы приносите пользу читателям, читатели благодарят вас материально.
Как отблагодарить? Прежде всего добавьте сайт в закладки и отключите блокировщик рекламы. Нравится вам она или нет, но именно реклама является основным источником дохода статейного сайта.
При этом и я, и большинство моих коллег размещаем только белую рекламу и только в приемлемых формах. Которая не мешает просмотру контента или которую можно легко закрыть.
Просто уважайте труд авторов, баннеры есть не просят и ни к чему вас не обязывают. А автор в конце месяца получит небольшую прибавку к семейному бюджету и избавится от назойливых вопросов жены «что ты там сидишь за своим компьютером, вынеси наконец елку».
Что еще можно сделать? Отправить донат. Но как показывает практика, данная схема у нас не работает. Культуры донатов как таковой у нас нет. Мы прикола ради каждый новый год считаем сумму донатов и она не превышает за год 5-6 тысяч рублей.
Если вы не готовы поддержать автора материально, то подпишитесь на его каналы и группы, а также включитесь в обсуждение или оценку материалов.
Потому как кроме материальной составляющей очень важна обратная связь от читателя, не важно, восторженная или критическая. Без такой связи появляется ощущение того, что пишешь в стол, что резко снижает, точнее даже убивает желание писать что-то дальше.
Просто подпишитесь, комментируйте, задавайте вопросы, ставьте реакции. Это важно, особенно для начинающих авторов. На этом этапе признание важнее, чем материальная часть и это видно по многим ресурсам, которые мы вам представим.
Но и материальная часть важна. Без рабочей бизнес-модели сайт очень скоро станет обузой и с очень большой долей вероятности будет заброшен и забыт. Примеров тому множество.
👍75❤5💯3
Вороний блог
✅ https://r4ven.me
Сайт Ивана Черного, в основном посвящен Linux, но не только, есть статьи на околотехнические темы, нескучные обои и все такое прочее.
Проект авторский, кроме сайта автор ведет телеграм-канал. Статьи отличаются достаточным уровнем проработки, отлично структурированы и оформлены. Написаны грамотным русским языком, также присутствует авторский стиль изложения.
Ресурс интересный, провел на нем достаточно много времени за чтением материалов. Рекламы и формы для донатов не обнаружено, т.е. проект в настоящее время ведется исключительно на энтузиазме автора.
Из недостатков – очень медленный хостинг, сайт может грузиться очень медленно, долго прогружаются картинки. Надеемся, что по мере роста популярности автор предпримет что-то для решения данного вопроса.
✅ https://r4ven.me
Сайт Ивана Черного, в основном посвящен Linux, но не только, есть статьи на околотехнические темы, нескучные обои и все такое прочее.
Проект авторский, кроме сайта автор ведет телеграм-канал. Статьи отличаются достаточным уровнем проработки, отлично структурированы и оформлены. Написаны грамотным русским языком, также присутствует авторский стиль изложения.
Ресурс интересный, провел на нем достаточно много времени за чтением материалов. Рекламы и формы для донатов не обнаружено, т.е. проект в настоящее время ведется исключительно на энтузиазме автора.
Из недостатков – очень медленный хостинг, сайт может грузиться очень медленно, долго прогружаются картинки. Надеемся, что по мере роста популярности автор предпримет что-то для решения данного вопроса.
👍63❤2
Sysadminium - База знаний системного администратора
✅ https://sysadminium.ru
Еще один очень неплохой авторский ресурс. Основные темы Windows, Linux, Proxmox, 1С, сети. Статьи небольшие, но без воды, по существу поднятых в них вопросов. Несколько раз за последнее время статьи этого сайта попадались мне в поисковой выдаче по ряду запросов.
Радует уважительное отношение автора к своим коллегам по перу, многие статьи представляют из себя компиляции материалов других авторов, в т.ч. и наших, но везде корректно проставлены активные открытые ссылки на источники.
Ресурс не только интересный, но и практически полезный. Из внешних ресурсов есть только ссылка на группу VK. Из монетизации скромный рекламный блок внизу экрана. Возможности отправить донат нет.
✅ https://sysadminium.ru
Еще один очень неплохой авторский ресурс. Основные темы Windows, Linux, Proxmox, 1С, сети. Статьи небольшие, но без воды, по существу поднятых в них вопросов. Несколько раз за последнее время статьи этого сайта попадались мне в поисковой выдаче по ряду запросов.
Радует уважительное отношение автора к своим коллегам по перу, многие статьи представляют из себя компиляции материалов других авторов, в т.ч. и наших, но везде корректно проставлены активные открытые ссылки на источники.
Ресурс не только интересный, но и практически полезный. Из внешних ресурсов есть только ссылка на группу VK. Из монетизации скромный рекламный блок внизу экрана. Возможности отправить донат нет.
👍92🤔2❤1
PC360 Ремонт/настройка ПК и окружающих его устройств.
✅ https://www.pc360.ru
Очередной сайт в нашем обзоре начинающих авторов. Ведется с 2017 года, в настоящий момент содержит около 130 статей. Тематика – ПК, сети, безопасность, много вопросов уделяется Mikrotik.
Статьи в большинстве своем достаточно подробные и объемные, много рисунков, схем, фотографий. Везде подробно указаны все действия, на схемах и изображениях присутствуют номера и стрелочки.
Дизайн сайта простой и непритязательный, в недостатки можно добавить разве что навигацию, например, очень не помешала бы разбивка по разделам.
На страничке «О сайте» и на странице обратной связи есть кнопка по которой можно отправить донат, рекламы нет.
✅ https://www.pc360.ru
Очередной сайт в нашем обзоре начинающих авторов. Ведется с 2017 года, в настоящий момент содержит около 130 статей. Тематика – ПК, сети, безопасность, много вопросов уделяется Mikrotik.
Статьи в большинстве своем достаточно подробные и объемные, много рисунков, схем, фотографий. Везде подробно указаны все действия, на схемах и изображениях присутствуют номера и стрелочки.
Дизайн сайта простой и непритязательный, в недостатки можно добавить разве что навигацию, например, очень не помешала бы разбивка по разделам.
На страничке «О сайте» и на странице обратной связи есть кнопка по которой можно отправить донат, рекламы нет.
👍41🔥4❤1
Настраиваем веб-сервер Caddy + PHP + MySQL с сертификатами Let's Encrypt
Веб-сервер Caddy сравнительно молодой и новый игрок на рынке веб-серверов, первый выпуск был опубликован в 2015 году, а используемая сейчас вторая версия вышла в 2020 году.
Caddy написан на Go и активно развивается, в его основе лежат современные подходы к реализации веб-серверов, а именно простота и защищенность.
В отличие от других веб-серверов Caddy из коробки рассчитан на работу с HTTPS и имеет интеграцию с Let's Encrypt, позволяя автоматически получать и продлять сертификаты, а также он весьма прост в настройке, в чем мы скоро убедимся.
https://interface31.ru/tech_it/2025/01/nastraivaem-veb-server-caddy-php-mysql-s-sertifikatami-lets-encrypt.html
Веб-сервер Caddy сравнительно молодой и новый игрок на рынке веб-серверов, первый выпуск был опубликован в 2015 году, а используемая сейчас вторая версия вышла в 2020 году.
Caddy написан на Go и активно развивается, в его основе лежат современные подходы к реализации веб-серверов, а именно простота и защищенность.
В отличие от других веб-серверов Caddy из коробки рассчитан на работу с HTTPS и имеет интеграцию с Let's Encrypt, позволяя автоматически получать и продлять сертификаты, а также он весьма прост в настройке, в чем мы скоро убедимся.
https://interface31.ru/tech_it/2025/01/nastraivaem-veb-server-caddy-php-mysql-s-sertifikatami-lets-encrypt.html
👍41❤3
Про нейросети
Нейросети сейчас находятся на пике популярности и местами способны серьезно облегчить труд человека. Что касается нашей отрасли, то нейросети вполне успешно составляют конфигурационные файлы, пишут простые программы и скрипты и т.д. и т.п.
Естественно, что у специалистов это вызывает некоторые опасения, ну а как сети полностью заменят человека, особенно на рядовых, линейных позициях.
Подобные опасения высказывают и производители технического контента – авторы технических сайтов и каналов. Мол скоро такими темпами окажемся без читателя, кто будет переходить на сайты, если нейросеть ответит на все вопросы.
Но постараюсь вас успокоить. Как бы не развивались нейросети, человека заменить они не смогут и причина этому одна, но глобальная. Нейросеть не может производить новый контент, все что она делает – это компилирует уже известные ей данные. Что-то принципиально новое может создать только человек.
Также сеть не имеет критического мышления и скормить ей можно любую дичь, ровно как ту же самую дичь может выдать она сама.
У многих сетей есть крайне неприятная особенность – если она чего-то не знает, то она начинает активно додумывать, причем делает это местами очень правдоподобно. Причем, чем более узкий и специфический вопрос, тем чаще можно столкнуться с такими придумками.
Последние несколько дней мы работали над статьей о веб-сервере Caddy и последнее время мы любим привлекать к этому процессу еще и нейросети, причем стараемся задавать вопросы простым языком, присущим обычному пользователю.
Скажем, как настроить редирект, как включить сжатие и т.д. и т.п.
Что касается популярных NGINX или Apache, то проблем обычно нет, нейросети выдают вполне приличные результаты и поправлять их особо не приходится, разве что иногда могут выдавать устаревшие данные, но все равно большая часть ответов приходится в тему.
Но стоит сделать шаг чуть в сторону и начинается откровенная дичь. По Caddy информации достаточно мало, поэтому и нейросеть откровенно плавает в вопросе, но это половину беды, потому что она еще и активно придумывает, как бы это могло быть.
Поэтому мы практически ни на один вопрос не получили правильного ответа, но зато получили полотна текста с лютой дичью и ее подробным пояснением.
Скажем на вопрос «как включить сжатие» она выдала блок настроек для NGINX оформленный в синтаксисе Caddу, когда мы ей указали на сей прискорбный факт, то она сказала «ой, и правда». После чего заменила первую директиву на правильную, а остальные снова придумала.
И так практически везде и во всем. Поэтому чем более узкий и специфический вопрос, тем более бесполезна и даже вредна нейросеть.
Подобный эффект можно получить и спрашивая что-либо по языку 1С:Предприятия, сетка может просто взять оператор из другого языка, перевести его на русский, оформить в синтаксисе 1С и выдать за истину.
Поэтому человека она заменить не сможет ни в ближайшей перспективе, ни в отдаленной. Но и отрицать ее возможности также не стоит. Какие-то базовые, простые действия она вполне способна выполнять самостоятельно.
Но в любом случае нужен будет человек, который должен уметь правильно задавать ей вопросы и критически анализировать ответы, помня о том, что сеть может придумывать и ошибаться.
Фактически мы получили еще один инструмент, который в умелых руках способен стать хорошим помощником, а при бесконтрольном применении наделать дел. Ровно, как и молоток: можно забить гвоздь, а можно по пальцу попасть.
Что касается опасений, особенно со стороны коллег невысокой квалификации, то они вполне обоснованы. Но это не проблема нейросетей, это проблема технического прогресса в целом, который делал не нужными целые профессии, но при этот тут же создавал новые.
Да, сейчас нейросеть вполне может заменить каких-то рядовых сотрудников начального уровня, которые тот же простейший скрипт будут писать час при помощи гугла и отладчика. Но если кто тут и виноват, так это сам сотрудник.
В то же время появляется новая потребность – с этой самой сетью управляться, так что без работы никто точно не останется.
Нейросети сейчас находятся на пике популярности и местами способны серьезно облегчить труд человека. Что касается нашей отрасли, то нейросети вполне успешно составляют конфигурационные файлы, пишут простые программы и скрипты и т.д. и т.п.
Естественно, что у специалистов это вызывает некоторые опасения, ну а как сети полностью заменят человека, особенно на рядовых, линейных позициях.
Подобные опасения высказывают и производители технического контента – авторы технических сайтов и каналов. Мол скоро такими темпами окажемся без читателя, кто будет переходить на сайты, если нейросеть ответит на все вопросы.
Но постараюсь вас успокоить. Как бы не развивались нейросети, человека заменить они не смогут и причина этому одна, но глобальная. Нейросеть не может производить новый контент, все что она делает – это компилирует уже известные ей данные. Что-то принципиально новое может создать только человек.
Также сеть не имеет критического мышления и скормить ей можно любую дичь, ровно как ту же самую дичь может выдать она сама.
У многих сетей есть крайне неприятная особенность – если она чего-то не знает, то она начинает активно додумывать, причем делает это местами очень правдоподобно. Причем, чем более узкий и специфический вопрос, тем чаще можно столкнуться с такими придумками.
Последние несколько дней мы работали над статьей о веб-сервере Caddy и последнее время мы любим привлекать к этому процессу еще и нейросети, причем стараемся задавать вопросы простым языком, присущим обычному пользователю.
Скажем, как настроить редирект, как включить сжатие и т.д. и т.п.
Что касается популярных NGINX или Apache, то проблем обычно нет, нейросети выдают вполне приличные результаты и поправлять их особо не приходится, разве что иногда могут выдавать устаревшие данные, но все равно большая часть ответов приходится в тему.
Но стоит сделать шаг чуть в сторону и начинается откровенная дичь. По Caddy информации достаточно мало, поэтому и нейросеть откровенно плавает в вопросе, но это половину беды, потому что она еще и активно придумывает, как бы это могло быть.
Поэтому мы практически ни на один вопрос не получили правильного ответа, но зато получили полотна текста с лютой дичью и ее подробным пояснением.
Скажем на вопрос «как включить сжатие» она выдала блок настроек для NGINX оформленный в синтаксисе Caddу, когда мы ей указали на сей прискорбный факт, то она сказала «ой, и правда». После чего заменила первую директиву на правильную, а остальные снова придумала.
И так практически везде и во всем. Поэтому чем более узкий и специфический вопрос, тем более бесполезна и даже вредна нейросеть.
Подобный эффект можно получить и спрашивая что-либо по языку 1С:Предприятия, сетка может просто взять оператор из другого языка, перевести его на русский, оформить в синтаксисе 1С и выдать за истину.
Поэтому человека она заменить не сможет ни в ближайшей перспективе, ни в отдаленной. Но и отрицать ее возможности также не стоит. Какие-то базовые, простые действия она вполне способна выполнять самостоятельно.
Но в любом случае нужен будет человек, который должен уметь правильно задавать ей вопросы и критически анализировать ответы, помня о том, что сеть может придумывать и ошибаться.
Фактически мы получили еще один инструмент, который в умелых руках способен стать хорошим помощником, а при бесконтрольном применении наделать дел. Ровно, как и молоток: можно забить гвоздь, а можно по пальцу попасть.
Что касается опасений, особенно со стороны коллег невысокой квалификации, то они вполне обоснованы. Но это не проблема нейросетей, это проблема технического прогресса в целом, который делал не нужными целые профессии, но при этот тут же создавал новые.
Да, сейчас нейросеть вполне может заменить каких-то рядовых сотрудников начального уровня, которые тот же простейший скрипт будут писать час при помощи гугла и отладчика. Но если кто тут и виноват, так это сам сотрудник.
В то же время появляется новая потребность – с этой самой сетью управляться, так что без работы никто точно не останется.
👍30💯20❤2👌1
DevOpsLife
✅ https://devopslife.ru
Сайт Игоря Панарина из Орла, как понятно из названия – основная тематика сайта DevOps. Много статей про Docker, Kubernetes, Terraform. Также есть материалы по сетям и Linux.
В отличие от других админских ресурсов сайт более нишевой, но это как раз неплохо, хотя и не способствует широкой популярности. В тоже время если эта тема вам интересна, то ресурс может оказаться полезен.
Сам блог простенький, аккуратный по дизайну, реклама и возможность перевести донаты отсутствуют, но есть ссылка на телеграм-канал автора.
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://t.me/interface31/3702
✅ https://devopslife.ru
Сайт Игоря Панарина из Орла, как понятно из названия – основная тематика сайта DevOps. Много статей про Docker, Kubernetes, Terraform. Также есть материалы по сетям и Linux.
В отличие от других админских ресурсов сайт более нишевой, но это как раз неплохо, хотя и не способствует широкой популярности. В тоже время если эта тема вам интересна, то ресурс может оказаться полезен.
Сам блог простенький, аккуратный по дизайну, реклама и возможность перевести донаты отсутствуют, но есть ссылка на телеграм-канал автора.
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://t.me/interface31/3702
👍42🔥8❤2
В связи с переходом на новые ставки НДС снова как никогда актуально.
Обновление прошивки ККТ АТОЛ
В условиях постоянно меняющихся требований законодательства в сфере применения контрольно-кассовой техники очень важно своевременно обновлять прошивку онлайн-кассы.
Обычно для этого приглашают сторонних специалистов, но их работа далеко не бесплатна и одно дело если касс одна-две, а если десяток, да не один?
Но обновить прошивку ККТ несложно и самостоятельно, никаких секретных знаний там нет. Сегодня мы научим вас обновлять прошивку кассовых аппаратов АТОЛ на платформе 5.0.
https://interface31.ru/tech_it/2021/06/obnovlenie-proshivki-kkt-atol.html
Часть статьи про самостоятельное получение прошивки можно пропустить, сейчас прошивку можно получить только у партнеров АТОЛ при условии оплаченной подписки АТОЛ Connect ИТС.
Обновление прошивки ККТ АТОЛ
В условиях постоянно меняющихся требований законодательства в сфере применения контрольно-кассовой техники очень важно своевременно обновлять прошивку онлайн-кассы.
Обычно для этого приглашают сторонних специалистов, но их работа далеко не бесплатна и одно дело если касс одна-две, а если десяток, да не один?
Но обновить прошивку ККТ несложно и самостоятельно, никаких секретных знаний там нет. Сегодня мы научим вас обновлять прошивку кассовых аппаратов АТОЛ на платформе 5.0.
https://interface31.ru/tech_it/2021/06/obnovlenie-proshivki-kkt-atol.html
Часть статьи про самостоятельное получение прошивки можно пропустить, сейчас прошивку можно получить только у партнеров АТОЛ при условии оплаченной подписки АТОЛ Connect ИТС.
👍22🥱3
Личный сайт Александра Linux
✅ https://bafista.ru
Сайт созданный как личный блог о различных технологиях, с которыми сталкивается автор. Очень много материалов про NAS, в частности Synology, так же есть про Linux, Windows и немного про Mikrotik.
Материалы неплохо проработаны, иллюстрированы, многие статьи содержат видеоролики для любителей данного формата. В целом сайт заслуживает внимания, многие материалы выполнены по принципу решения конкретной проблемы или вопроса.
Есть реклама (немного) и возможность оставить донат, а также подписаться на телеграм-канал, VK или видеоканалы автора.
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://t.me/interface31/3702
✅ https://bafista.ru
Сайт созданный как личный блог о различных технологиях, с которыми сталкивается автор. Очень много материалов про NAS, в частности Synology, так же есть про Linux, Windows и немного про Mikrotik.
Материалы неплохо проработаны, иллюстрированы, многие статьи содержат видеоролики для любителей данного формата. В целом сайт заслуживает внимания, многие материалы выполнены по принципу решения конкретной проблемы или вопроса.
Есть реклама (немного) и возможность оставить донат, а также подписаться на телеграм-канал, VK или видеоканалы автора.
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://t.me/interface31/3702
👍51
Сегодня снова были вопросы...
Базовая настройка брандмауэра в Mikrotik
Межсетевой экран, он же брандмауэр или файрволл - важнейшая служба вашего роутера, отвечающая как за его безопасность, так и за безопасность всей сети.
Мы до сих пор не рассматривали базовую настройку брандмауэра в отрыве от общей настройки роутера, но как показала практика, многие администраторы откровенно плавают в этом вопросе и имеют некорректно или не оптимально настроенные системы.
Как минимум это выливается в повышенную нагрузку на оборудование, а в самом плохом варианте ставит под угрозу безопасность всей сети. Поэтому давайте отдельно разберемся в этом вопросе.
https://interface31.ru/tech_it/2022/12/bazovaya-nastroyka-brandmauera-v-mikrotik.html
Базовая настройка брандмауэра в Mikrotik
Межсетевой экран, он же брандмауэр или файрволл - важнейшая служба вашего роутера, отвечающая как за его безопасность, так и за безопасность всей сети.
Мы до сих пор не рассматривали базовую настройку брандмауэра в отрыве от общей настройки роутера, но как показала практика, многие администраторы откровенно плавают в этом вопросе и имеют некорректно или не оптимально настроенные системы.
Как минимум это выливается в повышенную нагрузку на оборудование, а в самом плохом варианте ставит под угрозу безопасность всей сети. Поэтому давайте отдельно разберемся в этом вопросе.
https://interface31.ru/tech_it/2022/12/bazovaya-nastroyka-brandmauera-v-mikrotik.html
👍29🔥4🥱3😁1👌1
Блог IT'шника
✅ https://bite-byte.ru
Блог Сергея Гультяева – системного администратора аутсорсинговой компании. Автор пишет о том, с чем сталкивается в работе, получается обо всем понемногу, какой-то основной тематики нет.
Здесь и немного 1С, и немного сетей, операционные системы, программы, а также разные специфические вещи, скажем как МЧД для ФСС. Надо не всем, но кому-то может оказаться полезным, так как по этой тематике вообще очень мало информации.
Блог сделан простенько и аккуратно, статьи варьируются от коротких заметок, до полноценных инструкций. Есть немного рекламы и возможность оставить донат.
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://t.me/interface31/3702
✅ https://bite-byte.ru
Блог Сергея Гультяева – системного администратора аутсорсинговой компании. Автор пишет о том, с чем сталкивается в работе, получается обо всем понемногу, какой-то основной тематики нет.
Здесь и немного 1С, и немного сетей, операционные системы, программы, а также разные специфические вещи, скажем как МЧД для ФСС. Надо не всем, но кому-то может оказаться полезным, так как по этой тематике вообще очень мало информации.
Блог сделан простенько и аккуратно, статьи варьируются от коротких заметок, до полноценных инструкций. Есть немного рекламы и возможность оставить донат.
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://t.me/interface31/3702
👍42
Система отслеживания состояния соединений conntrack, часть 1
Conntrack – важная часть сетевого стека Linux ответственная за определение сетевых соединений и связывания с ними конкретных пакетов. На основе состояния соединения строится логика работы брандмауэра netfilter, а также высокоуровневых интерфейсов к нему, таких как iptables и nftables.
Несмотря на видимую простоту с работой conntrack связано множество заблуждений и в этой заметке мы постараемся разобрать некоторые из них.
Прежде всего соединения conntrack, равно как и их состояния существуют сугубо в пределах брандмауэра и нигде более. Кроме того, это исключительно Linux-технология и в среде других ОС она не применима.
В рамках пользовательского пространства доступно четыре состояния, это всем известные NEW, ESTABLISHED, RELATED и INVALID.
Трассировка соединений происходит в цепочке PREROUTING или OUTPUT, если пакет был порожден локальным процессом. Первый пакет соединения получает статус NEW.
И вот здесь есть один важный момент, как conntrack определяет, что этот пакет первый. Например, для TCP мы можем ориентироваться на флаг SYN, но как быть с UDP, где каждый пакет, по сути, первый и последний?
Тут все просто, анализируется адрес и порт источника, адрес и порт приемника и если такой записи в таблице трассировщика нет, то пакет становится первый и ему присваивается состояние NEW.
Таким образом если в брандмауэр придет TCP пакет уже установленного соединения (без SYN), то conntrack все равно повесит ему состояние NEW и отправит дальше по цепочкам.
Это позволяет подхватывать уже установленные TCP-соединения если таблица трассировщика была утеряна (скажем мы перезагрузили роутер).
Что будет с пакетом NEW дальше? Он пойдет по цепочкам брандмауэра и будет либо пропущен, либо отброшен.
С отброшен все понятно, соединение было отвергнуто с нашей стороны и все повторные попытки соединения снова получат состояние NEW.
А вот если пакет был пропущен, то ему присваивается состояние ESTABLISHED? А вот и нет. Для перехода соединения в состояние ESTABLISHED требуется, чтобы через conntrack прошел ответ на этот пакет.
И только при наличии ответа узла состояние соединения перейдет в установленное – ESTABLISHED. Причем данное состояние устанавливается как для TCP, так и для UDP, хотя последний в принципе не подразумевает установление соединений.
Но, напоминаем, все эти соединения живут только внутри брандмауэра Linux и никак не отражаются в самих пакетах.
Для времени жизни UDP соединения используется таймаут, если за указанное в нем время через соединение не прошел ни один пакет – оно считается закрытым. Если пакет прошел – то таймаут сбрасывается и начинается новый отсчет.
С TCP все немного сложнее, при нормальном завершении соединения после получения FIN соединение в брандмауэре переходит в состояние TIME OUT (буферное время) и еще в течении некоторого времени считается ESTABLISHED. Это сделано для того, чтобы через брандмауэр могли пройти пакеты «застрявшие» где-то там по дороге.
Если соединение было закрыто по RST, то оно сразу переходит в состояние закрытого без выделения буферного времени.
При аварийном завершении TCP-соединения его состояние в conntrack будет ESTABLISHED до истечения тайм-аута.
Еще интереснее с ICMP, может ли ICMP быть ESTABLISHED? Может, и даже становится. Почему? Потому что многие типы ICMP подразумевают ответ на запрос. Поэтому пришедший ICMP пакет получит состояние NEW, а ответ на него переведет соединение в состояние ESTABLISHED.
Однако conntrack понимает, что дальнейшей передачи данных такое «соединение» не подразумевает и после прохождения ответного пакета через netfilter запись о соединении из таблицы трассировщика удаляется.
Conntrack – важная часть сетевого стека Linux ответственная за определение сетевых соединений и связывания с ними конкретных пакетов. На основе состояния соединения строится логика работы брандмауэра netfilter, а также высокоуровневых интерфейсов к нему, таких как iptables и nftables.
Несмотря на видимую простоту с работой conntrack связано множество заблуждений и в этой заметке мы постараемся разобрать некоторые из них.
Прежде всего соединения conntrack, равно как и их состояния существуют сугубо в пределах брандмауэра и нигде более. Кроме того, это исключительно Linux-технология и в среде других ОС она не применима.
В рамках пользовательского пространства доступно четыре состояния, это всем известные NEW, ESTABLISHED, RELATED и INVALID.
Трассировка соединений происходит в цепочке PREROUTING или OUTPUT, если пакет был порожден локальным процессом. Первый пакет соединения получает статус NEW.
И вот здесь есть один важный момент, как conntrack определяет, что этот пакет первый. Например, для TCP мы можем ориентироваться на флаг SYN, но как быть с UDP, где каждый пакет, по сути, первый и последний?
Тут все просто, анализируется адрес и порт источника, адрес и порт приемника и если такой записи в таблице трассировщика нет, то пакет становится первый и ему присваивается состояние NEW.
Таким образом если в брандмауэр придет TCP пакет уже установленного соединения (без SYN), то conntrack все равно повесит ему состояние NEW и отправит дальше по цепочкам.
Это позволяет подхватывать уже установленные TCP-соединения если таблица трассировщика была утеряна (скажем мы перезагрузили роутер).
Что будет с пакетом NEW дальше? Он пойдет по цепочкам брандмауэра и будет либо пропущен, либо отброшен.
С отброшен все понятно, соединение было отвергнуто с нашей стороны и все повторные попытки соединения снова получат состояние NEW.
А вот если пакет был пропущен, то ему присваивается состояние ESTABLISHED? А вот и нет. Для перехода соединения в состояние ESTABLISHED требуется, чтобы через conntrack прошел ответ на этот пакет.
И только при наличии ответа узла состояние соединения перейдет в установленное – ESTABLISHED. Причем данное состояние устанавливается как для TCP, так и для UDP, хотя последний в принципе не подразумевает установление соединений.
Но, напоминаем, все эти соединения живут только внутри брандмауэра Linux и никак не отражаются в самих пакетах.
Для времени жизни UDP соединения используется таймаут, если за указанное в нем время через соединение не прошел ни один пакет – оно считается закрытым. Если пакет прошел – то таймаут сбрасывается и начинается новый отсчет.
С TCP все немного сложнее, при нормальном завершении соединения после получения FIN соединение в брандмауэре переходит в состояние TIME OUT (буферное время) и еще в течении некоторого времени считается ESTABLISHED. Это сделано для того, чтобы через брандмауэр могли пройти пакеты «застрявшие» где-то там по дороге.
Если соединение было закрыто по RST, то оно сразу переходит в состояние закрытого без выделения буферного времени.
При аварийном завершении TCP-соединения его состояние в conntrack будет ESTABLISHED до истечения тайм-аута.
Еще интереснее с ICMP, может ли ICMP быть ESTABLISHED? Может, и даже становится. Почему? Потому что многие типы ICMP подразумевают ответ на запрос. Поэтому пришедший ICMP пакет получит состояние NEW, а ответ на него переведет соединение в состояние ESTABLISHED.
Однако conntrack понимает, что дальнейшей передачи данных такое «соединение» не подразумевает и после прохождения ответного пакета через netfilter запись о соединении из таблицы трассировщика удаляется.
👍49🤔1🤡1
Блог Александра Марухина - Информационные технологии в моей жизни
✅ https://marukhin.ru
Автор блога Александр Марухин — специалист по безопасности информации и системный администратора крупной бюджетной организации.
Поэтому и тематика блога достаточно узкая и уникальная – он посвящен преимущественно Astra Linux.
Данная тематика сегодня, ввиду активного внедрения импортозамещения весьма актуальна, в тоже время наблюдается острый дефицит материалов на эту тему.
Здесь же собран хороший набор инструкций и советов от практика, что добавляет ценности блогу и размещенным на нем материалам.
Блог выполнен просто и аккуратно, статьи хорошо оформлены и иллюстрированы. Есть немного рекламы и форма для донатов.
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://t.me/interface31/3702
✅ https://marukhin.ru
Автор блога Александр Марухин — специалист по безопасности информации и системный администратора крупной бюджетной организации.
Поэтому и тематика блога достаточно узкая и уникальная – он посвящен преимущественно Astra Linux.
Данная тематика сегодня, ввиду активного внедрения импортозамещения весьма актуальна, в тоже время наблюдается острый дефицит материалов на эту тему.
Здесь же собран хороший набор инструкций и советов от практика, что добавляет ценности блогу и размещенным на нем материалам.
Блог выполнен просто и аккуратно, статьи хорошо оформлены и иллюстрированы. Есть немного рекламы и форма для донатов.
Данная заметка написана нами в поддержку начинающих авторов, почему это важно – можно прочитать здесь: https://t.me/interface31/3702
👍36⚡1🤡1