На днях на одном из серверов VPN с IP 175.115.158.81 заметил странные строки в логе:
Внимание привлекло то, что 95.145.141.246 это мой IP адрес ещё одного VPN сервера. Я не припомнил, чтобы настраивал на нем клиента для подключения к серверу 175.115.158.81. На всякий случай сходил туда и убедился в этом:
Никакого openvpn клиента тут не было запущено. Да и настроек для него тоже нет. У меня настроена разветвлённая система VPN туннелей с маршрутизацией, так что иногда начинаю в ней путаться. Надо схему рисовать.
Я немного напрягся и стал разбираться, в чём тут дело. Решил посмотреть на сервере с IP 95.145.141.246 исходящие сетевые соединения:
Соединения разные были, но к указанному VPN серверу ничего не было. Стало ещё интереснее. Расчехлил tcpdump и стал смотреть им:
Подождал, когда в логе на VPN сервере 175.115.158.81 опять появится запись о неудачном соединении. Вернулся в консоль сервера 95.145.141.246 и увидел запись:
1778 - порт VPN сервера. Смотрю на адрес 172.17.0.4 и тут до меня доходит, что это Docker контейнер. Проверяю IP адреса контейнеров:
А там мониторинг Gatus. И тут я вспоминаю, что настроил мониторинг VPN канала через проверку доступности порта, на котором он принимает подключения. Всё встало на свои места. Не думал, что проверка порта будет такими записями в логе отмечаться. Хотя на самом деле с таким встречаюсь иногда, когда через Zabbix порты проверяю через simple check.
Получилась мини-инструкция по диагностике исходящих соединений. В принципе, можно было сразу запустить tcpdump, но я по памяти не помню ключи и синтаксис выборки для него. Приходится куда-то лезть за подсказками. Мне казалось, что я делал по tcpdump заметку с популярными командами, но нет, не нашёл. Надо будет при случае исправить это.
#linux #terminal
ovpn-server[3742533]: TCP connection established with [AF_INET] 95.145.141.246:58560
ovpn-server[3742533]: 95.145.141.246:58560 Connection reset, restarting [0]
ovpn-server[3742533]: 95.145.141.246:58560 SIGUSR1[soft,connection-reset] received, client-instance restarting
Внимание привлекло то, что 95.145.141.246 это мой IP адрес ещё одного VPN сервера. Я не припомнил, чтобы настраивал на нем клиента для подключения к серверу 175.115.158.81. На всякий случай сходил туда и убедился в этом:
# ps axf
Никакого openvpn клиента тут не было запущено. Да и настроек для него тоже нет. У меня настроена разветвлённая система VPN туннелей с маршрутизацией, так что иногда начинаю в ней путаться. Надо схему рисовать.
Я немного напрягся и стал разбираться, в чём тут дело. Решил посмотреть на сервере с IP 95.145.141.246 исходящие сетевые соединения:
# ss -ntu
Соединения разные были, но к указанному VPN серверу ничего не было. Стало ещё интереснее. Расчехлил tcpdump и стал смотреть им:
# tcpdump -nn 'dst host 175.115.158.81'
Подождал, когда в логе на VPN сервере 175.115.158.81 опять появится запись о неудачном соединении. Вернулся в консоль сервера 95.145.141.246 и увидел запись:
14:29:38.706375 IP 172.17.0.4.58700 > 175.115.158.81.1778
1778 - порт VPN сервера. Смотрю на адрес 172.17.0.4 и тут до меня доходит, что это Docker контейнер. Проверяю IP адреса контейнеров:
# docker ps -q | xargs -n 1 docker inspect --format '{{ .NetworkSettings.IPAddress }} {{ .Name }}' | sed 's/ \// /'
...........
172.17.0.4 gatus
...........
А там мониторинг Gatus. И тут я вспоминаю, что настроил мониторинг VPN канала через проверку доступности порта, на котором он принимает подключения. Всё встало на свои места. Не думал, что проверка порта будет такими записями в логе отмечаться. Хотя на самом деле с таким встречаюсь иногда, когда через Zabbix порты проверяю через simple check.
Получилась мини-инструкция по диагностике исходящих соединений. В принципе, можно было сразу запустить tcpdump, но я по памяти не помню ключи и синтаксис выборки для него. Приходится куда-то лезть за подсказками. Мне казалось, что я делал по tcpdump заметку с популярными командами, но нет, не нашёл. Надо будет при случае исправить это.
#linux #terminal
👍202👎5
Очень простой и быстрый способ измерить ширину канала с помощью Linux без установки дополнительных пакетов. Понадобится только netcat, который чаще всего есть в составе базовых утилит. По крайней мере в Debian это так.
Берём условный сервер 10.20.1.50 и запускаем там netcat на порту 5201:
Идём на другую машину и запускаем netcat в режиме клиента, передавая туда 10 блоков размером 10 мегабайт:
Когда измерял так скорость, немного усомнился в достоверности результатов. Решил провести одинаковые тесты с помощью netcat и iperf3. На скоростях до 1 Gbits/sec замеры показывают одинаковые числа, плюс-минус в районе погрешности измерений. Можно смело использовать netcat. Это реально работает для быстрой проверки канала до какой-то VPS.
А вот в сетях в рамках гипервизора, где скорости значительно больше, идут большие расхождения. Iperf3 показывает раза в 4 больше скорость (~15.0 Gbits/sec), чем netcat (~4.0 Gbits/sec). Гипервизор объявляет скорость своего бриджа в 10 Gbits/sec. И тут уже трудно судить, кто ближе к истине. Корректно выполнить замеры на реальных данных затруднительно, так как много факторов, которые влияют на итоговый результат.
Напомню, что у меня есть хорошая заметка про netcat с различными практическими примерами применения этой утилиты.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network
Берём условный сервер 10.20.1.50 и запускаем там netcat на порту 5201:
# nc -lvp 5201 > /dev/null
Идём на другую машину и запускаем netcat в режиме клиента, передавая туда 10 блоков размером 10 мегабайт:
# dd if=/dev/zero bs=10M count=10 | nc 10.20.1.50 5201
Когда измерял так скорость, немного усомнился в достоверности результатов. Решил провести одинаковые тесты с помощью netcat и iperf3. На скоростях до 1 Gbits/sec замеры показывают одинаковые числа, плюс-минус в районе погрешности измерений. Можно смело использовать netcat. Это реально работает для быстрой проверки канала до какой-то VPS.
А вот в сетях в рамках гипервизора, где скорости значительно больше, идут большие расхождения. Iperf3 показывает раза в 4 больше скорость (~15.0 Gbits/sec), чем netcat (~4.0 Gbits/sec). Гипервизор объявляет скорость своего бриджа в 10 Gbits/sec. И тут уже трудно судить, кто ближе к истине. Корректно выполнить замеры на реальных данных затруднительно, так как много факторов, которые влияют на итоговый результат.
Напомню, что у меня есть хорошая заметка про netcat с различными практическими примерами применения этой утилиты.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network
3👍157👎3
Я уже давно использую заметки с канала как свои шпаргалки. Всё полезное из личных заметок перенёс сюда, плюс оформил всё это аккуратно и дополнил. Когда ищу какую-то информацию, в первую очередь иду сюда, ищу по тегам или содержимому.
Обнаружил, что тут нет заметки про tcpdump, хотя личная шпаргалка по этой программе у меня есть. Переношу сюда. По tcpdump можно много всего написать, материала море. Я напишу кратко, только те команды, что использую сам. Их немного. Tcpdump использую редко, если есть острая необходимость.
Я ко всем командам добавляю ключ
📌 Список сетевых интерфейсов, с которых tcpdump может смотреть пакеты:
Если запустить программу без ключей, то трафик будет захвачен с первого активного интерфейса из списка выше.
📌 Слушаем все интерфейсы:
Или только конкретный:
📌 Исключаем SSH протокол. Если в трафике, на который мы смотрим, будет SSH соединение, то оно забивает весь вывод своей активностью. Глазами уже не разобрать. Исключаю его по номеру порта:
По аналогии исключается любой другой трафик по портам. Если убираем слово not, то слушаем трафик только указанного порта.
📌 Пакеты к определённому адресату или адресатам:
Комбинация порта и адресата:
Подобным образом можно комбинировать любые параметры: src, dst, port и т.д. с помощью операторов and, or, not,
📌 Смотрим конкретный протокол или исключаем его и не только:
На этом всё. Лично мне этих команд в повседневной деятельности достаточно. Не припоминаю, чтобы хоть раз использовал что-то ещё. Если надо проанализировать большой список, то просто направляю вывод в файл:
На основе приведённых выше примеров можно посмотреть, к примеру, на SIP трафик по VPN туннелю от конкретного пользователя к VOIP серверу:
Если не знакомы с tcpdump, рекомендую обязательно познакомиться и научиться пользоваться. Это не трудно, хоть на первый взгляд вывод выглядит жутковато и запутанно. Сильно в нём разбираться чаще всего не нужно, а важно увидеть какие пакеты и куда направляются. Это очень помогает в отладке. Чаще всего достаточно вот этого в выводе:
Протокол IP, адрес источника и порт > адрес получателя и его порт.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#network #tcpdump
Обнаружил, что тут нет заметки про tcpdump, хотя личная шпаргалка по этой программе у меня есть. Переношу сюда. По tcpdump можно много всего написать, материала море. Я напишу кратко, только те команды, что использую сам. Их немного. Tcpdump использую редко, если есть острая необходимость.
Я ко всем командам добавляю ключ
-nn
, чтобы не резолвить IP адреса в домены и не заменять номера портов именем протокола. Мне это мешает. 📌 Список сетевых интерфейсов, с которых tcpdump может смотреть пакеты:
# tcpdump -D
Если запустить программу без ключей, то трафик будет захвачен с первого активного интерфейса из списка выше.
📌 Слушаем все интерфейсы:
# tcpdump -nn -i any
Или только конкретный:
# tcpdump -nn -i ens3
📌 Исключаем SSH протокол. Если в трафике, на который мы смотрим, будет SSH соединение, то оно забивает весь вывод своей активностью. Глазами уже не разобрать. Исключаю его по номеру порта:
# tcpdump -nn -i any port not 22
По аналогии исключается любой другой трафик по портам. Если убираем слово not, то слушаем трафик только указанного порта.
📌 Пакеты к определённому адресату или адресатам:
# tcpdump -nn dst 8.8.8.8
# tcpdump -nn dst 8.8.8.8 or dst 8.8.4.4
Комбинация порта и адресата:
# tcpdump -nn dst 8.8.8.8 and port 53
Подобным образом можно комбинировать любые параметры: src, dst, port и т.д. с помощью операторов and, or, not,
📌 Смотрим конкретный протокол или исключаем его и не только:
# tcpdump arp -nn -i any
# tcpdump not arp -nn -i any
# tcpdump not arp and not icmp -nn -i any
На этом всё. Лично мне этих команд в повседневной деятельности достаточно. Не припоминаю, чтобы хоть раз использовал что-то ещё. Если надо проанализировать большой список, то просто направляю вывод в файл:
# tcpdump -nn -i any > ~/tcpdump.txt
На основе приведённых выше примеров можно посмотреть, к примеру, на SIP трафик по VPN туннелю от конкретного пользователя к VOIP серверу:
# tcpdump -nn -i tun4 src 10.1.4.23 and dst 10.1.3.205 and port 5060
Если не знакомы с tcpdump, рекомендую обязательно познакомиться и научиться пользоваться. Это не трудно, хоть на первый взгляд вывод выглядит жутковато и запутанно. Сильно в нём разбираться чаще всего не нужно, а важно увидеть какие пакеты и куда направляются. Это очень помогает в отладке. Чаще всего достаточно вот этого в выводе:
IP 10.8.2.2.13083 > 10.8.2.3.8118
Протокол IP, адрес источника и порт > адрес получателя и его порт.
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#network #tcpdump
102👍270👎5
Если у вас нет глубоких знаний о работе современных процессоров, а вы хотите получить хотя бы примерное представление, как на них работают программы, то у меня для вас необычная рекомендация. Есть целый сайт по этой теме:
⇨ https://cpu.land
Особенность его в том, что текст для него написан 17-ти летней девочкой-подростком, которая стала разработчиком. Материал воспринимается очень легко, написан простым языком. Я прочитал его в автоматическом переводе Яндекс.Браузера. Просто открыл все главы на одной странице, перевёл и прочитал. Иногда переключался на оригинал, чтобы уточнить какой-то переведённый термин.
Чтиво буквально на 15-20 минут, но после прочтения у вас будет представление, как совершается компьютерная магия, которая превращает нолики и единички в работающие программы на ОС с ядром Linux.
В материале раскрываются следующие темы:
▪️Как в принципе устроен процессор, как он работает с оперативной памятью
▪️Ядро операционной системы и системные вызовы
▪️Процессорные архитектуры и инструкции
▪️Аппаратные прерывания, многозадачность
▪️Разбор последовательных действий, которые происходят после вашего запуска программы в ОС
▪️Отдельно автор прошлась по скриптам, оболочкам и шебангам
▪️Разбор ELF файлов, что это такое и для чего нужны
▪️Динамические библиотеки .so
▪️Основные и дочерние процессы
Отдельно мне понравилась ремарка автора насчёт использования ChatGPT:
Я довольно много общался с GPT-3.5 и GPT-4 во время написания этой статьи. Хотя они много лгали мне и большая часть информации была бесполезной, иногда они были очень полезны для решения проблем. Помощь LLM может быть исключительно положительной, если вы знаете об их ограничениях и крайне скептически относитесь ко всему, что они говорят.
Мне понравился лёгкий и весёлый слог автора, несмотря на то, что читал перевод. Прям увидел и ощутил новый взгляд на обучающий материал, каким он может быть. Наверное, так написать мог только подросток. Рекомендую, если вы интересуетесь самообразованием.
❗️ Надеюсь, я заинтересовал вас и убедил не просто сохранить ссылку, но и прочитать её. В этом плане мы можем быть полезны друг другу. Если бы мне не нужно было писать эту заметку, то скорее всего я бы не стал читать материал, а просто добавил бы его куда-нибудь на будущее и никогда бы не вернулся. Собственно, я изначально так и сделал. Эта ссылка лежала у меня год 😁
#обучение
⇨ https://cpu.land
Особенность его в том, что текст для него написан 17-ти летней девочкой-подростком, которая стала разработчиком. Материал воспринимается очень легко, написан простым языком. Я прочитал его в автоматическом переводе Яндекс.Браузера. Просто открыл все главы на одной странице, перевёл и прочитал. Иногда переключался на оригинал, чтобы уточнить какой-то переведённый термин.
Чтиво буквально на 15-20 минут, но после прочтения у вас будет представление, как совершается компьютерная магия, которая превращает нолики и единички в работающие программы на ОС с ядром Linux.
В материале раскрываются следующие темы:
▪️Как в принципе устроен процессор, как он работает с оперативной памятью
▪️Ядро операционной системы и системные вызовы
▪️Процессорные архитектуры и инструкции
▪️Аппаратные прерывания, многозадачность
▪️Разбор последовательных действий, которые происходят после вашего запуска программы в ОС
▪️Отдельно автор прошлась по скриптам, оболочкам и шебангам
▪️Разбор ELF файлов, что это такое и для чего нужны
▪️Динамические библиотеки .so
▪️Основные и дочерние процессы
Отдельно мне понравилась ремарка автора насчёт использования ChatGPT:
Я довольно много общался с GPT-3.5 и GPT-4 во время написания этой статьи. Хотя они много лгали мне и большая часть информации была бесполезной, иногда они были очень полезны для решения проблем. Помощь LLM может быть исключительно положительной, если вы знаете об их ограничениях и крайне скептически относитесь ко всему, что они говорят.
Мне понравился лёгкий и весёлый слог автора, несмотря на то, что читал перевод. Прям увидел и ощутил новый взгляд на обучающий материал, каким он может быть. Наверное, так написать мог только подросток. Рекомендую, если вы интересуетесь самообразованием.
#обучение
Please open Telegram to view this post
VIEW IN TELEGRAM
Putting the "You" in CPU
Curious exactly what happens when you run a program on your computer? Learn how multiprocessing works, what system calls really are, how computers manage memory with hardware interrupts, and how Linux loads executables.
2👍112👎7
Немного информации для тех, кто имеет дело с обычными веб серверами под php сайты. Вчера провозился несколько часов с одним сайтом, который передали разработчики для публикации. Причём провозился из-за ерунды. Это был немного навороченный мультиязычный сайт на базе Wordpress, но с полностью самописной темой.
Я этих вордпрессов десятки устанавливал и поддерживал. Никак не ожидал проблем с этим движком. Но разработчики сумели меня удивить и нагрузить работой. Для начала пришлось повозиться с тем, что режим работы сайта http или https был жёстко зашит в коде сайта. И не где-то в настройках Wordpress или базе, а в коде темы. Это создавало некоторые проблемы при публикации за Cloudflare и Nginx в режиме proxy_pass. Пока всё развернул, разобрался, нашёл и вычистил в коде, немного подустал. Плюс, сайт под Apache разрабатывали, запустил под Nginx.
В итоге на сайте кое-где всплывали ошибки php, что-то не работало. В логе тоже ошибки и предупреждения со стороны php. Причём ошибки какие-то странные, типа скобки не закрыты, переменная не объявлена и т.д. Сначала подумал, что сайт написали под старую версию php. На веб сервере стояла относительно свежая 8.2. Уточнил у разработчиков, у них на 8.1 нормально работает. Разница в этих версиях не такая большая, должно нормально работать. Потом подумал, что по ошибке скинули какой-то черновик, а не итоговую работу.
Немного поразбирался в ошибках и выяснил, в чём проблема. В php по умолчанию параметр short_open_tag выключен. Это нормальная история, так как стандартному коду Wordpress он не нужен. Мне и в голову не пришло его включить. В версиях php до 6-й он был включен, потом стали отключать из соображений совместимости с другим кодом. Например, с тэгами
В коде этого сайта были конструкции типа
Если где-то придётся писать код php, то пишите сразу полные тэги <?php, а не короткие. Сейчас это более правильный подход, который улучшает переносимость проекта и не вызывает проблем с совместимостью с другим кодом, который использует тэги. Вот наглядный пример, где будут проблемы с короткими тэгами:
Это элемент xml разметки, а с включённым short_open_tag это будет интерпретироваться как php код.
#webserver #php
Я этих вордпрессов десятки устанавливал и поддерживал. Никак не ожидал проблем с этим движком. Но разработчики сумели меня удивить и нагрузить работой. Для начала пришлось повозиться с тем, что режим работы сайта http или https был жёстко зашит в коде сайта. И не где-то в настройках Wordpress или базе, а в коде темы. Это создавало некоторые проблемы при публикации за Cloudflare и Nginx в режиме proxy_pass. Пока всё развернул, разобрался, нашёл и вычистил в коде, немного подустал. Плюс, сайт под Apache разрабатывали, запустил под Nginx.
В итоге на сайте кое-где всплывали ошибки php, что-то не работало. В логе тоже ошибки и предупреждения со стороны php. Причём ошибки какие-то странные, типа скобки не закрыты, переменная не объявлена и т.д. Сначала подумал, что сайт написали под старую версию php. На веб сервере стояла относительно свежая 8.2. Уточнил у разработчиков, у них на 8.1 нормально работает. Разница в этих версиях не такая большая, должно нормально работать. Потом подумал, что по ошибке скинули какой-то черновик, а не итоговую работу.
Немного поразбирался в ошибках и выяснил, в чём проблема. В php по умолчанию параметр short_open_tag выключен. Это нормальная история, так как стандартному коду Wordpress он не нужен. Мне и в голову не пришло его включить. В версиях php до 6-й он был включен, потом стали отключать из соображений совместимости с другим кодом. Например, с тэгами
<?xml
.В коде этого сайта были конструкции типа
<?
вместо <?php
, а для их корректной работы как раз и нужен параметр short_open_tag
. Есть проекты, где явно пишут, что надо включить этот параметр. А тут мне никто ни слова насчёт него не сказал. Включил параметр и всё заработало. Если где-то придётся писать код php, то пишите сразу полные тэги <?php, а не короткие. Сейчас это более правильный подход, который улучшает переносимость проекта и не вызывает проблем с совместимостью с другим кодом, который использует тэги. Вот наглядный пример, где будут проблемы с короткими тэгами:
<?xml version="1.0"?>
Это элемент xml разметки, а с включённым short_open_tag это будет интерпретироваться как php код.
#webserver #php
👍122👎2
⇨ ProxMox Cluster 2 Nodes + Q-Device. Кластер просто. Для дома и офиса.
Пример настройки бюджетного HA кластера из двух нод и "арбитра" на Raspberry Pi для кворума. Хранилища локальные на базе zfs. Второй сервер будет содержать клоны VM c первого и заменит его в случае выхода из строя.
⇨ Best Docker Container Server Setup // Docker Swarm, CephFS, and Portainer
Очень любопытное видео на тему перечисленных выше технологий. Автор рассмотрел простую отказоустойчивую замену кластера Kubernetes. Видео небольшое, но ёмкое по объему информации и практике. Не знаю, имеет ли смысл подобная сборка, но посмотреть и послушать интересно.
⇨ Linux - Как легко создать свой DEB package на Линукс
Пошаговая инструкция на заданную тему от Дениса Астахова и его полезного канала ADV-IT. Смотреть видео большого смысла нет, если у вас нет задачи по сборке пакетов. А вот сохранить ссылку имеет смысл, чтобы быстро найти, когда задача такая возникнет. Можно и мою инструкцию на эту тему сохранить.
⇨ ПРОБРОС СЕТЕВОЙ КАРТЫ ИЛИ LINUX BRIDGE? ИЛИ ВИРТУАЛЬНЫЙ РОУТЕР С 2 ЛАН ПОРТАМИ
Полезное видео на тему организации сети в Proxmox. Я лично всегда и везде использую бриджи. Это удобно, плюс виртуалки получают лучшую переносимость.
⇨ Dockge - выкинь Portainer немедленно
Кликбейтный заголовок, а по сути автор рассказывает про минусы Portainer и показывает, что можно использовать в качестве замены. Я лично не проникся этой заменой.
⇨ Docker always up to date! (and more) Renovate Tutorial
Рекламное видео на тему программы Renovate, которая умеет автоматически проверять и обновлять в исходниках версии используемых образов докера, пакетов, указанных в ваших репозиториях. У Renovate есть бесплатная self-hosted Community версия, так что видео может быть полезным. В нём настраивают и тестируют именно эту версию.
⇨ OpenRPort - Remote Management Tool with Secure Tunneling!
Бесплатная программа для удалённого управления компьютерами. Сделана на базе RealVNC. Есть веб интерфейс с 2FA аутентификацией. Впервые услышал об этой программе. Было интересно посмотреть. Надо будет попробовать в деле. Наличие VNC под капотом немного расстраивает, так как скорее всего картинка будет лагучей, как это обычно бывает с VNC через интернет на слабых каналах.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
ProxMox Cluster 2 Nodes + Q-Device. Кластер просто. Для дома и офиса.
ProxMox Cluster 2 Nodes + Q-Device. Создание кластера.
Proxmox cluster 3 Nodes: https://www.youtube.com/watch?v=Owyrz9D_pZQ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Буду очень благодарен за поддержку в виде чашечки ☕️:
https://www.buymeacoffee.com/RomNero
~…
Proxmox cluster 3 Nodes: https://www.youtube.com/watch?v=Owyrz9D_pZQ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Буду очень благодарен за поддержку в виде чашечки ☕️:
https://www.buymeacoffee.com/RomNero
~…
4👍69👎3
Периодически в комментариях возникают вопросы на тему личного хранилища информации. Кто, как и где хранит. Я сколько веду свою трудовую деятельность, столько и делаю записи по различным темам. Начинал всё с простого сохранения html страниц. Они, кстати, до сих пор у меня хранятся. Упаковал в архив, так и лежат с тех пор. В конце будет ссылка на один подобный архив по теме. Может кому интересно будет поностальгировать по прошлым временам. Там будет цикл статей по настройке почтового сервера на Freebsd, по которому я учился.
Сейчас вся моя база знаний переехала в этот канал. Как раньше сайт, так и сейчас канал я лично использую почти каждый день в своих делах. В том числе и поэтому я аккуратно и ответственно всё составляю, оформляю, готовлю к публикации, делаю подборки. Всегда держу в голове момент, как я буду потом искать эту информацию. Ищу либо по тэгами, либо по названиям конкретных программ. В целом могу сказать, что такой поиск меня устраивает. Обычно нахожу то, что нужно.
В дополнение к этому, я в Joplin веду все свои проекты, не только по работе, но и личные, типа стройки, ремонта, сайта и т.д. Когда делаю что-то значимое, что хочу сохранить для использования в будущем, делаю заметку по этой теме в свободной форме. Покажу на конкретных примерах.
Есть компания, где используются сайты на Битриксе. У меня там в том числе есть такие записи:
◽️Bitrix. Тут хранится общая информация обо всём, с чем сталкиваюсь. Например, была ошибка, я записал текст ошибки и тут же решение текстом или ссылку на материал, который использовал. Не занимаюсь никаким особым оформлением. Просто записываю, чтобы потом найти.
◽️Переезд веб сервера. Тут пишу всё, что касается переезда. Уже не раз меняли провайдера, сервера, услуги. Каждый раз кажется, что это в последний раз так переезжаем масштабно, но на деле, каждые 2-3 года что-то случается. Заметка очень помогает быстро составить план переноса.
◽️Заражение. Тут описана история заражения одного сайта. Что пролезло, какие признаки были, как лечил.
◽️Ошибки обновления. Сайты периодически обновляют, пишу, с чем сталкиваемся, чтобы потом быстрее обсудить с разработчиками очередное обновление.
❗️Важный момент. Я не трачу много времени на эти записки. Просто копирую информацию и всё. Если оформлять, дополнять, то на это тратится время, будешь лениться или откладывать. В итоге забудешь. А так всё записано. Потом это пригождается и в других проектах, так как с Bitrix приходится много где работать. Даже такие отрывочные данные сильно упрощают решение задачи, когда с ней повторно сталкиваешься.
По личным делам всё то же самое. Вот несколько примеров записей по даче:
◽️Техника. Записываю модели всей купленной техники и всё, что с ней связано.
◽️Обслуживание инженерки. Пишу, что, где, когда и как надо делать: проверить расширительный бак, заменить фильтр, закрыть уличный кран на зиму и т.д.
◽️Строительные компании. С какими компаниями работал, кто что делал.
◽️Серверная. Оборудование в серверном шкафу.
◽️Спросить у специалиста. Список вопросов, на которые мне нужен совет специалиста.
◽️Перед отъездом. Список того, что надо проверить перед отъездом: закрыть окна, отключить насос, выключить тёплый пол, забрать мусор и т.д. Не нужно каждый раз ломать голову и вспоминать, ничего ли я не забыл. Этот список, кстати, распечатан и висит перед выходной дверью.
Примерно так. Не знаю, насколько это будет полезно вам. Такие вещи очень индивидуальны. У меня простое правило - всё должно быть записано. Если не записал, через пол года уже ничего не помнишь. Вспоминать очень накладно и долго. Найти в своих заметках - дело пары минут. Главное не упарываться в оформление. Пусть будет свалка. С помощью поиска и в свалке быстро найдешь, если данные записаны.
Как вы можете увидеть, снизу есть тэг. По нему вы найдёте все мои записи по этой теме. Например, как планирую свои дела и какой планировщик использую.
Обещанный архив: postfix.7z
#заметки
Сейчас вся моя база знаний переехала в этот канал. Как раньше сайт, так и сейчас канал я лично использую почти каждый день в своих делах. В том числе и поэтому я аккуратно и ответственно всё составляю, оформляю, готовлю к публикации, делаю подборки. Всегда держу в голове момент, как я буду потом искать эту информацию. Ищу либо по тэгами, либо по названиям конкретных программ. В целом могу сказать, что такой поиск меня устраивает. Обычно нахожу то, что нужно.
В дополнение к этому, я в Joplin веду все свои проекты, не только по работе, но и личные, типа стройки, ремонта, сайта и т.д. Когда делаю что-то значимое, что хочу сохранить для использования в будущем, делаю заметку по этой теме в свободной форме. Покажу на конкретных примерах.
Есть компания, где используются сайты на Битриксе. У меня там в том числе есть такие записи:
◽️Bitrix. Тут хранится общая информация обо всём, с чем сталкиваюсь. Например, была ошибка, я записал текст ошибки и тут же решение текстом или ссылку на материал, который использовал. Не занимаюсь никаким особым оформлением. Просто записываю, чтобы потом найти.
◽️Переезд веб сервера. Тут пишу всё, что касается переезда. Уже не раз меняли провайдера, сервера, услуги. Каждый раз кажется, что это в последний раз так переезжаем масштабно, но на деле, каждые 2-3 года что-то случается. Заметка очень помогает быстро составить план переноса.
◽️Заражение. Тут описана история заражения одного сайта. Что пролезло, какие признаки были, как лечил.
◽️Ошибки обновления. Сайты периодически обновляют, пишу, с чем сталкиваемся, чтобы потом быстрее обсудить с разработчиками очередное обновление.
❗️Важный момент. Я не трачу много времени на эти записки. Просто копирую информацию и всё. Если оформлять, дополнять, то на это тратится время, будешь лениться или откладывать. В итоге забудешь. А так всё записано. Потом это пригождается и в других проектах, так как с Bitrix приходится много где работать. Даже такие отрывочные данные сильно упрощают решение задачи, когда с ней повторно сталкиваешься.
По личным делам всё то же самое. Вот несколько примеров записей по даче:
◽️Техника. Записываю модели всей купленной техники и всё, что с ней связано.
◽️Обслуживание инженерки. Пишу, что, где, когда и как надо делать: проверить расширительный бак, заменить фильтр, закрыть уличный кран на зиму и т.д.
◽️Строительные компании. С какими компаниями работал, кто что делал.
◽️Серверная. Оборудование в серверном шкафу.
◽️Спросить у специалиста. Список вопросов, на которые мне нужен совет специалиста.
◽️Перед отъездом. Список того, что надо проверить перед отъездом: закрыть окна, отключить насос, выключить тёплый пол, забрать мусор и т.д. Не нужно каждый раз ломать голову и вспоминать, ничего ли я не забыл. Этот список, кстати, распечатан и висит перед выходной дверью.
Примерно так. Не знаю, насколько это будет полезно вам. Такие вещи очень индивидуальны. У меня простое правило - всё должно быть записано. Если не записал, через пол года уже ничего не помнишь. Вспоминать очень накладно и долго. Найти в своих заметках - дело пары минут. Главное не упарываться в оформление. Пусть будет свалка. С помощью поиска и в свалке быстро найдешь, если данные записаны.
Как вы можете увидеть, снизу есть тэг. По нему вы найдёте все мои записи по этой теме. Например, как планирую свои дела и какой планировщик использую.
Обещанный архив: postfix.7z
#заметки
2👍154👎4
Если обратиться к веб серверу на базе Nginx по IP адресу, то увидите либо первый виртуальных хост в конфигурации, либо тот, где указана директива default в параметре listen. Показывать виртуальный хост не очень хочется, поэтому обычно на IP адрес ставят какую-то заглушку. Например, так:
С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:
То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.
Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:
Используем его:
Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:
Объединил для удобства оба протокола. Ключевой момент тут в настройке
Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver #angie
server {
listen 80 default_server;
server_name _;
return 404;
}
С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:
server {
listen 443 ssl default_server;
server_name _;
return 404;
}
То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.
Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:
# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/certs/nginx.key -out /etc/nginx/certs/nginx.crt
Используем его:
server {
listen 443 ssl default_server;
server_name _;
ssl_certificate /etc/nginx/certs/nginx.crt;
ssl_certificate_key /etc/nginx/certs/nginx.key;
return 404;
}
Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:
server {
listen 80 default_server;
listen 443 ssl default_server;
server_name _;
ssl_reject_handshake on;
return 404;
}
Объединил для удобства оба протокола. Ключевой момент тут в настройке
ssl_reject_handshake on
. Когда она включена, веб сервер отклоняет все попытки соединения, где адрес сервера не совпадает с тем, что указано в директиве server_name
. Тут у нас в этой директиве _
, так что все соединения будут сразу отклоняться. Пользователь сразу увидит ошибку без необходимости выполнять какие-либо действия. Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver #angie
4👍301👎4
Интересные дела происходят с замедлением youtube. Пару недель назад заметил, что на домашнем интернете замедление прекратилось. У меня в Москве провайдер Ростелеком. Ещё в августе началось жёсткое замедление, так что смотреть ютуб было нереально.
Я принял ряд организационных мер и направил трафик ко всему гуглу по IP адресам на VPN. Это нормально работает. Дома особо никто не пользуется услугами гугла, так что каких-то неудобств, связанных с тем, что весь трафик идёт в VPN, не было. Стало даже удобно, так как детям можно было отключить ютуб, пока они не сделают уроки.
В какой-то момент заметил, что замедление перестало работать. VPN отключен, а ютуб нормально работает. Стал разбираться, почему так. Для начала решил промаркировать весь трафик, который можно было по доменам или IP адресам идентифицировать как ютубовский. Смотрю видео в максимальном разрешении, а трафика по этим маркировкам нет. Что-то есть, но очень мало.
Посмотрел внимательнее, откуда грузится видео. Оказалось, что с IP адреса 77.37.252.140. Проверяю этот адрес:
Неплохо, кэш гугла работает. А чей же это айпишник:
Ростелекомовский. Поспрашивал знакомых, у кого-то работает замедление, у кого-то нет.
Такая вот странная история выходит с этим замедлением. У меня оно работать перестало. Основной трафик идёт через кэширующий сервер гугла, который стоит в Ростелекоме. По идее последний без проблем может его отключить и снова замедлять.
Теперь думаю, как мне снова замедлить ютуб, чтобы дети не смотрели, пока уроки не сделают. С появлением кэширующих серверов, адреса которых неизвестны, задача усложнилась. cache.google.com - это PTR запись для IP адресов. Сам домен не пингуется, DNS записей для него нет. У Ростелекома много подобных серверов, IP периодически меняются.
У кого-то есть идеи, как теперь обратно всё замедлить при таких вводных? Я не совсем понимаю, в какой момент происходит перенаправление запросов на локальный кэширующий сервер провайдера и какие конкретно запросы перенаправляются, чтобы их как-то отследить. Весь гугл банить или замедлять не вариант. Во время воспроизведения даже одного и того же видео поток иногда идёт напрямую из USA с гугловских IP, а иногда из кэширующего сервера.
У вас вообще как с замедлением? Работает или нет? У меня по факту ни на мобильном интернете, ни на проводном замедления нет. Спокойно всё смотрю в высоком качестве.
#замедление
Я принял ряд организационных мер и направил трафик ко всему гуглу по IP адресам на VPN. Это нормально работает. Дома особо никто не пользуется услугами гугла, так что каких-то неудобств, связанных с тем, что весь трафик идёт в VPN, не было. Стало даже удобно, так как детям можно было отключить ютуб, пока они не сделают уроки.
В какой-то момент заметил, что замедление перестало работать. VPN отключен, а ютуб нормально работает. Стал разбираться, почему так. Для начала решил промаркировать весь трафик, который можно было по доменам или IP адресам идентифицировать как ютубовский. Смотрю видео в максимальном разрешении, а трафика по этим маркировкам нет. Что-то есть, но очень мало.
Посмотрел внимательнее, откуда грузится видео. Оказалось, что с IP адреса 77.37.252.140. Проверяю этот адрес:
# host 77.37.252.140
140.252.37.77.in-addr.arpa domain name pointer cache.google.com.
Неплохо, кэш гугла работает. А чей же это айпишник:
# ipa 77.37.252.140
{
"ip": "77.37.252.140",
"ip_decimal": 1294335116,
"country": "Russia",
"country_iso": "RU",
"country_eu": false,
"region_name": "Moscow Oblast",
"region_code": "MOS",
"zip_code": "140185",
"city": "Zhukovsky",
"latitude": 55.597,
"longitude": 38.1151,
"time_zone": "Europe/Moscow",
"asn": "AS42610",
"asn_org": "Rostelecom",
"hostname": "cache.google.com"
}
Ростелекомовский. Поспрашивал знакомых, у кого-то работает замедление, у кого-то нет.
Такая вот странная история выходит с этим замедлением. У меня оно работать перестало. Основной трафик идёт через кэширующий сервер гугла, который стоит в Ростелекоме. По идее последний без проблем может его отключить и снова замедлять.
Теперь думаю, как мне снова замедлить ютуб, чтобы дети не смотрели, пока уроки не сделают. С появлением кэширующих серверов, адреса которых неизвестны, задача усложнилась. cache.google.com - это PTR запись для IP адресов. Сам домен не пингуется, DNS записей для него нет. У Ростелекома много подобных серверов, IP периодически меняются.
У кого-то есть идеи, как теперь обратно всё замедлить при таких вводных? Я не совсем понимаю, в какой момент происходит перенаправление запросов на локальный кэширующий сервер провайдера и какие конкретно запросы перенаправляются, чтобы их как-то отследить. Весь гугл банить или замедлять не вариант. Во время воспроизведения даже одного и того же видео поток иногда идёт напрямую из USA с гугловских IP, а иногда из кэширующего сервера.
У вас вообще как с замедлением? Работает или нет? У меня по факту ни на мобильном интернете, ни на проводном замедления нет. Спокойно всё смотрю в высоком качестве.
#замедление
👍75👎22
В начале октября была новость от Microsoft, что в новых версиях своего сервера они откажутся от поддержки протоколов PPTP и L2TP для организации VPN соединений. Про первый очень давно известно, что он небезопасен и в целом его уже не используют. А вот насчёт второго я немного удивился. Связка L2TP + Ipsec вполне надёжна и безопасна. Я на Микротиках по умолчанию именно её всегда использовал, так как легко и быстро настраивается.
В новости нет пояснений на тему того, почему от L2TP + Ipsec принято решение постепенно отказываться. Поясню, что прекращение поддержки в данном случае не означает, что эти протоколы не будут работать и их будет невозможно настроить в Windows. Пока всё останется как есть, просто никакие новые возможности и нововведения, связанные с этими технологиями, не будут добавляться. Ну а со временем, скорее всего, и использование будет прекращено. Думаю, что это случится нескоро, так что сильно напрягаться по этому поводу не стоит.
Взамен Microsoft предлагает использовать SSTP и IKEv2. Про последний есть отдельное пояснение, что этот протокол особенно удобен и эффективен для мобильных пользователей. После прочтения решил проверить, а что вообще предлагает мой Android 14 из встроенных средств для настройки VPN. Оказалось, что только IKEv2. Так что в этом плане как минимум у Microsoft нет расхождений с Google насчёт VPN для смартфонов.
Если есть возможность выбирать, то я в первую очередь в качестве сервера использую OpenVPN, иногда в простых случаях Wireguard, в Микротиках - L2TP. Решил посмотреть, а что вообще есть в качестве сервера на Linux для организации VPN на базе IKEv2. Кстати, поделитесь в комментариях, что вы используете для этих целей, если пользуетесь.
Стоит сказать, что IKEv2 в связке с IPsec поддерживают все современные системы. Для настройки клиентского соединения не нужно устанавливать никакой дополнительный софт. Аутентификация возможна с использованием только имени пользователя и пароля. Это огромный плюс для больших сетей, где настройка и поддержка клиентов может занимать значительные ресурсы.
Я немного погуглил. Для настройки IKEv2 в связке с IPsec, можно использовать реализацию на базе strongswan. Всё необходимое есть в пакетах дистрибутивов:
Настраивается относительно просто. Примерно так же, как и OpenVPN. Для идентификации клиентов IKEv2 нужны сертификаты. Этот вопрос решает пакет strongswan-pki. Запускаете свой CA, выпускаете сертификат для сервера. Клиентов можете аутентифицировать как по сертификатам, так и просто по логину с паролем. Хранить их можно в обычном текстовом файле на сервере. Дополнительной защитой будет служить то, что клиенты должны будут доверять сертификату VPN сервера. Для этого ваш CA нужно будет добавить в доверенные сертификаты, либо изначально использовать доверенный сертификат для сервера (можно использовать от let's encrypt).
Основное неудобство подобного сервера по сравнению с тем же OpenVPN - нет возможности со стороны сервера управлять маршрутами клиентов. То есть либо всё отправляем в VPN туннель, либо как-то по-другому настраиваем на клиенте маршруты. Ну а плюс я уже назвал - нативная поддержка со стороны всех современных ОС. Не нужно ставить дополнительный софт.
Для простых site-to-site соединений, то есть для объединения офисов или других распределённых сетей можно использовать только пакет strongswan, который позволяет организовать обычный ipsec канал без использования сертификатов. Просто два конфига ipsec на обоих серверах и секрет для шифрования.
#vpn #IKEv2 #ipsec
В новости нет пояснений на тему того, почему от L2TP + Ipsec принято решение постепенно отказываться. Поясню, что прекращение поддержки в данном случае не означает, что эти протоколы не будут работать и их будет невозможно настроить в Windows. Пока всё останется как есть, просто никакие новые возможности и нововведения, связанные с этими технологиями, не будут добавляться. Ну а со временем, скорее всего, и использование будет прекращено. Думаю, что это случится нескоро, так что сильно напрягаться по этому поводу не стоит.
Взамен Microsoft предлагает использовать SSTP и IKEv2. Про последний есть отдельное пояснение, что этот протокол особенно удобен и эффективен для мобильных пользователей. После прочтения решил проверить, а что вообще предлагает мой Android 14 из встроенных средств для настройки VPN. Оказалось, что только IKEv2. Так что в этом плане как минимум у Microsoft нет расхождений с Google насчёт VPN для смартфонов.
Если есть возможность выбирать, то я в первую очередь в качестве сервера использую OpenVPN, иногда в простых случаях Wireguard, в Микротиках - L2TP. Решил посмотреть, а что вообще есть в качестве сервера на Linux для организации VPN на базе IKEv2. Кстати, поделитесь в комментариях, что вы используете для этих целей, если пользуетесь.
Стоит сказать, что IKEv2 в связке с IPsec поддерживают все современные системы. Для настройки клиентского соединения не нужно устанавливать никакой дополнительный софт. Аутентификация возможна с использованием только имени пользователя и пароля. Это огромный плюс для больших сетей, где настройка и поддержка клиентов может занимать значительные ресурсы.
Я немного погуглил. Для настройки IKEv2 в связке с IPsec, можно использовать реализацию на базе strongswan. Всё необходимое есть в пакетах дистрибутивов:
# apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins
Настраивается относительно просто. Примерно так же, как и OpenVPN. Для идентификации клиентов IKEv2 нужны сертификаты. Этот вопрос решает пакет strongswan-pki. Запускаете свой CA, выпускаете сертификат для сервера. Клиентов можете аутентифицировать как по сертификатам, так и просто по логину с паролем. Хранить их можно в обычном текстовом файле на сервере. Дополнительной защитой будет служить то, что клиенты должны будут доверять сертификату VPN сервера. Для этого ваш CA нужно будет добавить в доверенные сертификаты, либо изначально использовать доверенный сертификат для сервера (можно использовать от let's encrypt).
Основное неудобство подобного сервера по сравнению с тем же OpenVPN - нет возможности со стороны сервера управлять маршрутами клиентов. То есть либо всё отправляем в VPN туннель, либо как-то по-другому настраиваем на клиенте маршруты. Ну а плюс я уже назвал - нативная поддержка со стороны всех современных ОС. Не нужно ставить дополнительный софт.
Для простых site-to-site соединений, то есть для объединения офисов или других распределённых сетей можно использовать только пакет strongswan, который позволяет организовать обычный ipsec канал без использования сертификатов. Просто два конфига ipsec на обоих серверах и секрет для шифрования.
#vpn #IKEv2 #ipsec
TECHCOMMUNITY.MICROSOFT.COM
PPTP and L2TP deprecation: A new era of secure connectivity | Microsoft Community Hub
Start transitioning to SSTP and IKEv2 from PPTP and L2TP protocols on Windows Server
👍91👎4
Существует популярная панель для управления сервером с прицелом на персональное использование в качестве некоего домашнего сервера. Речь пойдёт про CasaOS - популярный open source проект. Ставится поверх обычного дистрибутива Linux. Я установил на Debian и попробовал его для решения некоторых задач. В частности своего личного WireGuard сервера в связке с AdGuard Home для блокировки рекламы на компьютерах или смартфонах.
Не знаю, за что CasaOS снискала свою популярность. Скорее всего за лёгкий и красивый веб интерфейс. Похожие проекты существую давно. Например, Runtipi, про который я ранее уже писал. Там, кстати, в комментариях как раз CasaOS упоминали. По своей сути это просто веб интерфейс поверх работающих Docker контейнеров, которые устанавливаются из встроенного магазина преднастроенных приложений.
Можно было бы предположить, что это продукт для тех, кто не умеет и не хочет уметь работать с консолью Linux, ничего не знает, а хочет просто мышкой потыкать и получить настроенный сервер. Но на самом деле с CasaOS это так не работает. Без знаний особенностей работы Docker контейнеров настроить нормальную работу всех сервисов скорее всего не получится. В консоль ходить не обязательно, но некоторые настройки контейнеров после установки нужно будет делать.
Сразу приведу список приложений, которые можно установить в CasaOS. Вообще, их огромное количество. Есть всё, что только можно. Сообщество насоздавало своих магазинов, которые регулярно поддерживаются и обновляются. Вот самые популярные:
◽️big-bear-casaos
◽️CasaOS-LinuxServer-AppStore
◽️CasaOS-Coolstore
◽️CasaOS-HomeAutomation-AppStore
Получается внушительный набор. Для личного сервера есть всё необходимое: FileBrowser, Nginx Proxy Manager, WireGuard, AdGuard Home, Syncthing, Transmission, Nextcloud и многое другое.
Установить CasaOS очень просто. Берём чистый сервер и ставим:
На выходе получаем работающий веб интерфейс по IP адресу сервера. При первом входе нужно будет создать учётку. Дальше я настроил и потестировал прикладную связку из WireGuard + AdGuard. Сначала установил AdGuard Home. Первый вход из админки запускает стандартный установщик AdGuard, который в том числе настраивает доступ к веб интерфейсу. По умолчанию это будет 80-й порт, но он уже занят интерфейсом самого CasaOS. Поэтому после установки контейнера, надо зайти в настройки AdGuard Home и добавить проброс ещё одного порта к уже существующим: 8080 ⇨ 80. Теперь по IP адресу сервера и порту 8080 можно попасть в веб интерфейс AdGuard.
Потом установил WireGuard Easy. После установки зашёл в настройки приложения и отредактировал некоторые параметры. В переменной PASSWORD установил свой пароль. В переменной WG_HOST указал IP адрес сервера, в WG_DEFAULT_DNS указал IP адрес контейнера с AdGuard Home. Так как он устанавливался первым, IP адрес у него 172.17.0.2.
Ну и всё. Дальше зашёл в веб интерфейс WG-Easy, создал пользователя. Импортировал конфиг в смартфон и подключился. Смартфон автоматом весь трафик завернул в туннель, а в качестве DNS сервера стал использовать контейнер AdGuard Home. А в нём можно настроить различные блокировки как по спискам рекламы, так и целые сервисы. Например, можно заблокировать полностью Youtube или VK. Таким же образом WG можно подключить на компьютере (проверил, работает) или на роутере. Причём на роутере не обязательно весь трафик заворачивать в туннель. Можно использовать только DNS сервер от AdGuard Home для блокировки рекламы.
Эту связку можно использовать для различных задач. Не буду подробно на этом останавливаться, так как за это уже начали наказывать. Пока в виде предупреждений. Авторы сайтов и ютуб каналов уже получают уведомления от Роскомнадзора. Так что если вы автор контента, имейте ввиду.
В целом, панель приятная. Если понимаешь особенности работы контейнеров, проблем не будет. Можно быстро всё настроить и связать друг с другом.
⇨ Сайт / Исходники / Demo (casaos / casaos)
#linux
Не знаю, за что CasaOS снискала свою популярность. Скорее всего за лёгкий и красивый веб интерфейс. Похожие проекты существую давно. Например, Runtipi, про который я ранее уже писал. Там, кстати, в комментариях как раз CasaOS упоминали. По своей сути это просто веб интерфейс поверх работающих Docker контейнеров, которые устанавливаются из встроенного магазина преднастроенных приложений.
Можно было бы предположить, что это продукт для тех, кто не умеет и не хочет уметь работать с консолью Linux, ничего не знает, а хочет просто мышкой потыкать и получить настроенный сервер. Но на самом деле с CasaOS это так не работает. Без знаний особенностей работы Docker контейнеров настроить нормальную работу всех сервисов скорее всего не получится. В консоль ходить не обязательно, но некоторые настройки контейнеров после установки нужно будет делать.
Сразу приведу список приложений, которые можно установить в CasaOS. Вообще, их огромное количество. Есть всё, что только можно. Сообщество насоздавало своих магазинов, которые регулярно поддерживаются и обновляются. Вот самые популярные:
◽️big-bear-casaos
◽️CasaOS-LinuxServer-AppStore
◽️CasaOS-Coolstore
◽️CasaOS-HomeAutomation-AppStore
Получается внушительный набор. Для личного сервера есть всё необходимое: FileBrowser, Nginx Proxy Manager, WireGuard, AdGuard Home, Syncthing, Transmission, Nextcloud и многое другое.
Установить CasaOS очень просто. Берём чистый сервер и ставим:
# curl -fsSL https://get.casaos.io | sudo bash
На выходе получаем работающий веб интерфейс по IP адресу сервера. При первом входе нужно будет создать учётку. Дальше я настроил и потестировал прикладную связку из WireGuard + AdGuard. Сначала установил AdGuard Home. Первый вход из админки запускает стандартный установщик AdGuard, который в том числе настраивает доступ к веб интерфейсу. По умолчанию это будет 80-й порт, но он уже занят интерфейсом самого CasaOS. Поэтому после установки контейнера, надо зайти в настройки AdGuard Home и добавить проброс ещё одного порта к уже существующим: 8080 ⇨ 80. Теперь по IP адресу сервера и порту 8080 можно попасть в веб интерфейс AdGuard.
Потом установил WireGuard Easy. После установки зашёл в настройки приложения и отредактировал некоторые параметры. В переменной PASSWORD установил свой пароль. В переменной WG_HOST указал IP адрес сервера, в WG_DEFAULT_DNS указал IP адрес контейнера с AdGuard Home. Так как он устанавливался первым, IP адрес у него 172.17.0.2.
Ну и всё. Дальше зашёл в веб интерфейс WG-Easy, создал пользователя. Импортировал конфиг в смартфон и подключился. Смартфон автоматом весь трафик завернул в туннель, а в качестве DNS сервера стал использовать контейнер AdGuard Home. А в нём можно настроить различные блокировки как по спискам рекламы, так и целые сервисы. Например, можно заблокировать полностью Youtube или VK. Таким же образом WG можно подключить на компьютере (проверил, работает) или на роутере. Причём на роутере не обязательно весь трафик заворачивать в туннель. Можно использовать только DNS сервер от AdGuard Home для блокировки рекламы.
Эту связку можно использовать для различных задач. Не буду подробно на этом останавливаться, так как за это уже начали наказывать. Пока в виде предупреждений. Авторы сайтов и ютуб каналов уже получают уведомления от Роскомнадзора. Так что если вы автор контента, имейте ввиду.
В целом, панель приятная. Если понимаешь особенности работы контейнеров, проблем не будет. Можно быстро всё настроить и связать друг с другом.
⇨ Сайт / Исходники / Demo (casaos / casaos)
#linux
2👍108👎4
Уважаемые сисадмины, у меня для вас очень интересная и полезная система удалённого управления - Rport. А точнее её форк - OpenRPort. Сам Rport был куплен коммерческой организацией, которая закрыла исходники, а OpenRPort остался open source.
Про OpenRPort узнал случайно из видео в youtube. Раньше про неё не знал и не слышал. Развернул у себя, попробовал. Очень понравилось. Внимательно проверил все возможности и теперь готов вам об этом рассказать. Постараюсь вместить всё в формат заметки.
Кратко, что такое OpenRPort - клиент-серверная система для управления компьютерами, серверами и прочим оборудованием. Похожа немного на MeshCentral и Apache Guacamole вместе взятые, но со своими особенностями. По возможностям OpenRPort понравилась больше этих программ. Она предназначена не только для удалённых подключений к экранам.
📌 Особенности OpenRPort:
◽️Сервер может быть установлен как только в локальной сети или с доступом по VPN, так и с доступом через интернет напрямую или проброс портов.
◽️Для управления клиентами на них ставится агент.
◽️Аутентификация пользователей может быть двухфакторной с отправкой токенов на email, пушами на смартфон или использованием TOTP.
◽️Доступ к экрану клиентов осуществляется через проброс портов с сервера OpenRPort до клиента. Для подключения используются встроенные инструменты самой системы, типа RDP и SSH, либо какое-то стороннее ПО.
◽️Доступ по RDP возможен как через RDP клиент с загрузкой .rdp файла для подключения, так и через браузер непосредственно из веб интерфейса OpenRPort.
◽️На клиентах можно выполнять различные консольные команды или скрипты, делая выборку по разным группам или тэгам. Команды и скрипты можно запускать регулярно через планировщик.
◽️Для клиентов осуществляется простой мониторинг основных метрик (CPU, Memory, Network, Disk) и отображается список запущенных процессов.
◽️Для каждого клиента можно настроить несколько разных туннелей от сервера. Например, пробросить RDP порт и HTTP для доступа к какому-то локальному сервису.
Из описания видно, что система может одинаково эксплуатироваться как системными администраторами, так и пользователями компьютеров. Им можно организовать удалённый доступ к их рабочим местам или каким-то внутренним сервисам. Например, у вас есть какая-то локальная веб система с доступом через браузер. Вы можете пользователей запускать в неё через личный кабинет OpenRPort.
Отдельно расскажу про систему туннелей к клиентам. Мне эта возможность особенно понравилась. Реализована она следующим образом. Администратор системы может настроить туннель от сервера (10.20.1.36) к клиенту (10.20.1.53). Например, указывает локальный порт сервера 20011 и порт клиента 3389. На сервере будет поднят туннель 10.20.1.36:20011 ⇨ 10.20.1.53:3389. И отдельно можно указать, что этот туннель доступен только пользователю с IP адресом 10.8.2.2 или всей подсети 10.8.2.0/24.
Вы можете подключиться по этому туннелю как через веб интерфейс, так и любой другой софт. Туннель может быть постоянным, с ограничением по времени, то есть выключится, к примеру, через 2 часа принудительно. Либо его можно отключить после 5-ти минут неактивности. Для каждого клиента может быть много подобных туннелей с разными параметрами и доступом. Туннели открывает на сервере служба rportd. Они все видны через
Установить и настроить OpenRPort легко. У меня сходу получилось по инструкции. Ставил на чистый Debian 12:
В консоли увидите адрес для подключения и учётку админа. Без fqdn с IP адресом нормально работает. Будет выпущен самоподписный сертификат.
В веб интерфейсе создаёте клиента, получаете cli команду для установки агента, ставите его и клиент автоматически появляется в системе.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Сайт / Исходники
#remote
Про OpenRPort узнал случайно из видео в youtube. Раньше про неё не знал и не слышал. Развернул у себя, попробовал. Очень понравилось. Внимательно проверил все возможности и теперь готов вам об этом рассказать. Постараюсь вместить всё в формат заметки.
Кратко, что такое OpenRPort - клиент-серверная система для управления компьютерами, серверами и прочим оборудованием. Похожа немного на MeshCentral и Apache Guacamole вместе взятые, но со своими особенностями. По возможностям OpenRPort понравилась больше этих программ. Она предназначена не только для удалённых подключений к экранам.
📌 Особенности OpenRPort:
◽️Сервер может быть установлен как только в локальной сети или с доступом по VPN, так и с доступом через интернет напрямую или проброс портов.
◽️Для управления клиентами на них ставится агент.
◽️Аутентификация пользователей может быть двухфакторной с отправкой токенов на email, пушами на смартфон или использованием TOTP.
◽️Доступ к экрану клиентов осуществляется через проброс портов с сервера OpenRPort до клиента. Для подключения используются встроенные инструменты самой системы, типа RDP и SSH, либо какое-то стороннее ПО.
◽️Доступ по RDP возможен как через RDP клиент с загрузкой .rdp файла для подключения, так и через браузер непосредственно из веб интерфейса OpenRPort.
◽️На клиентах можно выполнять различные консольные команды или скрипты, делая выборку по разным группам или тэгам. Команды и скрипты можно запускать регулярно через планировщик.
◽️Для клиентов осуществляется простой мониторинг основных метрик (CPU, Memory, Network, Disk) и отображается список запущенных процессов.
◽️Для каждого клиента можно настроить несколько разных туннелей от сервера. Например, пробросить RDP порт и HTTP для доступа к какому-то локальному сервису.
Из описания видно, что система может одинаково эксплуатироваться как системными администраторами, так и пользователями компьютеров. Им можно организовать удалённый доступ к их рабочим местам или каким-то внутренним сервисам. Например, у вас есть какая-то локальная веб система с доступом через браузер. Вы можете пользователей запускать в неё через личный кабинет OpenRPort.
Отдельно расскажу про систему туннелей к клиентам. Мне эта возможность особенно понравилась. Реализована она следующим образом. Администратор системы может настроить туннель от сервера (10.20.1.36) к клиенту (10.20.1.53). Например, указывает локальный порт сервера 20011 и порт клиента 3389. На сервере будет поднят туннель 10.20.1.36:20011 ⇨ 10.20.1.53:3389. И отдельно можно указать, что этот туннель доступен только пользователю с IP адресом 10.8.2.2 или всей подсети 10.8.2.0/24.
Вы можете подключиться по этому туннелю как через веб интерфейс, так и любой другой софт. Туннель может быть постоянным, с ограничением по времени, то есть выключится, к примеру, через 2 часа принудительно. Либо его можно отключить после 5-ти минут неактивности. Для каждого клиента может быть много подобных туннелей с разными параметрами и доступом. Туннели открывает на сервере служба rportd. Они все видны через
ss
или netstat
. Установить и настроить OpenRPort легко. У меня сходу получилось по инструкции. Ставил на чистый Debian 12:
# curl -o rportd-installer.sh https://get.openrport.io
# bash rportd-installer.sh \
--email [email protected] \
--client-port 8000 \
--api-port 5000 \
--fqdn 10.20.1.36 \
--port-range 20000-20050 \
--no-2fa
В консоли увидите адрес для подключения и учётку админа. Без fqdn с IP адресом нормально работает. Будет выпущен самоподписный сертификат.
В веб интерфейсе создаёте клиента, получаете cli команду для установки агента, ставите его и клиент автоматически появляется в системе.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Сайт / Исходники
#remote
3👍283👎5
Наглядный пример, почему не стоит сохранять пароли в браузерах. Их оттуда очень легко утянуть незаметно для пользователя. Я что 10 лет назад видел, как это просто сделать, что сейчас.
До последнего думал, что у меня ничего не получится, когда пробовал. Не верил, что за столько лет в хроме ничего не поменялось. Что-то может и поменялось, но всё равно все пароли можно разом утянуть. Можете сами проверить.
Пример для ОС Windows. Идём в репозиторий:
⇨ https://github.com/ohyicong/decrypt-chrome-passwords
Скачиваем исходник файла decrypt_chrome_password.py. Ставим на машину python. Уже не помню, как я ставил на тестовую тачку. Он тут уже стоял на тот момент, когда я тестировал.
Установил зависимости:
Запускаю скрипт. Перед этим специально сохранил пароль от одного сайта:
Получаю тут же в консоли логин и пароль в открытом виде. Он же лежит рядом со скриптом в файле decrypted_password.csv. В нём будут лежать все сохранённые в браузере пароли.
Я перестал сохранять важные пароли в браузерах с тех пор, как впервые увидел подобный трюк. Какие-то малозначительные сохраняю для удобства, либо где есть второй фактор. На что-то важное отменяю сохранение.
#security
До последнего думал, что у меня ничего не получится, когда пробовал. Не верил, что за столько лет в хроме ничего не поменялось. Что-то может и поменялось, но всё равно все пароли можно разом утянуть. Можете сами проверить.
Пример для ОС Windows. Идём в репозиторий:
⇨ https://github.com/ohyicong/decrypt-chrome-passwords
Скачиваем исходник файла decrypt_chrome_password.py. Ставим на машину python. Уже не помню, как я ставил на тестовую тачку. Он тут уже стоял на тот момент, когда я тестировал.
Установил зависимости:
> pip install pycryptodomex sqlite sqlite
Запускаю скрипт. Перед этим специально сохранил пароль от одного сайта:
> python decrypt_chrome_password.py
Получаю тут же в консоли логин и пароль в открытом виде. Он же лежит рядом со скриптом в файле decrypted_password.csv. В нём будут лежать все сохранённые в браузере пароли.
Я перестал сохранять важные пароли в браузерах с тех пор, как впервые увидел подобный трюк. Какие-то малозначительные сохраняю для удобства, либо где есть второй фактор. На что-то важное отменяю сохранение.
#security
👍148👎10
Небольшое предупреждение для тех, кто администрирует сайты и получает на них Abuse от РКН. Если на сайтах открыта регистрация пользователей и есть возможность публиковать текст, то это только вопрос времени, когда вы получите требование удалить ту или иную информацию, нарушающую закон. Боты или реальные люди будут пытаться оставить ссылку на запрещёнку везде, где это возможно: комментарии, отзывы, сообщения на форуме, поля для комментариев в профиле и т.д.
Уведомления приходят сначала провайдерам, а они уже уведомляют владельцев сайтов. Даются сутки на удаление противозаконной информации. Вот точная информация на этот счёт:
Провайдер хостинга или иное лицо, обеспечивающее размещение информационного ресурса в сети «Интернет» (далее – иное лицо, разместившее информационный ресурс), с момента получения настоящего уведомления обязаны:
- незамедлительно проинформировать владельца информационного ресурса о необходимости незамедлительного удаления распространяемой с нарушением закона информации;
- по истечении суток ограничить доступ к информационному ресурсу в случае отказа или бездействия владельца информационного ресурса в удалении распространяемой с нарушением закона информации.
В сообщении от провайдера обычно в тикете указана вся необходимая информация. Я просто иду и удаляю то, что там указано. Когда удалю, пишу провайдеру, что сделал это. На этом всё, больше ничего не предпринимаю. К тикету прикладывается исходное уведомление от РКН, которое я обычно не читаю, так как там всё то же самое, только канцелярским языком.
На днях получил подобное уведомление. Информацию удалил. Решил прочитать исходный текст уведомления от РКН. А он существенно изменился в сравнении с тем, что я получал ещё в сентябре. В заявлении указан уникальный идентификатор. Используя этот идентификатор, необходимо отчитаться об удалении либо по email, либо через специальную форму на сайте 398-fz.rkn.gov.ru. В уведомлении есть ссылка с зашитой информацией об основных данных по этому уведомлению.
Если вы владелец или администратор сайта, то нельзя просто так взять и позволить пользователям без премодерации что-то публиковать. Вы должны либо в течении суток реагировать на обращения, либо включать премодерацию и удалять весь возможный противоправный контент заранее. Если быстро не отреагировать, то можно получить блокировку сайта.
❗️И ещё дам небольшой совет, который может сэкономить ваше время. В требовании может прийти ссылка как со слешом на конце, так и без. Я не знаю, кто и как её формирует, но сталкивался не раз. На веб сервере может быть не настроен редирект ссылок без слеша на слеш и наоборот. Речь вот о чём. Ссылки https://398-fz.rkn.gov.ru/toproviders/ и https://398-fz.rkn.gov.ru/toproviders по сути разные.
Вам может прийти требование, где указана ссылка без слеша на конце. Вы идёте на сайт и видите, что такой страницы нет, либо, что ещё хуже, можете увидеть вообще какую-то информацию, не относящуюся непосредственно к этому урлу. Некоторые CMS или самописные сайты могут по разному обрабатывать эти ситуации. Так что проверяйте на всякий случай оба варианта.
#webserver
Уведомления приходят сначала провайдерам, а они уже уведомляют владельцев сайтов. Даются сутки на удаление противозаконной информации. Вот точная информация на этот счёт:
Провайдер хостинга или иное лицо, обеспечивающее размещение информационного ресурса в сети «Интернет» (далее – иное лицо, разместившее информационный ресурс), с момента получения настоящего уведомления обязаны:
- незамедлительно проинформировать владельца информационного ресурса о необходимости незамедлительного удаления распространяемой с нарушением закона информации;
- по истечении суток ограничить доступ к информационному ресурсу в случае отказа или бездействия владельца информационного ресурса в удалении распространяемой с нарушением закона информации.
В сообщении от провайдера обычно в тикете указана вся необходимая информация. Я просто иду и удаляю то, что там указано. Когда удалю, пишу провайдеру, что сделал это. На этом всё, больше ничего не предпринимаю. К тикету прикладывается исходное уведомление от РКН, которое я обычно не читаю, так как там всё то же самое, только канцелярским языком.
На днях получил подобное уведомление. Информацию удалил. Решил прочитать исходный текст уведомления от РКН. А он существенно изменился в сравнении с тем, что я получал ещё в сентябре. В заявлении указан уникальный идентификатор. Используя этот идентификатор, необходимо отчитаться об удалении либо по email, либо через специальную форму на сайте 398-fz.rkn.gov.ru. В уведомлении есть ссылка с зашитой информацией об основных данных по этому уведомлению.
Если вы владелец или администратор сайта, то нельзя просто так взять и позволить пользователям без премодерации что-то публиковать. Вы должны либо в течении суток реагировать на обращения, либо включать премодерацию и удалять весь возможный противоправный контент заранее. Если быстро не отреагировать, то можно получить блокировку сайта.
❗️И ещё дам небольшой совет, который может сэкономить ваше время. В требовании может прийти ссылка как со слешом на конце, так и без. Я не знаю, кто и как её формирует, но сталкивался не раз. На веб сервере может быть не настроен редирект ссылок без слеша на слеш и наоборот. Речь вот о чём. Ссылки https://398-fz.rkn.gov.ru/toproviders/ и https://398-fz.rkn.gov.ru/toproviders по сути разные.
Вам может прийти требование, где указана ссылка без слеша на конце. Вы идёте на сайт и видите, что такой страницы нет, либо, что ещё хуже, можете увидеть вообще какую-то информацию, не относящуюся непосредственно к этому урлу. Некоторые CMS или самописные сайты могут по разному обрабатывать эти ситуации. Так что проверяйте на всякий случай оба варианта.
#webserver
1👍123👎20
Несмотря на то, что сейчас существует очень много современных решений по сбору и обработке логов, старый текстовый формат syslog не потерял полностью актуальность. Причин тому несколько. Перечислю то, что сам вспомнил:
◽️Формат популярен для сетевого оборудования, IPMI серверов.
◽️Нетребователен к ресурсам железа.
◽️Нет необходимости изменения конфигурации сервера для приёма новых логов.
◽️Это стандарт для ведения логов в POSIX-совместимых системах.
◽️Много софта поддерживают формат syslog, нет необходимости устанавливать дополнительное ПО на клиентах.
◽️Легко ротировать логи с помощью logrotate.
Я использую syslog регулярно, несмотря на то, что для глобального хранения логов устанавливаю ELK Stack. Использую его, если нужна какая-то аналитика по логам, а не просто хранение текстовых данных.
Наиболее частое использование формата syslog - сбор логов с Микротиков. Сами они хранят логи только до перезагрузки. Если где-то есть любой Linux сервер, собираю там текстовые логи с Микротиков. Аналитика обычно не нужна. Важно просто иметь представление о том, что происходило на устройстве, так как перезагрузка по различным причинам логи очистит. Писал когда-то давно статью по этому поводу. Она не потеряла актуальность, так как ни настройка роутеров не поменялась, ни rsyslog.
Второй пример использования - быстро собрать логи для анализа содержимого с помощью Zabbix. Для анализа обычных текстовых логов не нужны никакие костыли и дополнительные настройки. Zabbix встроенными средствами может их читать и анализировать с помощью regex. Это позволяет очень просто и быстро настроить какие-нибудь уведомления на события. Например, аутентификацию по SSH.
Соответственно, если вам нужно что-то быстро связать с системой мониторинга Zabbix и это что-то умеет писать логи в формате syslog, настройка мониторинга очень сильно упрощается. Можно прямо на Zabbix Server настроить rsyslog на приём логов по сети. Для этого необходимо в
И перезапустить службу:
Проверяем, слушает ли rsyslog входящие подключения:
Если слушает 514 порт, то можно отправлять на него логи. Обычно в настройках оборудования или софта достаточно просто указать IP адрес сервера с rsyslog, чтобы потекли данные на сервер. Дополнительно можно задать порт, если используете не стандартный, facility (категория), severity (важность).
Если больше не менять настройки, то все логи будут писаться в общий syslog файл. Обычно это
Данное правило будет автоматически раскладывать все логи с удаленных устройств по файлам в директории
Для удобного просмотра подобных логов можно использовать какой-то простенький веб интерфейс. Я описывал некоторые из них:
▪️tailon
Ожидал тут сделать список из таких инструментов, но оказалось, что кроме tailon больше ничего и не знаю. Если кто-то знает, чем удобно просматривать текстовые логи Linux через браузер, поделитесь информацией.
Можно взять тот же Webmin. Там неплохой раздел для просмотра локальных логов. Похожая возможность есть и в Cockpit.
☝️ Кстати, кто-то может не знает, что rsyslog агент есть и под Windows. Он формат виндовых логов преобразует в syslog и отправляет на rsyslog сервер.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs
◽️Формат популярен для сетевого оборудования, IPMI серверов.
◽️Нетребователен к ресурсам железа.
◽️Нет необходимости изменения конфигурации сервера для приёма новых логов.
◽️Это стандарт для ведения логов в POSIX-совместимых системах.
◽️Много софта поддерживают формат syslog, нет необходимости устанавливать дополнительное ПО на клиентах.
◽️Легко ротировать логи с помощью logrotate.
Я использую syslog регулярно, несмотря на то, что для глобального хранения логов устанавливаю ELK Stack. Использую его, если нужна какая-то аналитика по логам, а не просто хранение текстовых данных.
Наиболее частое использование формата syslog - сбор логов с Микротиков. Сами они хранят логи только до перезагрузки. Если где-то есть любой Linux сервер, собираю там текстовые логи с Микротиков. Аналитика обычно не нужна. Важно просто иметь представление о том, что происходило на устройстве, так как перезагрузка по различным причинам логи очистит. Писал когда-то давно статью по этому поводу. Она не потеряла актуальность, так как ни настройка роутеров не поменялась, ни rsyslog.
Второй пример использования - быстро собрать логи для анализа содержимого с помощью Zabbix. Для анализа обычных текстовых логов не нужны никакие костыли и дополнительные настройки. Zabbix встроенными средствами может их читать и анализировать с помощью regex. Это позволяет очень просто и быстро настроить какие-нибудь уведомления на события. Например, аутентификацию по SSH.
Соответственно, если вам нужно что-то быстро связать с системой мониторинга Zabbix и это что-то умеет писать логи в формате syslog, настройка мониторинга очень сильно упрощается. Можно прямо на Zabbix Server настроить rsyslog на приём логов по сети. Для этого необходимо в
/etc/rsyslog.conf
раскомментировать:module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")
И перезапустить службу:
# systemctl restart rsyslog
Проверяем, слушает ли rsyslog входящие подключения:
# ss -tulnp | grep rsyslogd
Если слушает 514 порт, то можно отправлять на него логи. Обычно в настройках оборудования или софта достаточно просто указать IP адрес сервера с rsyslog, чтобы потекли данные на сервер. Дополнительно можно задать порт, если используете не стандартный, facility (категория), severity (важность).
Если больше не менять настройки, то все логи будут писаться в общий syslog файл. Обычно это
/var/log/syslog
. Удобно их разделять либо по IP адресам отправителей, либо по приложениям, которые их отправляют. Я чаще по хостам разделяю логи. Для этого надо задать шаблон формирования лог-файлов. Добавляем в rsyslog.conf
:$template FILENAME,"/var/log/syslog/%fromhost-ip%.log"
if $fromhost-ip != '127.0.0.1' then ?FILENAME
& stop
Данное правило будет автоматически раскладывать все логи с удаленных устройств по файлам в директории
/var/log/syslog
с именами в виде IP адресов. При этом мы исключаем туда запись локальных логов, иначе они появятся под адресом 127.0.0.1, и предотвращаем их запись в системный syslog файл. По шаблонам наглядные примеры есть в документации. Для удобного просмотра подобных логов можно использовать какой-то простенький веб интерфейс. Я описывал некоторые из них:
▪️tailon
Ожидал тут сделать список из таких инструментов, но оказалось, что кроме tailon больше ничего и не знаю. Если кто-то знает, чем удобно просматривать текстовые логи Linux через браузер, поделитесь информацией.
Можно взять тот же Webmin. Там неплохой раздел для просмотра локальных логов. Похожая возможность есть и в Cockpit.
☝️ Кстати, кто-то может не знает, что rsyslog агент есть и под Windows. Он формат виндовых логов преобразует в syslog и отправляет на rsyslog сервер.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs
👍159👎3