Современные операционные системы сегодня живут своей жизнью. Иногда бывает забавно посмотреть на сетевой трафик и ужаснуться от того, сколько там различных сетевых соединений, которые инициировали не вы. Проще всего их отследить по DNS запросам, настроив свой DNS сервер с логированием всех запросов.
Но есть способы проще. Например, взять open source приложение Sniffnet и посмотреть в удобном виде всю сетевую активность. Причём приложение кроссплатформенное. Я сначала не понял, как такая простая и маленькая программа на Rust может одинаково работать на всех платформах. Оказалось, она использует библиотеку pcap: libpcap в unix и npcap в windows. Для тех, кто не в курсе, поясню, что это та же библиотека, что используется в Nmap и Wireshark.
Sniffnet позволяет подключиться к конкретному сетевому интерфейсу и посмотреть его активность. Работает в том числе с VPN интерфейсами. Например, если вы заворачиваете весь трафик в VPN, то на основном интерфейсе увидите только трафик в сторону VPN сервера. А если заглянете в VPN интерфейс, там уже будет детальна информация. Можно быстро проверить, точно ли весь нужный трафик идёт в VPN.
В Sniffnet можно настроить 3 типа уведомлений:
1️⃣ Превышение порога по частоте передачи пакетов.
2️⃣ Превышение порога полосы пропускания.
3️⃣ Соединение с указанными IP адресами.
Уведомления фиксируются и отображаются в отдельной вкладке интерфейса.
Поддерживаются оба протокола: ipv4 и ipv6. В программе, в принципе, ничего особенного нет. Но сделана добротно и удобно, приятный интерфейс, есть русский язык. Можно взять на заметку, если понадобится подобный функционал. Я, к примеру, так сходу и не вспомню, чем так же трафик посмотреть на Windows. Первыми на ум приходят различные application firewalls, но это немного не то. Более навороченные и функциональные программы.
В Windows предварительно надо будет установить Npcap (installer), в Linux libpcap и звуки со шрифтами:
А потом уже сам Sniffnet.
⇨ Сайт / Исходники
#network
Но есть способы проще. Например, взять open source приложение Sniffnet и посмотреть в удобном виде всю сетевую активность. Причём приложение кроссплатформенное. Я сначала не понял, как такая простая и маленькая программа на Rust может одинаково работать на всех платформах. Оказалось, она использует библиотеку pcap: libpcap в unix и npcap в windows. Для тех, кто не в курсе, поясню, что это та же библиотека, что используется в Nmap и Wireshark.
Sniffnet позволяет подключиться к конкретному сетевому интерфейсу и посмотреть его активность. Работает в том числе с VPN интерфейсами. Например, если вы заворачиваете весь трафик в VPN, то на основном интерфейсе увидите только трафик в сторону VPN сервера. А если заглянете в VPN интерфейс, там уже будет детальна информация. Можно быстро проверить, точно ли весь нужный трафик идёт в VPN.
В Sniffnet можно настроить 3 типа уведомлений:
1️⃣ Превышение порога по частоте передачи пакетов.
2️⃣ Превышение порога полосы пропускания.
3️⃣ Соединение с указанными IP адресами.
Уведомления фиксируются и отображаются в отдельной вкладке интерфейса.
Поддерживаются оба протокола: ipv4 и ipv6. В программе, в принципе, ничего особенного нет. Но сделана добротно и удобно, приятный интерфейс, есть русский язык. Можно взять на заметку, если понадобится подобный функционал. Я, к примеру, так сходу и не вспомню, чем так же трафик посмотреть на Windows. Первыми на ум приходят различные application firewalls, но это немного не то. Более навороченные и функциональные программы.
В Windows предварительно надо будет установить Npcap (installer), в Linux libpcap и звуки со шрифтами:
# apt install libpcap-dev libasound2-dev libfontconfig1-devА потом уже сам Sniffnet.
⇨ Сайт / Исходники
#network
Запомнился один момент с недавней конференции, где я присутствовал. Выступающий рассказывал, если не ошибаюсь, про технологию VDI и оптимизацию полосы пропускания, что позволяет комфортно общаться по видеосвязи. В подтверждение своих слов с цифрами показал картинку, где справа окно терминала.
Я сразу же узнал, чем они измеряли скорость. Это утилита iftop, которую я сам почти всегда ставлю на сервера под своим управлением. Привык к ней. Удобно быстро посмотреть потоки трафика на сервере с разбивкой по IP адресам и портам.
Ну и чтобы добавить пользы посту, приведу список утилит со схожей функциональностью, но не идентичной. То есть они дополняют друг друга: bmon, Iptraf, sniffer, netsniff-ng.
#network #perfomance
Я сразу же узнал, чем они измеряли скорость. Это утилита iftop, которую я сам почти всегда ставлю на сервера под своим управлением. Привык к ней. Удобно быстро посмотреть потоки трафика на сервере с разбивкой по IP адресам и портам.
Ну и чтобы добавить пользы посту, приведу список утилит со схожей функциональностью, но не идентичной. То есть они дополняют друг друга: bmon, Iptraf, sniffer, netsniff-ng.
#network #perfomance
Когда вы настраиваете VPN, встаёт вопрос выбора размера MTU (maximum transmission unit) внутри туннеля. Это размер полезного блока с данными в одном пакете. Как известно, в сетевом пакете часть информации уходит для служебной информации в заголовках. Различные технологии VPN используют разный объём служебных заголовков. А если VPN пущен поверх другого VPN канала, то этот вопрос встаёт особенно остро.
Если ошибиться с размером MTU, то пакеты начнут разбиваться на несколько, чтобы передать полезный блок с данными. Это очень сильно снижает скорость передачи данных. Минимум в 2 раза, но на деле гораздо больше.
Правильно выбрать размер MTU можно с помощью готового калькулятора - Visual packet size calculator. Его автор, кстати, Даниил Батурин, который иногда ведёт бесплатные вебинары Rebrain, которые я периодически рекламирую. Рекомендую послушать, интересно.
К сожалению, в калькуляторе нет OpenVPN. И я как-то сходу не смог найти информацию, сколько места занимают служебные заголовки этого протокола. Покажу пример для WireGuard, если я всё правильно понимаю. Если ошибаюсь, прошу поправить.
Мы устанавливаем туннель WireGuard, чтобы гонять по нему ipv4 трафик. Идём в калькулятор и выстраиваем там цепочку:
IPv4 (20 bytes) ⇨ WireGuard (40 bytes) ⇨ IPv4 (20 bytes)
Имея на родительском интерфейсе MTU 1500, внутри туннеля нам необходимо установить его 1420. Если не ошибаюсь, это как раз значение по умолчанию для WireGuard.
Тема MTU довольно сложная. Если вы не сетевой инженер и специально ей не интересовались, то вникнуть непросто. На практике я сталкивался с подобными проблемами. Решал их в меру своих сил и способностей - просто уменьшал MTU до некоторых значений, когда проблем пропадала. Если вы не разбираетесь детально в этой теме, рекомендую поступать так же. И важно знать, что если у вас PPPoE соединение от провайдера, то оно дополнительно 8 байт занимает на заголовки. Часто дефолтные значения различного софта не учитывают этого нюанса и нужно будет поправить вручную.
#vpn #network
Если ошибиться с размером MTU, то пакеты начнут разбиваться на несколько, чтобы передать полезный блок с данными. Это очень сильно снижает скорость передачи данных. Минимум в 2 раза, но на деле гораздо больше.
Правильно выбрать размер MTU можно с помощью готового калькулятора - Visual packet size calculator. Его автор, кстати, Даниил Батурин, который иногда ведёт бесплатные вебинары Rebrain, которые я периодически рекламирую. Рекомендую послушать, интересно.
К сожалению, в калькуляторе нет OpenVPN. И я как-то сходу не смог найти информацию, сколько места занимают служебные заголовки этого протокола. Покажу пример для WireGuard, если я всё правильно понимаю. Если ошибаюсь, прошу поправить.
Мы устанавливаем туннель WireGuard, чтобы гонять по нему ipv4 трафик. Идём в калькулятор и выстраиваем там цепочку:
IPv4 (20 bytes) ⇨ WireGuard (40 bytes) ⇨ IPv4 (20 bytes)
Имея на родительском интерфейсе MTU 1500, внутри туннеля нам необходимо установить его 1420. Если не ошибаюсь, это как раз значение по умолчанию для WireGuard.
Тема MTU довольно сложная. Если вы не сетевой инженер и специально ей не интересовались, то вникнуть непросто. На практике я сталкивался с подобными проблемами. Решал их в меру своих сил и способностей - просто уменьшал MTU до некоторых значений, когда проблем пропадала. Если вы не разбираетесь детально в этой теме, рекомендую поступать так же. И важно знать, что если у вас PPPoE соединение от провайдера, то оно дополнительно 8 байт занимает на заголовки. Часто дефолтные значения различного софта не учитывают этого нюанса и нужно будет поправить вручную.
#vpn #network
Часто слышал выражение, что трафик отправляют в blackhole. Обычно это делает провайдер, когда вас ддосят. Вас просто отключают, отбрасывая весь адресованный вам трафик. А что за сущность такая blackhole, я не знал. Решил узнать, заодно и вам рассказать.
Я изначально думал, что это какое-то образное выражение, которое переводится как чёрная дыра. А на деле предполагал, что соединения просто дропают где-то на файрволе, да и всё. Оказывается, blackhole это реальная запись в таблице маршрутизации. Вы на своём Linux сервере тоже можете отправить весь трафик в blackhole, просто создав соответствующий маршрут:
Проверяем:
Все пакеты с маршрутом до 1.2.3.4 будут удалены с причиной No route to host. На практике на своём сервере кого-то отправлять в blackhole большого смысла нет. Если я правильно понимаю, это провайдеры отправляют в blackhole весь трафик, адресованный какому-то хосту, которого ддосят. Таким образом они разгружают своё оборудование. И это более эффективно и просто, чем что-то делать на файрволе.
Если я правильно понимаю, подобные маршруты где-то у себя имеет смысл использовать, чтобы гарантированно отсечь какой-то исходящий трафик в случае динамических маршрутов. Например, у вас есть какой-то трафик по vpn, который должен уходить строго по определённому маршруту. Если этого маршрута не будет, то трафик не должен никуда идти. В таком случае делаете blackhole маршрут с максимальной дистанцией, а легитимные маршруты с дистанцией меньше. В итоге если легитимного маршрута не будет, весь трафик пойдёт в blackhole. Таким образом можно подстраховывать себя от ошибок в файрволе.
#network
Я изначально думал, что это какое-то образное выражение, которое переводится как чёрная дыра. А на деле предполагал, что соединения просто дропают где-то на файрволе, да и всё. Оказывается, blackhole это реальная запись в таблице маршрутизации. Вы на своём Linux сервере тоже можете отправить весь трафик в blackhole, просто создав соответствующий маршрут:
# ip route add blackhole 1.2.3.4Проверяем:
# ip r | grep blackholeblackhole 1.2.3.4Все пакеты с маршрутом до 1.2.3.4 будут удалены с причиной No route to host. На практике на своём сервере кого-то отправлять в blackhole большого смысла нет. Если я правильно понимаю, это провайдеры отправляют в blackhole весь трафик, адресованный какому-то хосту, которого ддосят. Таким образом они разгружают своё оборудование. И это более эффективно и просто, чем что-то делать на файрволе.
Если я правильно понимаю, подобные маршруты где-то у себя имеет смысл использовать, чтобы гарантированно отсечь какой-то исходящий трафик в случае динамических маршрутов. Например, у вас есть какой-то трафик по vpn, который должен уходить строго по определённому маршруту. Если этого маршрута не будет, то трафик не должен никуда идти. В таком случае делаете blackhole маршрут с максимальной дистанцией, а легитимные маршруты с дистанцией меньше. В итоге если легитимного маршрута не будет, весь трафик пойдёт в blackhole. Таким образом можно подстраховывать себя от ошибок в файрволе.
#network
