2025-01-19_215325.png
4.5 MB
Вчера себе сделал обоину на рабочий стол. Может кому-то пригодится, либо просто идея понравится. Я уже пару лет себе делаю обои на рабочий стол с календарём. По мне, так это очень удобно. Дополнительно добавил правописание метрик, так как постоянно путаю прописные и заглавные буквы. Если не перепроверю, обязательно с ошибкой напишу.
Думал, думал, что ещё добавить, но так и не придумал. На практике мне особо ничего больше не надо. По разным каналам гуляют шпаргалки с всевозможными командами на любые случаи в жизни системного администратора, но лично я ничем этим не пользуюсь настолько часто, чтобы нужно было на рабочий стол выносить. Ищу в заметках.
А вы как думаете, что ещё пригодилось бы на рабочем столе? Иногда простые советы или комментарии потом сильно упрощают жизнь. Я кое-что неизменно беру на вооружение. Было время, всякие системные метрики выносил, но они только отвлекают. Реальной необходимости в них нет. В трее есть текущая частота и температура процессора. К сожалению, на ноутах Thinkpad это необходимая информация.
К заметке прилагаю саму обоину, мой рабочий стол, как это выглядит на практике, и сами образцы, которые добавил к картинке, чтобы в к своей смогли добавить, если захотите.
Ну и раз уж такая тема зашла упомяну ещё одну вещь. Я когда обсуждал свой новый моник 27" 2К меня прям чуть ли не унизили тем, какой я старый и отсталый, работаю с одним моником, да ещё таким маленьким. Типа надо было брать либо здоровый, либо хотя бы 2. В конце года читал интересный отчёт небезызвестного Вастрика, где он рассказывал, как себе монитор выбирал. Он там тоже всякие варианты пробовал, но остановился на одном 32" мониторе. У него стол глубокий, так что взял 32", а так тоже к 27" примерялся.
На днях на эту же тему со знакомым айтишником общался, он мне тоже сказал, что ему подходит максимум 27" 2К, а больше всего нравится на 24 FullHD работать. Я теперь хоть успокоился. Сам работаю за 23.8" 1920x1200. Не надо никакие окна подгонять, масштабы менять. Мне для работы это идеальный размер. Ноут рядом лежит, но даже не раскрываю его. Второй экран не нужен.
Слаб я ещё в плане мнения окружающих. Требуется внешнее подтверждение адекватности, а то грустно становится. Не молодею же. Правда оба описанных примера тоже ~40 лет от роду😂 .
#разное
Думал, думал, что ещё добавить, но так и не придумал. На практике мне особо ничего больше не надо. По разным каналам гуляют шпаргалки с всевозможными командами на любые случаи в жизни системного администратора, но лично я ничем этим не пользуюсь настолько часто, чтобы нужно было на рабочий стол выносить. Ищу в заметках.
А вы как думаете, что ещё пригодилось бы на рабочем столе? Иногда простые советы или комментарии потом сильно упрощают жизнь. Я кое-что неизменно беру на вооружение. Было время, всякие системные метрики выносил, но они только отвлекают. Реальной необходимости в них нет. В трее есть текущая частота и температура процессора. К сожалению, на ноутах Thinkpad это необходимая информация.
К заметке прилагаю саму обоину, мой рабочий стол, как это выглядит на практике, и сами образцы, которые добавил к картинке, чтобы в к своей смогли добавить, если захотите.
Ну и раз уж такая тема зашла упомяну ещё одну вещь. Я когда обсуждал свой новый моник 27" 2К меня прям чуть ли не унизили тем, какой я старый и отсталый, работаю с одним моником, да ещё таким маленьким. Типа надо было брать либо здоровый, либо хотя бы 2. В конце года читал интересный отчёт небезызвестного Вастрика, где он рассказывал, как себе монитор выбирал. Он там тоже всякие варианты пробовал, но остановился на одном 32" мониторе. У него стол глубокий, так что взял 32", а так тоже к 27" примерялся.
На днях на эту же тему со знакомым айтишником общался, он мне тоже сказал, что ему подходит максимум 27" 2К, а больше всего нравится на 24 FullHD работать. Я теперь хоть успокоился. Сам работаю за 23.8" 1920x1200. Не надо никакие окна подгонять, масштабы менять. Мне для работы это идеальный размер. Ноут рядом лежит, но даже не раскрываю его. Второй экран не нужен.
Слаб я ещё в плане мнения окружающих. Требуется внешнее подтверждение адекватности, а то грустно становится. Не молодею же. Правда оба описанных примера тоже ~40 лет от роду
#разное
Please open Telegram to view this post
VIEW IN TELEGRAM
При использование популярной в Linux утилиты
Зачастую удобнее сразу указать имя процесса. Покажу на примере просмотра потоков процесса, о которых дальше пойдёт речь:
Увидели сразу PID процесса 525 и все его потоки с номерами SPID. Иногда бывает нужно посмотреть или сразу посчитать потоки во время отладки какого-то приложения, которое, к примеру, виснет по какой-то причине. Быстро считаем его потоки:
Обращаю внимание, что вывод с потоками будет больше, чем просто вывод списка процессов, которые тоже часто считают для задач мониторинга. На том же сервере в тот же момент:
Если есть какие-то проблемы с приложением, и не понятно, что именно тормозит, можно вывести нужные метрики с разбивкой на потоки. Это хорошо показать на примере Fail2ban с PID 508.
У Fail2ban может быть много фильтров, которые обрабатываются в разных потоках. И какой-то из них в случае лавинообразного разрастания лога может очень сильно нагружать систему. Зная PID и SPID можно посмотреть подробности потока:
Всю строку не привожу, так как самое интересное в начале. Тут видно, что указанный поток обрабатывает jail с именем wp-login. Больше информации покажет
Ещё более подробную информацию можно получить через strace. Он не только по PID может подключаться, но и по SPID:
Там будет виден и лог, который поток читает, и даже конкретные строки. На нагруженном сервере завалит консоль, так что лучше сразу в файл выводить и потом смотреть. Обычное перенаправление в файл не сработает, надо использовать ключ
Можно конкретизировать, что записывать. Например, для Fail2ban будут актуальны операции открытия файлов и чтения:
А для каких-то процессов будет иметь смысл следить за записью:
Подобная проверка с strace будет очень актуальна, когда у вас какой-то поток приложения, к примеру, обращается по сети к ресурсу, который недоступен. И запрос висит по таймауту хрен знает сколько времени. А у вас сам процесс из-за него тормозит или висит.
Трейсы в режиме реального времени можно посмотреть и в
Стандартные и относительно простые утилиты консоли Linux позволят продебажить и разобраться даже в сложных и неочевидных на первый взгляд ситуациях.
📌 Полезные ссылки по теме заметки дебага консольными утилитами:
▪️Примеры использования ps
▪️Анализ дисковой активности в Linux
▪️Узнаём, что конкретно тормозит в php коде
▪️Расследование фантомных чтений с диска
▪️Расследование тормозов php сайта с помощью perf
▪️Профилирование нагрузки в Linux
▪️Кто и как использует swap
▪️Анализируем нагрузку на диск с помощью perf-tools
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #perfomance
ps
чаще всего оперируешь PID процесса или грепаешь вывод по строке в имени процесса:# ps -p 524 -o %mem,%cpu,cmd
# ps ax | grep prometheus
Зачастую удобнее сразу указать имя процесса. Покажу на примере просмотра потоков процесса, о которых дальше пойдёт речь:
# ps -T -C prometheus
PID SPID TTY TIME CMD
525 525 ? 00:55:34 prometheus
525 803 ? 00:03:10 prometheus
525 808 ? 00:09:22 prometheus
525 1054 ? 00:08:44 prometheus
525 1113 ? 00:12:03 prometheus
525 1129 ? 00:10:42 prometheus
525 58983 ? 00:11:30 prometheus
Увидели сразу PID процесса 525 и все его потоки с номерами SPID. Иногда бывает нужно посмотреть или сразу посчитать потоки во время отладки какого-то приложения, которое, к примеру, виснет по какой-то причине. Быстро считаем его потоки:
# ps -T -C zabbix_server | wc -l
82
Обращаю внимание, что вывод с потоками будет больше, чем просто вывод списка процессов, которые тоже часто считают для задач мониторинга. На том же сервере в тот же момент:
# ps ax | grep zabbix_server | wc -l
59
Если есть какие-то проблемы с приложением, и не понятно, что именно тормозит, можно вывести нужные метрики с разбивкой на потоки. Это хорошо показать на примере Fail2ban с PID 508.
# ps -L -o spid,%mem,%cpu,cmd 508
SPID %MEM %CPU CMD
1070 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
1071 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
1072 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
1074 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
1075 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
1077 0.6 0.3 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
У Fail2ban может быть много фильтров, которые обрабатываются в разных потоках. И какой-то из них в случае лавинообразного разрастания лога может очень сильно нагружать систему. Зная PID и SPID можно посмотреть подробности потока:
# cat /proc/508/task/1077/stat
1077 (f2b/f.wp-login) ...................................
Всю строку не привожу, так как самое интересное в начале. Тут видно, что указанный поток обрабатывает jail с именем wp-login. Больше информации покажет
status
:# cat /proc/508/task/1077/status
Ещё более подробную информацию можно получить через strace. Он не только по PID может подключаться, но и по SPID:
# strace -p 1077
Там будет виден и лог, который поток читает, и даже конкретные строки. На нагруженном сервере завалит консоль, так что лучше сразу в файл выводить и потом смотреть. Обычное перенаправление в файл не сработает, надо использовать ключ
-o
:# strace -p 1077 -o ~/strace.out
Можно конкретизировать, что записывать. Например, для Fail2ban будут актуальны операции открытия файлов и чтения:
# strace -p 1077 -e trace=openat,read
А для каких-то процессов будет иметь смысл следить за записью:
# strace -p 1077 -e trace=write
Подобная проверка с strace будет очень актуальна, когда у вас какой-то поток приложения, к примеру, обращается по сети к ресурсу, который недоступен. И запрос висит по таймауту хрен знает сколько времени. А у вас сам процесс из-за него тормозит или висит.
Трейсы в режиме реального времени можно посмотреть и в
htop
. Выбираете нужный процесс или поток и нажимайте s. Если strace установлена в системе, то увидите её работу.Стандартные и относительно простые утилиты консоли Linux позволят продебажить и разобраться даже в сложных и неочевидных на первый взгляд ситуациях.
📌 Полезные ссылки по теме заметки дебага консольными утилитами:
▪️Примеры использования ps
▪️Анализ дисковой активности в Linux
▪️Узнаём, что конкретно тормозит в php коде
▪️Расследование фантомных чтений с диска
▪️Расследование тормозов php сайта с помощью perf
▪️Профилирование нагрузки в Linux
▪️Кто и как использует swap
▪️Анализируем нагрузку на диск с помощью perf-tools
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #perfomance
Вчера одной знакомой мошенники взломали учётную запись от Госуслуг. Причём сделали это таким запутанным способом, что я даже не уверен, что ломали именно их. Расскажу обо всём по порядку. Возможно кто-то с подобным сталкивался. Другим наука будет, чтобы предупредили знакомых и родственников.
1️⃣ 9 утра, человек едет в метро. Раздаётся звонок на телефон. Слышно плохо. Мошенники называют ФИО и адрес проживания. Говорят, что пришла посылка на почту рядом с домом. Чтобы забрать, надо привязать в почте свой номер телефона, на который придёт код подтверждения для забора посылки.
2️⃣ Приходит смс от Госуслуг. Тут первая странность. В смс текст: Для подтверждения смены номера введите код подтверждения: 1234. Не сообщайте никому! Странности тут две. Во-первых, коды подтверждения у Госуслуг 6-ти значные, а тут только 4 знака. Во-вторых, сейчас от Госуслуг приходит другой текст. В конце добавляют, что этот код спрашивают только мошенники. И при этом смс пришла от отправителя gosuslugi и легла в тот же чат, где все остальные смс от реального сервиса.
3️⃣ Человек называет код и тут же понимает, что это какая-то ерунда и обман. Она кладёт трубку, заходит через приложение Госуслуг на смартфоне и меняет пароль. Приходит смс для аутентификации и там 6 знаков и привычный текст.
4️⃣ Человек заходит в свою почту и там видит несколько подозрительных писем:
▪️Первое от реальных Госуслуг, где указано, что её номер введён в другой учётной записи.
▪️Второе фейковое от хостинга Aeza, отправленное с домена aeza_email, где указано, что для подтверждения почты нужно пройти по ссылке и активировать учётку. Тут я уже удивился, так как сначала вообще не понял, при чём тут Aeza. В письме странные ссылки через сокращатели. Не ходил по ним. Письмо точно фейк, потому что у меня есть письма от реальной Аезы. Они по-другому отправляют.
▪️Третье письмо подделано под шаблон Госуслуг. Там сказано, что кто-то совершил вход под вашей учётной записью. Указан IP адрес и расположение: Украина - г. Киев. И ниже указан номер тех. поддержки, куда предлагают позвонить, если это были не вы. Забегая вперёд скажу, что номер мошенников. Письмо отправлено с домена в зоне .org, похожего на госуслуги.
5️⃣ Человек звонит по этому номеру. Там сразу снимают трубку, как-будто ждали звонка. Мужчина без всякого акцента рассказал, что кто-то заходил в учётку, если это не вы, то надо срочно менять пароль и привязку телефона. А потом отложил трубку и судя по всему забыл отключить микрофон. Начал разговаривать матерясь с какой-то девушкой рядом, а та ему говорила, что надо что-то ещё, чтобы она сделала или ничего не получится.
6️⃣ Знакомая поняла, что это опять мошенники, положила трубку. Зашла с компьютера в Госуслуги, снова сменила пароль, убедилась, что привязан её мобильный номер. Для аутентификации все смски с кодами приходили к ней на смартфон.
Всё просмотрела в личном кабинете, вроде никаких изменений. В списке действий ровно одно подозрительное действие как раз после первого звонка, совершённое не с её IP адреса. При этом IP адрес московский. Выполнено действие - отключение входа с подтверждением. Что это значит, не очень понятно, так как подтверждение по телефону реально не отключили.
Вот такая странная история произошла. Ниже список писем в тот день и скрины фейкового письма с госуслуг и от Aeza. Вот последняя меня больше всего интересует. При чём тут вообще этот хостинг? Знакомая с ним никак не связана и вообще не знает, что это такое.
И второй момент. От чего в итоге был передан мошенникам код из 4-х знаков? У меня есть подозрение, что Госуслуги тут только прикрытие каких-то других дел. Я не знаю, можно ли подделать отправителя смс, чтобы его сообщение попало в папку или чат с реальными смс от Госуслуг. А может на смену номера там только 4 символа и остался старый шаблон. Но смена по какой-то причине не состоялась.
Кто-нибудь сталкивался с подобным? Что это может быть? Какая-то многоходовая махинация. Тут и посылка, и фейковые письма, и поддержка.
#security
▪️Первое от реальных Госуслуг, где указано, что её номер введён в другой учётной записи.
▪️Второе фейковое от хостинга Aeza, отправленное с домена aeza_email, где указано, что для подтверждения почты нужно пройти по ссылке и активировать учётку. Тут я уже удивился, так как сначала вообще не понял, при чём тут Aeza. В письме странные ссылки через сокращатели. Не ходил по ним. Письмо точно фейк, потому что у меня есть письма от реальной Аезы. Они по-другому отправляют.
▪️Третье письмо подделано под шаблон Госуслуг. Там сказано, что кто-то совершил вход под вашей учётной записью. Указан IP адрес и расположение: Украина - г. Киев. И ниже указан номер тех. поддержки, куда предлагают позвонить, если это были не вы. Забегая вперёд скажу, что номер мошенников. Письмо отправлено с домена в зоне .org, похожего на госуслуги.
Всё просмотрела в личном кабинете, вроде никаких изменений. В списке действий ровно одно подозрительное действие как раз после первого звонка, совершённое не с её IP адреса. При этом IP адрес московский. Выполнено действие - отключение входа с подтверждением. Что это значит, не очень понятно, так как подтверждение по телефону реально не отключили.
Вот такая странная история произошла. Ниже список писем в тот день и скрины фейкового письма с госуслуг и от Aeza. Вот последняя меня больше всего интересует. При чём тут вообще этот хостинг? Знакомая с ним никак не связана и вообще не знает, что это такое.
И второй момент. От чего в итоге был передан мошенникам код из 4-х знаков? У меня есть подозрение, что Госуслуги тут только прикрытие каких-то других дел. Я не знаю, можно ли подделать отправителя смс, чтобы его сообщение попало в папку или чат с реальными смс от Госуслуг. А может на смену номера там только 4 символа и остался старый шаблон. Но смена по какой-то причине не состоялась.
Кто-нибудь сталкивался с подобным? Что это может быть? Какая-то многоходовая махинация. Тут и посылка, и фейковые письма, и поддержка.
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Если у вас стоит задача собрать небольшое количество текстовых логов в одном месте, то городить современные решения типа Loki, ELK, Graylog избыточно. Это и долго, и разбираться надо, если не умеешь, и по ресурсам затратно. Предлагаю старую, простую и проверенную временем альтернативу - syslog-ng. Я этот софт давно знаю и использую по мере необходимости.
Покажу пример простой настройки, которую можно взять за основу и расширить при необходимости. Устанавливаем:
Если на машине уже был установлен rsyslog, то он будет удалён. Вместе они не работают, так как выполняют одну и ту же задачу в том числе по ведению локальных системных логов.
Открываем конфигурацию
Можно выбрать любой IP адрес сервера, порт и протокол. Я указал стандартный порт UDP 514 для протокола syslog. Никто не мешает использовать что-то другое. Например TCP 1000:
Переходим в папку
Файл назвал
Я создал объект d_mikrotik, который указывает на хранение логов в файле
С таким подходом удобно настраивать что, куда и по каким условиям писать. Можно несколько source указать с разными интерфейсами, протоколами и портами. Если у вас устройства разнесены по разным подсетям, то можно описать приём в два разных лог-файла логи от Mikrotik и от Linux систем:
По умолчанию syslog-ng работает от root, что не очень разумно и в данной задаче не нужно. Запустим его от пользователя syslog. Если вас это не беспокоит, то можно запускать и под root.
Добавляем в
В файле
на
Идём на конечное устройство настраивать отправку логов. В Mikrotik это делается в System ⇨ Logging ⇨ Actions. В remote указываете IP адрес сервера с syslog-ng.
В системах Linux с rsyslog достаточно в
и перезапустить его.
Получилось очень простое решение по централизованному сбору логов без аналитики, которое настраивается за 10 минут и не требует практически никаких особых ресурсов. На чём можно запустить Debian, там и будет работать.
Для просмотра логов через браузер можно использовать tailon, logdy, cockpit, webmin.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #syslog
Покажу пример простой настройки, которую можно взять за основу и расширить при необходимости. Устанавливаем:
# apt install syslog-ng
Если на машине уже был установлен rsyslog, то он будет удалён. Вместе они не работают, так как выполняют одну и ту же задачу в том числе по ведению локальных системных логов.
Открываем конфигурацию
/etc/syslog-ng/syslog-ng.conf
и добавляем один параметр, который позволит принимать логи по сети от других устройств и систем:source s_net { udp(ip(0.0.0.0) port(514)); };
Можно выбрать любой IP адрес сервера, порт и протокол. Я указал стандартный порт UDP 514 для протокола syslog. Никто не мешает использовать что-то другое. Например TCP 1000:
source s_net { TCP(ip(0.0.0.0) port(1000)); };
Переходим в папку
/etc/syslog-ng/conf.d
и создаём там конфиг для приёма логов, например, с Mikrotik:destination d_mikrotik { file("/var/log/_remote/mikrotik.log"); };
filter f_mikrotik { netmask("10.20.1.20/255.255.255.255"); };
log { source(s_net); filter(f_mikrotik); destination(d_mikrotik); };
Файл назвал
mikrotik.conf
. В syslog-ng объектный принцип описания конфигурации. Этот как раз то, почему я предпочитаю для таких задач использовать именно его, а не rsyslog. У последнего не такой удобный формат конфигурации.Я создал объект d_mikrotik, который указывает на хранение логов в файле
/var/log/_remote/mikrotik.log
. Далее я сделал фильтр f_mikrotik, где указал в качестве условия IP адрес роутера. Можно и всю подсеть добавить. И в завершении указал, как именно будем логировать. Берём источник s_net, то есть всё, что приходит на UDP 514, проверяем по фильтру f_mikrotik и пишем в d_mikrotik, то есть в указанный лог-файл. С таким подходом удобно настраивать что, куда и по каким условиям писать. Можно несколько source указать с разными интерфейсами, протоколами и портами. Если у вас устройства разнесены по разным подсетям, то можно описать приём в два разных лог-файла логи от Mikrotik и от Linux систем:
destination d_mikrotik { file("/var/log/_remote/mikrotik.log"); };
filter f_mikrotik { netmask("10.20.1.0/255.255.255.0"); };
log { source(s_net); filter(f_mikrotik); destination(d_mikrotik); };
destination d_linux { file("/var/log/_remote/linux.log"); };
filter f_linux { netmask("10.30.1.0/255.255.255.0"); };
log { source(s_net); filter(f_linux); destination(d_linux); };
По умолчанию syslog-ng работает от root, что не очень разумно и в данной задаче не нужно. Запустим его от пользователя syslog. Если вас это не беспокоит, то можно запускать и под root.
# useradd syslog -s /usr/sbin/nologin
# chown syslog /var/lib/syslog-ng /var/log/_remote
Добавляем в
/etc/default/syslog-ng
:SYSLOGNG_OPTS="-u syslog -g syslog"
if [ ! -e /var/lib/syslog-ng.pid ] then
touch /var/lib/syslog-ng.pid
fi
chown syslog /var/lib/syslog-ng.pid
chmod 0664 /var/lib/syslog-ng.pid
В файле
/etc/syslog-ng/syslog-ng.conf
меняем пользователя в параметрах:owner("root"); group("adm")
на
owner("syslog"); group("syslog")
Идём на конечное устройство настраивать отправку логов. В Mikrotik это делается в System ⇨ Logging ⇨ Actions. В remote указываете IP адрес сервера с syslog-ng.
В системах Linux с rsyslog достаточно в
/etc/rsyslog.conf
добавить параметр:*.* @10.20.1.5
и перезапустить его.
Получилось очень простое решение по централизованному сбору логов без аналитики, которое настраивается за 10 минут и не требует практически никаких особых ресурсов. На чём можно запустить Debian, там и будет работать.
Для просмотра логов через браузер можно использовать tailon, logdy, cockpit, webmin.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #syslog
Расскажу об одной банальной вещи. Возможно кому-то она поможет, если в голову не приходило такое решение.
Ночь - время для обслуживания и бэкапов. Хорошо, когда ты за ночное окно успеваешь всё сделать и перекинуть данные на бэкап сервера. Но рано или поздно ночного окна начинает не хватать, особенно если бэкапы льются через интернет. Решать вопрос лучше всего комплексно, уменьшая объём передаваемых данных и двигая сервер с бэкапами ближе к источнику.
Если перечисленное выше не приводит к желаемому результату, то я настраиваю ограничение трафика. Вопрос этот непростой, если подразумевать полноценную приоритизацию на основе типов данных. Если ты не занимаешься этим вопросом постоянно, то довольно муторно вникать во все нюансы. Но конкретно в этой задаче не придётся сильно погружаться, так как я предлагаю просто ограничить в определённое время полосу пропускания на основе IP адреса сервера с бэкапами. А это самый простой случай.
В Mikrotik такое ограничение можно настроить с помощью Simple Queue. В шлюзах на базе Linux с помощью tc из пакета iproute2. В других шлюзах и роутерах этот как-то по-другому может решаться.
Для нормальной настройки шейпирования, чтобы не мешать привычной дневной работе, нужно обязательно иметь мониторинг полосы пропускания. Тот же Zabbix или Prometheus без особых проблем решают в типовых ситуациях эти вопросы. Надо знать среднюю загрузку канала и разрешить бэкапам литься с такой скоростью, чтобы днём не было полной утилизации полосы пропускания.
Я обычно делаю отдельные дашборды в мониторинге с загрузкой канала, чтобы во-первых, быстро оценить среднюю дневную загрузку, во-вторых, чтобы потом удобно контролировать загрузку, если бэкапы в ночь не успевают скопироваться.
Делается всё это обычно для того, чтобы если до утра задержится копирование, не парализовать работу. Если бэкапы уже сильно не успевают заливаться и уходят в день, то надо что-то менять. Потому что даже с таким ограничением они мешают полноценной работе. У тебя полезная ёмкость канала уменьшается.
#network #backup
Ночь - время для обслуживания и бэкапов. Хорошо, когда ты за ночное окно успеваешь всё сделать и перекинуть данные на бэкап сервера. Но рано или поздно ночного окна начинает не хватать, особенно если бэкапы льются через интернет. Решать вопрос лучше всего комплексно, уменьшая объём передаваемых данных и двигая сервер с бэкапами ближе к источнику.
Если перечисленное выше не приводит к желаемому результату, то я настраиваю ограничение трафика. Вопрос этот непростой, если подразумевать полноценную приоритизацию на основе типов данных. Если ты не занимаешься этим вопросом постоянно, то довольно муторно вникать во все нюансы. Но конкретно в этой задаче не придётся сильно погружаться, так как я предлагаю просто ограничить в определённое время полосу пропускания на основе IP адреса сервера с бэкапами. А это самый простой случай.
В Mikrotik такое ограничение можно настроить с помощью Simple Queue. В шлюзах на базе Linux с помощью tc из пакета iproute2. В других шлюзах и роутерах этот как-то по-другому может решаться.
Для нормальной настройки шейпирования, чтобы не мешать привычной дневной работе, нужно обязательно иметь мониторинг полосы пропускания. Тот же Zabbix или Prometheus без особых проблем решают в типовых ситуациях эти вопросы. Надо знать среднюю загрузку канала и разрешить бэкапам литься с такой скоростью, чтобы днём не было полной утилизации полосы пропускания.
Я обычно делаю отдельные дашборды в мониторинге с загрузкой канала, чтобы во-первых, быстро оценить среднюю дневную загрузку, во-вторых, чтобы потом удобно контролировать загрузку, если бэкапы в ночь не успевают скопироваться.
Делается всё это обычно для того, чтобы если до утра задержится копирование, не парализовать работу. Если бэкапы уже сильно не успевают заливаться и уходят в день, то надо что-то менять. Потому что даже с таким ограничением они мешают полноценной работе. У тебя полезная ёмкость канала уменьшается.
#network #backup
Изучал на днях один инструмент и случайно наткнулся на информацию про Systemd.path - триггер на события в файловой системе. Удивился, что не знаком с этой функциональностью. Либо уже забыл это. Но сам точно не использовал. С помощью Systemd.path можно отслеживать изменения в файловой системе и выполнять какие-то действия на их основе.
Функциональность очень полезная. Сразу покажу на примере. Допустим, нам надо выполнить какое-то действие при изменении файла. Настраиваем сначала слежение за файлом. Создаём файл
Будем следить за изменением файла
Для теста и понимания, как это работает, настроил простейшее действие. Команда echo будет писать текущую дату перезапуска службы в файл
Убеждаемся, что первое выполнение службы было сделано в момент старта:
Должен был создаться файл
Такой вот простой и удобный механизм. В строку
В данном примере я использовал директиву слежения за записью в файл PathModified. Помимо неё есть другие:
◽️PathExists= реагирует на появление заданного файла или директории.
◽️PathExistsGlob= то же самое что и предыдущее, но можно использовать маски для имён.
◽️PathChanged= отличается от PathModified тем, что реагирует не на запись в файл, а на закрытие файла после записи.
◽️DirectoryNotEmpty= реагирует на появление файла в пустой директории.
📌 Другая полезная (и не очень) функциональность SystemD:
◽️Systemd timers как замена Cron
◽️Journald как замена Syslog
◽️Systemd-journal-remote - централизованное хранение логов
◽️Systemd-journal-gatewayd - просмотр логов через браузер
◽️Hostnamectl для просмотра информации о системе
◽️Systemd-resolved - кэширующий DNS сервер
◽️Параметры Systemd для приоритизации дисковых операций
◽️Ограничение потребления памяти с Systemd
◽️Синхронизация времени с помощью systemd-timesyncd
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#systemd
Функциональность очень полезная. Сразу покажу на примере. Допустим, нам надо выполнить какое-то действие при изменении файла. Настраиваем сначала слежение за файлом. Создаём файл
/etc/systemd/system/daemon.path
:[Unit]
Description=Watch /etc/daemon/daemon.conf for changes
[Path]
PathModified=/etc/daemon/daemon.conf
[Install]
WantedBy=multi-user.target
Будем следить за изменением файла
daemon.conf
. А если оно случится, перезапустим службу daemon.service. Для этого создаём саму службу в файле /etc/systemd/system/daemon.service
:[Unit]
Description=Restart Daemon Service
After=network.target
[Service]
Type=oneshot
ExecStart=sh -c "/usr/bin/echo daemon service restarted at `date` >> /etc/daemon/restart.date"
[Install]
RequiredBy=daemon.path
Для теста и понимания, как это работает, настроил простейшее действие. Команда echo будет писать текущую дату перезапуска службы в файл
/etc/daemon/restart.date
. Запускаем проверку и саму службу:# systemctl enable daemon.{path,service}
# systemctl start daemon.{path,service}
Убеждаемся, что первое выполнение службы было сделано в момент старта:
# systemctl status daemon.service
Должен был создаться файл
/etc/daemon/restart.date
. Теперь изменяем файл /etc/daemon/daemon.conf
и проверяем снова restart.date
. Там должна появиться новая строка с текстом daemon service restarted at и текущее время с датой.Такой вот простой и удобный механизм. В строку
ExecStart
вместо echo
можно указать любую команду или скрипт. Можете какую-то службу перезапускать или копировать куда-то файл при его изменении. Например, изменился TLS сертификат, можно его скопировать куда-то или перезапустить службу, которая его использует. Удобство тут в том, что всё логируется в systemd. И если у вас логи уже где-то хранятся и анализируются, то все события с path и service поедут туда автоматически и не надо отдельно об этом беспокоиться.В данном примере я использовал директиву слежения за записью в файл PathModified. Помимо неё есть другие:
◽️PathExists= реагирует на появление заданного файла или директории.
◽️PathExistsGlob= то же самое что и предыдущее, но можно использовать маски для имён.
◽️PathChanged= отличается от PathModified тем, что реагирует не на запись в файл, а на закрытие файла после записи.
◽️DirectoryNotEmpty= реагирует на появление файла в пустой директории.
📌 Другая полезная (и не очень) функциональность SystemD:
◽️Systemd timers как замена Cron
◽️Journald как замена Syslog
◽️Systemd-journal-remote - централизованное хранение логов
◽️Systemd-journal-gatewayd - просмотр логов через браузер
◽️Hostnamectl для просмотра информации о системе
◽️Systemd-resolved - кэширующий DNS сервер
◽️Параметры Systemd для приоритизации дисковых операций
◽️Ограничение потребления памяти с Systemd
◽️Синхронизация времени с помощью systemd-timesyncd
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#systemd
⇨ Authentik proxy outposts for Traefik, Docker and K8S
Судя по всему Authentik - самый популярный из бесплатных сервисов SSO. Про него последнее время попадается много материала. Указанное видео очень круто сделано. Автор по шагам показал, как настроить интеграцию Authentik с Docker, Traefik (только доступ в его веб интерфейс), Kubernetes. Для Docker настроен удалённый доступ к его сокету с аутентификацией через Authentik.
⇨ Authentik. Часть 2. Установка и обзор пользовательского интерфейса
⇨ Authentik. Часть 3. Аутентификация простых приложений
Тоже очередное видео про Authentik, только в данном случае на примере настройки аутентификации для сервисов, которые вообще её не имеют ни в каком виде. Для этого настраивается обратный прокси (Traefik), на котором осуществляется аутентификация с помощью Authentik.
🔥 Wazuh! Powerful, Open Source Endpoint Security Monitoring!
Очень основательный и подробный материал по настройке open source SIEM-системы - Wazuh. Тут и обзор и демонстрация возможностей, и установка, и настройка, и подключение агентов. И всё это подробно. Очень качественный материал.
⇨ Safeline WAF надежная защита для вашего сайта сервера и данных
Автор сделал обзор на бесплатную версию Safeline WAF, про которую я недавно писал.
⇨ Практика по HTTP API | Компьютерные сети 2025 - 15
⇨ HTTP API в Postman | Компьютерные сети 2025 - 16
Очередные уроки из бесплатного курса Андрея Созыкина по сетям. Автор показывает работу в программе Postman с HTTP API. Я, кстати, у себя на ноуте тоже обычно использую Postman, если надо много работать с API. Для одиночных запросов обычно использую curl.
⇨ Kutt URL Shortener: Easy Installation, Password Protection, and More!
Простенький обзор на небольшой сервис для сокращения ссылок со статистикой переходов по ним. В сервисе ничего особенного, но выглядит аккуратно и удобно.
⇨ Литературно-комиксовая зарисовка для любителей Mikrotik из современного словаря модных в IT слов
Теоретический доклад, который можно просто послушать, от системного администратора, devops инженера и любителя Mikrotik на тему применения всяких современных и модных штук в работе с сетями. Первые 15 минут мне не особо понравились, когда автор просто рассказывал известные вещи про devops. Дальше было более конкретно и интересно с примерами и описанием продуктов для бэкапа, мониторинга, логов и т.д.
⇨ Zellij - Powerful Productivity in your Terminal!
Подробный обзор программы Zellij - консольный мультиплексор, более современный и продвинутый аналог screen и tmux. Я пару раз писал про неё. Интересная штука, но лично я так и не стал пользоваться, так как пользуюсь не часто и в целом мне нет разницы что это - screen или tmux. Раньше использовал screen. Последнее время везде tmux ставлю.
⇨ GitLab CI/CD - Установка своего DOCKER GitLab Runner на LINUX
Продолжение серии уроков по использованию GitLab. Если вам интересна эта тема, то посмотрите предыдущие уроки автора. Их уже довольно много. Информация для новичков, даётся очень доступно, с теорией и практикой.
⇨ DeepSeek: Ваш персональный ИИ-помощник в мире технологий и не только
Обзор на китайский бесплатный аналог ChatGPT - DeepSeek. Автор в восторге от его работы. Рекомендует. Я лично не пользовался, но надо попробовать.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Authentik proxy outposts for Traefik, Docker and K8S
Check out Twingate and supercharge your security: https://bit.ly/3Y1OaZi
In this video, I will guide you through the process of using Authentik Proxy Outposts with Traefik, Docker, and Kubernetes. We'll dive into how to connect Authentik, a powerful open…
In this video, I will guide you through the process of using Authentik Proxy Outposts with Traefik, Docker, and Kubernetes. We'll dive into how to connect Authentik, a powerful open…
В выходной для разнообразия подниму тему, которая не относится к технической части, но тем не менее будет полезна любому специалисту. Последнее время смотрел много видео на тему того, как современные системные администраторы, devops инженеры и программисты ищут работу. Не знаю, зачем мне это надо. Сам работу искать не собираюсь. Было просто интересно.
По знаниям и техническим подробностям ничего говорить не буду, это и так известная информация, которую легко найти. Расскажу немного о другом. Причём не только со стороны соискателя, но и со стороны работодателя. У меня был опыт, и не очень маленький, когда нужно было закрывать вакансии сисадминов. Я составлял вакансии, проводил собеседования. Иногда прям на потоке по 5-6 человек в день. Довольно утомительное занятие. Тогда я понял, почему люди редко дают обратную связь, когда тебе отказывают. Мало того, что это банально занимает твоё время, так ещё и надо не забыть, почему конкретному человеку ты отказал. А когда было 10-15 собеседований, выбрал ты одного, остальным 14-ти уже трудно каждому написать и объяснить, почему не подошёл. Просто кто-то был лучше.
На собеседованиях часто задают примерно такие вопросы:
❓Какое у тебя было самое большое достижение на прошлой или ещё раньше, работе?
❓Какой был самый большой провал и какие из него были сделаны выводы?
❓Как развиваетесь, повышаете свои навыки? Что последнее изучили, внедрили новое?
Когда тебе надо искать работу и обновлять резюме, затруднительно всё это сразу вспомнить и хорошо написать. Вместо этого я вам советую вести своё резюме в режиме реального времени. Постоянно записывать свои достижения, провалы, полученные навыки, прохождение курсов или изучение чего-то нового пусть даже по видео из Youtube.
Готовый список из описанных событий позволит быстро скомпоновать резюме под конкретные задачи или вакансии. Не обязательно там писать сразу всё. Просто сядьте и подумайте, для какой компании или вакансии было бы уместно указать те или иные достижения. В резюме стоит писать только их. А остальные вещи просто держать в голове и освежать знания перед собеседованиями, чтобы быстро и уверенно ответить, а не судорожно вспоминать, где же я там накосячил и как рассказать так, чтобы мне в итоге не отказали и не посчитали нубасом. Уверенно рассказать про свои косяки и выводы, которые из этого были сделаны, дорого стоит. Сходу может и не получиться.
Кому-то может показаться, что он ничего особенного не делал и писать в достижениях нечего. Вряд ли это так на самом деле, если вы реально занимались работой, а не били баклуши. Наверняка внедряли или дорабатывали систему мониторинга, переносили какие-то сервисы или сервера, настраивали бэкапы и проверяли их. Вот об этом кратко и пишите сразу, как сделаете. Что-то типа такого:
Без остановки производственного процесса выполнил миграцию рабочей нагрузки на новое железо. Предварительно провёл анализ нагрузки, рассчитал бюджет под новое железо, обосновал его. Сделал предварительную настройку, тестовое перемещение работающих сервисов. Составил подробный план. В запланированное время выполнил успешную миграцию.
Это и на текущей работе сможет помочь. Например, если вас просят на какой-нибудь аттестации или просто разговоре с руководством, чем вы, собственно, занимаетесь и почему вам стоит поднять зарплату. А вы сразу готовый список покажете своих достижений, даже если кажется, что это обычная рутина. Но даже хорошо выполняемую рутину можно оформить как достижение.
В общем, заведите себе какой-то документ в своих заметках и пишите там основные вехи в своей деятельности. Это займёт буквально 5 минут в неделю, но сильно поможет как минимум в поиске работе, а скорее всего и на текущем рабочем месте.
К слову, большинство людей, с которыми я беседовал, раньше явно такой список не готовили и начинали плавать в этих очень простых вопросах, которые стоит проработать заранее и подать себя в лучшем виде.
#разное
По знаниям и техническим подробностям ничего говорить не буду, это и так известная информация, которую легко найти. Расскажу немного о другом. Причём не только со стороны соискателя, но и со стороны работодателя. У меня был опыт, и не очень маленький, когда нужно было закрывать вакансии сисадминов. Я составлял вакансии, проводил собеседования. Иногда прям на потоке по 5-6 человек в день. Довольно утомительное занятие. Тогда я понял, почему люди редко дают обратную связь, когда тебе отказывают. Мало того, что это банально занимает твоё время, так ещё и надо не забыть, почему конкретному человеку ты отказал. А когда было 10-15 собеседований, выбрал ты одного, остальным 14-ти уже трудно каждому написать и объяснить, почему не подошёл. Просто кто-то был лучше.
На собеседованиях часто задают примерно такие вопросы:
❓Какое у тебя было самое большое достижение на прошлой или ещё раньше, работе?
❓Какой был самый большой провал и какие из него были сделаны выводы?
❓Как развиваетесь, повышаете свои навыки? Что последнее изучили, внедрили новое?
Когда тебе надо искать работу и обновлять резюме, затруднительно всё это сразу вспомнить и хорошо написать. Вместо этого я вам советую вести своё резюме в режиме реального времени. Постоянно записывать свои достижения, провалы, полученные навыки, прохождение курсов или изучение чего-то нового пусть даже по видео из Youtube.
Готовый список из описанных событий позволит быстро скомпоновать резюме под конкретные задачи или вакансии. Не обязательно там писать сразу всё. Просто сядьте и подумайте, для какой компании или вакансии было бы уместно указать те или иные достижения. В резюме стоит писать только их. А остальные вещи просто держать в голове и освежать знания перед собеседованиями, чтобы быстро и уверенно ответить, а не судорожно вспоминать, где же я там накосячил и как рассказать так, чтобы мне в итоге не отказали и не посчитали нубасом. Уверенно рассказать про свои косяки и выводы, которые из этого были сделаны, дорого стоит. Сходу может и не получиться.
Кому-то может показаться, что он ничего особенного не делал и писать в достижениях нечего. Вряд ли это так на самом деле, если вы реально занимались работой, а не били баклуши. Наверняка внедряли или дорабатывали систему мониторинга, переносили какие-то сервисы или сервера, настраивали бэкапы и проверяли их. Вот об этом кратко и пишите сразу, как сделаете. Что-то типа такого:
Без остановки производственного процесса выполнил миграцию рабочей нагрузки на новое железо. Предварительно провёл анализ нагрузки, рассчитал бюджет под новое железо, обосновал его. Сделал предварительную настройку, тестовое перемещение работающих сервисов. Составил подробный план. В запланированное время выполнил успешную миграцию.
Это и на текущей работе сможет помочь. Например, если вас просят на какой-нибудь аттестации или просто разговоре с руководством, чем вы, собственно, занимаетесь и почему вам стоит поднять зарплату. А вы сразу готовый список покажете своих достижений, даже если кажется, что это обычная рутина. Но даже хорошо выполняемую рутину можно оформить как достижение.
В общем, заведите себе какой-то документ в своих заметках и пишите там основные вехи в своей деятельности. Это займёт буквально 5 минут в неделю, но сильно поможет как минимум в поиске работе, а скорее всего и на текущем рабочем месте.
К слову, большинство людей, с которыми я беседовал, раньше явно такой список не готовили и начинали плавать в этих очень простых вопросах, которые стоит проработать заранее и подать себя в лучшем виде.
#разное
Для управления простым в установке и настройке VPN туннелем WireGuard существует много веб-панелей. Про некоторые я уже писал ранее. Недавно перебирал свои черновики и нашёл ещё один проект, который раньше не пробовал. Я развернул и настроил сервер с Wireguard буквально за несколько минут. Установка и настройка очень простые, а возможностей достаточно не только для управления клиентами, но и настройками самого сервера.
❗️Сразу скажу, что это решение не для обхода блокировок и замедлений, а для доступа к закрытым сетям. Не надо писать о том, что WG блокируют провайдеры. Внутри РФ у меня нет с этим проблем. Во время написания заметки пробовал подключаться и через смартфон, и через проводной интернет дома и на работе. У меня не возникает проблем с подключением ни по WG, ни по OVPN. Я пользуюсь ими постоянно во время работы. Иногда бывают проблемы на мобильном интернете, но так было всегда, а не только последнее время.
Оформил всё это дело в короткую заметку, по которой простым копированием команд можно быстро настроить свой сервер и запустить в работу. Настраивать буду, как обычно, на Debian 12.
Устанавливаем необходимые пакеты:
Сразу разрешим пересылку пакетов между сетевыми интерфейсами. Иногда забываю это сделать, а потом долго разбираюсь, почему ничего не работает.
Скачиваем wireguard-ui в ту же директорию, где живут настройки службы WG:
Запускаем wireguard-ui, ждём несколько секунд, чтобы она создала конфигурацию для службы:
Останавливаем wireguard-ui. Нажимаем в консоли
Запускаем службу WireGuard:
Проверяем, что интерфейс wg0 поднялся и правила iptables добавились:
Веб-панель умеет вносить изменения в настройки WG, но не умеет перезапускать службу. Воспользуемся возможностями SystemD.Path для автоматического перезапуска туннеля после изменения файла конфигурации. Создаём файл /etc/systemd/system/wgui.path:
И саму службу /etc/systemd/system/wgui.service:
Запускаем их:
Сделаем отдельный юнит для автозапуска wireguard-ui после старта машины /etc/systemd/system/wireguard-ui.service:
Запускаем и добавляем в автозапуск одновременно:
Идём в веб интерфейс по IP адресу сервера на порт 5000. Учётка по умолчанию - admin / admin. Базовые настройки сервера мы уже сделали. Можно добавлять пользователей и подключаться. При необходимости можно изменить настройки сервера. Не забудьте изменить учётную запись администратора.
⇨ 🌐 Исходники
📌Полезные материалы на тему использования WG:
◽️Wireproxy - socks5/http прокси на базе WG
◽️TunnlTo - управление маршрутами в туннели WG на основе приложений
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wireguard #vpn
❗️Сразу скажу, что это решение не для обхода блокировок и замедлений, а для доступа к закрытым сетям. Не надо писать о том, что WG блокируют провайдеры. Внутри РФ у меня нет с этим проблем. Во время написания заметки пробовал подключаться и через смартфон, и через проводной интернет дома и на работе. У меня не возникает проблем с подключением ни по WG, ни по OVPN. Я пользуюсь ими постоянно во время работы. Иногда бывают проблемы на мобильном интернете, но так было всегда, а не только последнее время.
Оформил всё это дело в короткую заметку, по которой простым копированием команд можно быстро настроить свой сервер и запустить в работу. Настраивать буду, как обычно, на Debian 12.
Устанавливаем необходимые пакеты:
# apt install wireguard iptables
Сразу разрешим пересылку пакетов между сетевыми интерфейсами. Иногда забываю это сделать, а потом долго разбираюсь, почему ничего не работает.
# echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
# sysctl -p
Скачиваем wireguard-ui в ту же директорию, где живут настройки службы WG:
# cd /etc/wireguard
# wget https://github.com/ngoduykhanh/wireguard-ui/releases/download/v0.6.2/wireguard-ui-v0.6.2-linux-amd64.tar.gz
# tar -xzvf wireguard-ui-v0.6.2-linux-amd64.tar.gz
Запускаем wireguard-ui, ждём несколько секунд, чтобы она создала конфигурацию для службы:
# ./wireguard-ui
Останавливаем wireguard-ui. Нажимаем в консоли
Ctrl+C
. Сразу добавим необходимые параметры в /etc/wireguard/wg0.conf:PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;
PostDown = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;
Запускаем службу WireGuard:
# systemctl enable --now wg-quick@wg0.service
Проверяем, что интерфейс wg0 поднялся и правила iptables добавились:
# ip a | grep wg
# iptables -L -v -n -t nat | grep MASQUERADE
Веб-панель умеет вносить изменения в настройки WG, но не умеет перезапускать службу. Воспользуемся возможностями SystemD.Path для автоматического перезапуска туннеля после изменения файла конфигурации. Создаём файл /etc/systemd/system/wgui.path:
[Unit]
Description=Watch /etc/wireguard/wg0.conf for changes
[Path]
PathModified=/etc/wireguard/wg0.conf
[Install]
WantedBy=multi-user.target
И саму службу /etc/systemd/system/wgui.service:
[Unit]
Description=Restart WireGuard
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl restart wg-quick@wg0.service
[Install]
RequiredBy=wgui.path
Запускаем их:
# systemctl enable wgui.{path,service}
# systemctl start wgui.{path,service}
Сделаем отдельный юнит для автозапуска wireguard-ui после старта машины /etc/systemd/system/wireguard-ui.service:
[Unit]
Description=WireGuard UI Service
After=network.target
[Service]
Type=simple
User=root
WorkingDirectory=/etc/wireguard
ExecStart=/etc/wireguard/wireguard-ui
Restart=on-failure
[Install]
WantedBy=multi-user.target
Запускаем и добавляем в автозапуск одновременно:
# systemctl enable --now wireguard-ui.service
Идём в веб интерфейс по IP адресу сервера на порт 5000. Учётка по умолчанию - admin / admin. Базовые настройки сервера мы уже сделали. Можно добавлять пользователей и подключаться. При необходимости можно изменить настройки сервера. Не забудьте изменить учётную запись администратора.
⇨ 🌐 Исходники
📌Полезные материалы на тему использования WG:
◽️Wireproxy - socks5/http прокси на базе WG
◽️TunnlTo - управление маршрутами в туннели WG на основе приложений
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wireguard #vpn