$AllowedDHCPServer = "ЗДЕСЬ_АЙПИШНИК_ТВОЕГО_DHCP"

#Замените URL-адрес загрузки на тот, куда вы сами загрузили файл DHCPTest. Мы загрузим этот файл только один раз.
$DownloadURL = "https://files.cy.md/dhcptest/dhcptest-0.9-win64.exe"
$DownloadLocation = "$(pwd)\DHCPTest"

$BotToken = "СЮДА_СУЙ_ТОКЕН_БОТА"
# Объявление массива с идентификаторами чатов
$ChatIDs = @("USERID1", "USERID2")
$NMinutes = 1 # Интервал времени для повторения проверки в минутах

# Функция для отправки сообщений в Telegram
function Send-TelegramMessage {
    param (
        [Parameter(Mandatory=$true)]
        [string]$MessageText,
        [Parameter(Mandatory=$true)]
        [string[]]$ChatIDs
    )
    $TelegramAPI = "https://api.telegram.org/bot$BotToken/sendMessage"
    foreach ($ChatID in $ChatIDs) {
        $params = @{
            chat_id = $ChatID
            text = $MessageText
            parse_mode = "Markdown"
        }
        $response = Invoke-WebRequest -Uri $TelegramAPI -Method Post -Body $params -ContentType "application/x-www-form-urlencoded"
    }
}

# Бесконечный цикл для периодической проверки
while ($true) {
    try {
        $TestDownloadLocation = Test-Path $DownloadLocation
        if (!$TestDownloadLocation) { New-Item $DownloadLocation -ItemType Directory -Force }
        $TestDownloadLocationZip = Test-Path "$DownloadLocation\DHCPTest.exe"
        if (!$TestDownloadLocationZip) { Invoke-WebRequest -UseBasicParsing -Uri $DownloadURL -OutFile "$($DownloadLocation)\DHCPTest.exe" }
    }
    catch {
        $ErrorMessage = "Загрузка и извлечение DHCPTest не удались. Ошибка: $($_.Exception.Message)"
        Send-TelegramMessage -MessageText $ErrorMessage -ChatIDs $ChatIDs
        break # Выход из цикла в случае ошибки
    }

    $Tests = 0
    $ListedDHCPServers = do {
        & "$DownloadLocation\DHCPTest.exe" --quiet --query --print-only 54 --wait --timeout 3
        $Tests++
    } while ($Tests -lt 2)

    $DHCPHealthMessages = @()
    foreach ($ListedServer in $ListedDHCPServers) {
        if ($ListedServer -ne $AllowedDHCPServer) {
            # Выполнение команды ping для гарантии наличия IP в ARP-таблице
            ping $ListedServer -n 1 | Out-Null
            # Получение MAC-адреса из ARP-таблицы
            $arpResult = [String]::Join(' ', (arp -a $ListedServer ))
            $MACAddress = if ($arpResult -match "(\w{2}-\w{2}-\w{2}-\w{2}-\w{2}-\w{2})") {$matches[0]} else {"MAC адрес не найден"}
            
            $DHCPHealthMessages += "Обнаружен неавторизованный DHCP-сервер. IP-адрес неавторизованного сервера: $ListedServer, MAC адрес: $MACAddress"
        }
    }

    if ($DHCPHealthMessages.Count -gt 0) {
        $DHCPHealthMessage = $DHCPHealthMessages -join "`n"
        Send-TelegramMessage -MessageText $DHCPHealthMessage -ChatIDs $ChatIDs
    }
    
    Start-Sleep -Seconds ($NMinutes * 60) # Пауза перед следующей итерацией цикла
}

#network #dhcp

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

Возьму популярный пример, когда вы арендуете выделенный сервер и с ним /29 подсеть. Либо у вас в офис от провайдера приходит провод с /29 подсетью, а это всё воткнуто в какой-то шлюз. Например, в Mikrotik. Тогда заметка будет актуальна для обоих ситуаций, так как в Mikrotik линуксовый файрвол iptables. Принцип настройки которого один и тот же.

Итак, у вас сервер и несколько IP адресов. Если это гипервизор, то у вас могут быть 2 принципиально разных варианта настроек:

1️⃣ Вы делаете сетевой бридж с интерфейсом, на который приходят IP адреса. На самом гипервизоре и на виртуальных машинах настраиваете этот бридж. Файрвол на гипервизоре можно вообще не настраивать, он тут не нужен для управления трафиком. Каждая VM получает свой внешний IP адрес. Это самый простой вариант настройки. Но тут виртуалок с разными IP адресами может быть не больше, чем у вас есть IP адресов. Если нужно 3 виртуалки выпускать в интернет через один IP адрес, а 2 других через другой, то такой вариант уже не подходит.

2️⃣ У вас может быть несколько серверов и куча виртуальных машин за шлюзом, к которому подключен шнурок от провайдера. И вы хотите какие-то подсети выпускать в интернет через один IP адрес, а какие-то через другой. Здесь уже нужен будет файрвол на шлюзе. Если это гипервизор Proxmox, то можно настраивать iptables прям на нём. Но лучше вынести такую задачу на отдельную виртуальную машину.

Принцип настройки тут будет следующий. Вы на шлюзе настраиваете все внешние IP адреса, какие будете использовать. Далее с помощью iptables маркируете (mangle) трафик из разных подсетей разными метками. Признак маркировки - источник в виде адреса подсети или отдельных IP адресов, если вам не подсетями делить нужно, а отдельными адресами. После этого вы создаёте маршруты через нужные внешние IP адреса на основе меток. Трафик с разными метками будет выходить через разные IP адреса. И в завершении нужно будет добавить правила NAT (snat) для разных внешних IP адресов (--to-source). Тоже на основе меток.

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

3️⃣ Есть ещё промежуточный вариант, более простой, чем второй. Вы настраиваете, как в первом случае, каждой машине свой внешний IP адрес через бридж. И эти машины делаете шлюзами для разных подсетей. Тогда вам не придётся заниматься маркировкой и маршрутизацией как во втором случае. Ситуация менее гибкая, но зато простая в настройке.

#network

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

⇨ https://github.com/amwalding/wireshark_profiles

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

1️⃣ Скачиваете из репозитория zip файл нужного вам профиля. Например, DNS.

2️⃣ В Wireshark идёте в раздел Edit ⇨ Configuration Profiles. Жмёте Import from zip files и импортируете скачанный профайл в zip файле. Выбираете его.

3️⃣ Выбираете сетевой интерфейс, с которого хотите собирать пакеты. Откроется основной интерфейс программы с готовыми настройками фильтров.

4️⃣ Потом загруженные фильтры можно быстро переключать в правом нижнем углу программы.

Ничего особенного тут нет, можно и самому набросать себе нужные фильтры. Но тут всё сделали за нас, упростив задачу. Как минимум, не помешают базовые фильтры на DNS, DHCP, HTTP, ARP, SMB, VLAN и т.д.

#network #wireshark

​​С удивлением недавно узнал, что известный и популярный ISC DHCP Server с 2022 года не развивается и не поддерживается. Вот соответствующая новость на сайте разработчиков:

⇨ ISC DHCP Server has reached EOL

Я начинал работу с DHCP серверами в Linux как раз с этим сервером. Его базовая настройка была простая и быстрая. Один конфиг с несколькими опциями и дальше настройка подсетей и резервирований. Лог файл и выданные leases в отдельных текстовых файлах. Было удобно поддерживать и дебажить.

Со временем переехал на Dnsmasq, так как он объединяет службы dns и dhcp, что для небольших сетей удобно, поэтому за isc-dhcp следить перестал. Разработчики перестали его развивать, потому что с их слов его код труден для тестирования и внедрения нововведений. Поэтому они прекратили его поддержку, а всё развитие продолжили в новом проекте Kea DHCP, внедрив туда:

◽модульную структуру, где DHCPv4, DHCPv6, DDNS службы работают независимо друг от друга;
◽изменение конфигурации на лету через запросы к REST API;
◽конфигурация в json формате;
◽графический дашборд через web интерфейс;
◽поддержку разных бэкендов для хранения конфигурации: MySQL, PostgreSQL, Cassandra или CSV файл;
◽возмжоность настроить отказоустойчивую конфигурацию;

Сразу отмечу, что для Kea есть пакет netbox-kea-dhcp для интеграции с известным сервисом netbox.

Все компоненты kea есть в стандартном репозитории Debian. Как уже было упомянуто, структура продукта модульная, так что для каждой службы есть отдельный пакет:

▪️ kea - как я понял общий пакет, который в зависимостях тянет все остальные
▪️ kea-admin - утилиты управления
▪️ kea-common - общие библиотеки сервера
▪️ kea-ctrl-agent - служба REST API
▪️ kea-dhcp-ddns-server - служба DDNS
▪️ kea-dhcp4-server - IPv4 DHCP сервер
▪️ kea-dhcp6-server - IPv6 DHCP сервер

Есть инструмент для автоматической миграции с isc-dhcp в одно действие. Примерно так:

# keama -4 -i /etc/dhcp/dhcp4.conf -o /etc/kea/kea-dhcp4.conf

Dashboard для Kea реализован на базе отдельного продукта от тех же авторов - Stork. Помимо непосредственно веб интерфейса с информацией о работе сервисов, stork предоставляет экспорт метрик в prometheus и готовые дашборды для Grafana.

Все описанные возмжоности представлены в open source версии. Я посмотрел примеры настроек. Там всё относительно просто. Не сложнее, чем было в isc-dhcp. Вместе с веб интерфейсом, метриками и дашбордами это выглядит наиболее привлекательным dhcp сервером на текущий момент. При случае попробую его натсроить вместо dnsmasq.

#network #dhcp

Услышал неожиданную и новую для себя информацию. Нельзя последовательно соединить две и более rj45 розетки для того, чтобы пользоваться только одной из них одновременно. Работать будет только последняя розетка. Спорить не стал, но слегка удивился, так как для меня это неочевидная информация. К тому же я сам у себя в доме электрические розетки собирал и некоторые из них соединялись последовательно. То же самое для температурных датчиков делал, которые соединял последовательно на шине от контроллера. То есть для меня такая схема подключения выглядит вполне привычной. Я бы даже не подумал, что тут есть какой-то нюанс.

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

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

❗️Век живи, век учись. Знали об этом? Либо может быть сталкивались с таким соединением?

#железо #network

​​Я недавно рассказывал про namespaces в Linux. На основе этой изоляции работает множество софта. Далее будет пример одного из них, который использует network namespaces для записи дампа трафика конкретного приложения.

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

1️⃣ Создаёт отдельный network namespace для исследуемого приложения.
2️⃣ Для того, чтобы там был доступ в интернет, создаются виртуальные сетевые интерфейсы. Один в новом namespace, другой в основном. В новом используется шлюз из основного namespace. Из-за этой схемы у запускаемого приложения будет IP адрес виртуальной сети.
3️⃣ Средствами iptables трафик натится из виртуальной сети в реальную.
4️⃣ Запускает приложение в новом namespace и собирает его трафик с помощью libpcap. Результат сохраняет в обычный pcap файл.

Nsntrace есть в базовых репах Debian:

# apt install nsntrace

Самый банальный пример, чтобы проверить работу:

# nsntrace wget google.com

На выходе получаем nsntrace.pcap, который можно посмотреть тут же, если у вас есть tshark:

# tshark -r nsntrace.pcap

Можно и в режиме реального времени наблюдать:

# nsntrace -o - wget google.com 2> /dev/null | tshark -r -

Помимо обычных приложений, снимать трафик можно и со скриптов:

# nsntrace php script.php
# nsntrace python script.py

Проверим на простом python скрипте:

import requests
res = requests.get('https://ya.ru')

Запускаем анализ сетевой активности:

# nsntrace python3 script.py
Starting network trace of 'python3' on interface eth0.
Your IP address in this trace is 172.16.42.255.
Use ctrl-c to end at any time.

Finished capturing 57 packets.

Смотрим:

# tshark -r nsntrace.pcap

Можно передать .pcap на другую машину и посмотреть в Wireshark.

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

#network #perfomance

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

Берём условный сервер 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

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

Обнаружил, что тут нет заметки про 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

Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

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

⇨ Как настроить сетевые параметры в Debian

Последние 5 лет вообще её не трогал. А она не потеряла актуальность и популярность. Последние 2 года это самая посещаемая статья сайта. Каждый день по 200-300 посетителей приходят её прочитать. А за всё время её посмотрели сотни тысяч раз. Если прикинуть, то это большой масштаб. И таких статей много. То, что я написал, прочитали уже миллионы людей. Вроде сидишь себе, что-то пишешь. А тебя читает столько народа. В уникальное время живём. Надо это ценить.

Собрался с силами и переработал статью, актуализировал. Перенёс все настройки на ip, замерив ifconfig и route. Давно серьёзно не занимался сайтом и контентом нём. Это забирает очень много времени. Нет возможности его выделять. Одна переработка заняла целый день. А если писать с нуля, то нужно ещё больше времени. Для того, чтобы подобная статья вышла в топ поисковиков, приходится работать с SEO, надо это знать. Из-за этого текст выглядит немного косоязычно. Но если этого не сделать, то текст заберут другие сайты, добавят SEO и статья от них уйдёт в ТОП. Так что лучше самому сразу сделать так, как надо.

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

Статью можно использовать новичкам как шпаргалку. Там есть вся база:

◽️статические и динамические настройки ip адресов
◽️dns и hostname
◽️статические маршруты
◽️vlan
◽️отключение ipv6
◽️несколько адресов на одном интерфейсе

Узнал для себя некоторые новые вещи, на которые раньше не обращал внимание. Например, 2 типа активации сетевого интерфейса в /etc/network/interfaces:

▪️auto - интерфейс активируется при загрузке системы. Это подходящая настройка для статичного сетевого адаптера.
▪️allow-hotplug - интерфейс поднимается, когда подсистема udev обнаружит его. Это произойдёт и при загрузке системы, как в случае с auto, если сетевая карта будет подключена, и в случае подключения, отключения устройства. Например, если это usb сетевая карта или VPN туннель. Настройка больше подходит для динамических сетевых интерфейсов.

Ещё интересный момент. Если сбросить dhcp lease через консоль соответствующей командой:

# dhclient -r

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

#debian #network