Очень простой и быстрый способ измерить ширину канала с помощью 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👍158👎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👍272👎5
За что больше всего люблю дистрибутив Debian, так это за его консерватизм. Много лет назад я написал статью на сайте:
⇨ Как настроить сетевые параметры в Debian
Последние 5 лет вообще её не трогал. А она не потеряла актуальность и популярность. Последние 2 года это самая посещаемая статья сайта. Каждый день по 200-300 посетителей приходят её прочитать. А за всё время её посмотрели сотни тысяч раз. Если прикинуть, то это большой масштаб. И таких статей много. То, что я написал, прочитали уже миллионы людей. Вроде сидишь себе, что-то пишешь. А тебя читает столько народа. В уникальное время живём. Надо это ценить.
Собрался с силами и переработал статью, актуализировал. Перенёс все настройки на
Если вы автор сайта, пишите статьи и хотите, чтобы их читали, пройдите какой-нибудь онлайн курс по SEO. Это поможет вам писать статьи так, чтобы их поисковики ставили в выдачу повыше других. Это не значит, что придётся с чем-то мухлевать или кого-то вводить в заблуждение. Вы просто поймёте, как поисковики видят ваш сайт и статьи на нём, и что надо делать, чтобы поисковые системы ставили вас в выдаче повыше.
Статью можно использовать новичкам как шпаргалку. Там есть вся база:
◽️статические и динамические настройки ip адресов
◽️dns и hostname
◽️статические маршруты
◽️vlan
◽️отключение ipv6
◽️несколько адресов на одном интерфейсе
Узнал для себя некоторые новые вещи, на которые раньше не обращал внимание. Например, 2 типа активации сетевого интерфейса в
▪️auto - интерфейс активируется при загрузке системы. Это подходящая настройка для статичного сетевого адаптера.
▪️allow-hotplug - интерфейс поднимается, когда подсистема udev обнаружит его. Это произойдёт и при загрузке системы, как в случае с auto, если сетевая карта будет подключена, и в случае подключения, отключения устройства. Например, если это usb сетевая карта или VPN туннель. Настройка больше подходит для динамических сетевых интерфейсов.
Ещё интересный момент. Если сбросить dhcp lease через консоль соответствующей командой:
То вы не только потеряете все полученные по dhcp настройки, но и статические адреса. Соответственно, вас отключает по ssh. Для меня это было сюрпризом. Такие вещи надо делать осторожно, имея доступ к консоли сервера напрямую.
#debian #network
⇨ Как настроить сетевые параметры в 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
Server Admin
Настройка сети в Debian
Подробное описание настройки сети в Debian - задать ip адрес, dhcp, dns, hostname, отключить ipv6, статические маршруты и др.
👍184👎3
Для анализа сетевого трафика в первую очередь вспоминаешь про tcpdump. В принципе, он покрывает все основные потребности. Там можно посмотреть и отфильтровать всё, что угодно. Но не сказать, что он удобен и интуитивен, поэтому существуют более специализированные программы.
Я на днях увидел упоминание утилиты ngrep. Название показалось очень знакомым, как-будто я её знаю и уже писал о ней. Поискал по каналу и сайту и ничего не нашёл. Потом вспомнил, что спутал её с sngrep, которую я постоянно использовал, когда плотно работал с VOIP серверами. Очень её рекомендую, если приходится анализировать SIP протокол. Хотя скорее всего вы про неё знаете, если с ним работаете. Это очень удобная и функциональная утилита, известная в узких кругах.
Возвращаясь к ngrep. Это старая программа, которая есть в базовых репозиториях дистрибутивов. В некоторых случаях она будет удобнее tcpdump. Сразу покажу на конкретном примере. В качестве параметра ngrep принимает regex по содержимому пакетов. То есть можно сделать вот так:
И посмотреть информацию о пакетах, где есть строка HTTP. Собственно, это будут все пакеты данного протокола. В примере выше ключ
Ngrep умеет отображать содержимое пакетов с переходом на новую строку. Это особенно удобно для анализа HTTP или SMTP протокола. Как это выглядит, можно посмотреть на картинках снизу:
Подобным образом можно тут же в консоли отфильтровать все запросы с определённым User-Agent:
Чтобы не анализировать вообще весь трафик, его можно конкретизировать примерно таким же синтаксисом, как у tcpdump:
Указали интерфейс и порт. Если слушаете трафик на шлюзе, то можно конкретизировать сервер назначения, куда идёт трафик:
Host может принимать значения не только IP адреса, но и домена. Если смотрите на веб сервере запросы к конкретному домену, то указать адрес этого домена можно в фильтре для содержимого пакетов:
Подобные выборки по содержимому актуальны для всех протоколов, где иногда приходится заглядывать в сетевой трафик для дебага. Это упомянутый HTTP, а так же SMTP, SIP. Это из того, что я сам делал.
Например, смотрим обмен с конкретным почтовым сервером, добавляя метки времени:
Можно конкретизировать, если нужно посмотреть только EHLO:
Сохраните себе информацию о ngrep. Прямо здесь и сейчас вряд ли он нужен будет, но в будущем может пригодиться.
#network #terminal
Я на днях увидел упоминание утилиты ngrep. Название показалось очень знакомым, как-будто я её знаю и уже писал о ней. Поискал по каналу и сайту и ничего не нашёл. Потом вспомнил, что спутал её с sngrep, которую я постоянно использовал, когда плотно работал с VOIP серверами. Очень её рекомендую, если приходится анализировать SIP протокол. Хотя скорее всего вы про неё знаете, если с ним работаете. Это очень удобная и функциональная утилита, известная в узких кругах.
Возвращаясь к ngrep. Это старая программа, которая есть в базовых репозиториях дистрибутивов. В некоторых случаях она будет удобнее tcpdump. Сразу покажу на конкретном примере. В качестве параметра ngrep принимает regex по содержимому пакетов. То есть можно сделать вот так:
# ngrep -q 'HTTP'И посмотреть информацию о пакетах, где есть строка HTTP. Собственно, это будут все пакеты данного протокола. В примере выше ключ
-q означает отображать только сетевые пакеты. Непонятно зачем ngrep без этого ключа рисует полоску из псевдографики в консоли, когда ожидает пакеты. Ngrep умеет отображать содержимое пакетов с переходом на новую строку. Это особенно удобно для анализа HTTP или SMTP протокола. Как это выглядит, можно посмотреть на картинках снизу:
# ngrep -q 'HTTP' -W bylineПодобным образом можно тут же в консоли отфильтровать все запросы с определённым User-Agent:
# ngrep -q 'YaBrowser' -W bylineЧтобы не анализировать вообще весь трафик, его можно конкретизировать примерно таким же синтаксисом, как у tcpdump:
# ngrep -q 'YaBrowser' -W byline -d ens18 port 80Указали интерфейс и порт. Если слушаете трафик на шлюзе, то можно конкретизировать сервер назначения, куда идёт трафик:
# ngrep -q 'YaBrowser' -W byline 'host 10.20.1.36 and port 80 or 443'Host может принимать значения не только IP адреса, но и домена. Если смотрите на веб сервере запросы к конкретному домену, то указать адрес этого домена можно в фильтре для содержимого пакетов:
# ngrep -q 'example.com' -W byline 'port 80 or 443'Подобные выборки по содержимому актуальны для всех протоколов, где иногда приходится заглядывать в сетевой трафик для дебага. Это упомянутый HTTP, а так же SMTP, SIP. Это из того, что я сам делал.
Например, смотрим обмен с конкретным почтовым сервером, добавляя метки времени:
# ngrep -q '' -t -W byline 'port smtp and host 94.142.141.246'Можно конкретизировать, если нужно посмотреть только EHLO:
# ngrep -q -i 'EHLO' -t -W byline 'port smtp and host 94.142.141.246'Сохраните себе информацию о ngrep. Прямо здесь и сейчас вряд ли он нужен будет, но в будущем может пригодиться.
#network #terminal
2👍124👎3
Ранее я уже поднимал тему выбора размера MTU (maximum transmission unit) для VPN туннелей. Чаще всего об этом не нужно беспокоиться, принимая все параметры по умолчанию, но иногда бывают ситуации, и я с ними сталкивался, когда приходится разбираться из-за заметного уменьшения быстродействия туннеля без видимых причин.
Я вспомнил об этой теме, потому что столкнулся с реальным примером. У меня не возникло каких-то проблем с быстродействием, но получилось на практике посмотреть на эти настройки. Мне нужно было подключиться к старенькому PPTP туннелю. Клиентом выступал Mikrotik.
При создании PPTP интерфейса Mikrotik предлагает выбрать MTU 1450. Я немного погуглил, но не понял, а почему именно это значение ставить? Есть рекомендации сделать либо больше, либо меньше. Не понятно.
Взял под Windows утилиту mturoute. Это лучшее решение для быстрого определения MTU. Она отправляет нефрагментированные ICMP пакеты разного размера, определяя максимальный размер, который доходит до адресата. В настройках Mikrotik для начала указал MTU 1500, запустил туннель и выполнил проверку:
В Linux можно использовать tracepath:
Обе утилиты показали максимальный размер пакета 1492. Его я и установил в настройках PPTP интерфейса. Если бы я оставил то, что предлагалось по умолчанию 1450, то проблемы бы тоже не было. Но теоретически, с 1492 скорость будет немного выше. А вот если поставить 1500, то наверняка будут проблемы, так как стандартные пакеты начнут дополнительно фрагментироваться.
Задался вопросом. А почему, собственно, рабочее MTU 1492? Ведь по идее PPTP уменьшает стандартный размер пакета как минимум на следующие заголовки: IPv4+TCP+GRE. То есть там как минимум будет уменьшение на 20+20+8 = 48 байт. MTU должно быть 1452. Дело тут скорее всего в том, PPTP для передачи данных использует отдельное соединение с помощью протокола GRE. Сначала выполняется управляющее подключение по TCP порту 1723. А потом данные передаются по отдельному GRE соединению. Если верить калькулятору, то GRE с ключом как раз забирает для своих заголовков 8 байт и MTU будет 1492.
Данный вопрос 100% актуален, если у вас используется PPPoE соединение с интернетом, а поверх него VPN туннель. Там точно нужно будет делать поправку на PPPoE. У меня есть одна точка с таким соединением. Без VPN mturoute показывает MTU 1480.
Надеюсь вам эта информация будет полезна и где-то пригодится. Писал больше для себя, чтобы разобраться. Тема с MTU сложная. Нужно хорошо понимать, как вообще устроена передача данных, из чего состоят пакеты, как передаются, фрагментируются и т.д. Я в отдельности всё это изучал, но без практики информация быстро забывается.
Написав текст, я лучше запоминаю и всегда могу к нему вернуться, если понадобится. Главное, не забыть, что об этом уже писал и разбирался 😁 Не всегда удаётся. Успокаивает то, что это не только для меня проблема. Читал недавно статью на сайте, где автор в комментариях написал, что вышел на свою статью через google. Тупо забыл, что уже сталкивался и писал об этом. У меня так тоже не раз бывало.
☝️Из этой заметки стоит сохранить на память как минимум:
◽️Visual packet size calculator, пример расчёта
◽️mturoute.exe
◽️Чем отличаются утилиты traceroute, tracert и tracepath?
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#network
Я вспомнил об этой теме, потому что столкнулся с реальным примером. У меня не возникло каких-то проблем с быстродействием, но получилось на практике посмотреть на эти настройки. Мне нужно было подключиться к старенькому PPTP туннелю. Клиентом выступал Mikrotik.
При создании PPTP интерфейса Mikrotik предлагает выбрать MTU 1450. Я немного погуглил, но не понял, а почему именно это значение ставить? Есть рекомендации сделать либо больше, либо меньше. Не понятно.
Взял под Windows утилиту mturoute. Это лучшее решение для быстрого определения MTU. Она отправляет нефрагментированные ICMP пакеты разного размера, определяя максимальный размер, который доходит до адресата. В настройках Mikrotik для начала указал MTU 1500, запустил туннель и выполнил проверку:
> mturoute 192.168.10.1* ICMP Fragmentation is not permitted. ** Speed optimization is enabled. ** Maximum payload is 10000 bytes. *- ICMP payload of 1472 bytes is too big.+ ICMP payload of 92 bytes succeeded.+ ICMP payload of 1299 bytes succeeded.- ICMP payload of 1466 bytes is too big.+ ICMP payload of 1463 bytes succeeded.+ ICMP payload of 1464 bytes succeeded.- ICMP payload of 1465 bytes is too big.Path MTU: 1492 bytes.В Linux можно использовать tracepath:
# tracepath 192.168.10.1 1?: [LOCALHOST] pmtu 1500 1: ??? 0.586ms 1: ??? 0.256ms 2: 10.8.2.1 5.685ms 3: 10.8.0.3 11.253ms 4: 10.8.0.3 14.199ms pmtu 1492 4: 192.168.10.1 17.783ms reached Resume: pmtu 1492 hops 4 back 4Обе утилиты показали максимальный размер пакета 1492. Его я и установил в настройках PPTP интерфейса. Если бы я оставил то, что предлагалось по умолчанию 1450, то проблемы бы тоже не было. Но теоретически, с 1492 скорость будет немного выше. А вот если поставить 1500, то наверняка будут проблемы, так как стандартные пакеты начнут дополнительно фрагментироваться.
Задался вопросом. А почему, собственно, рабочее MTU 1492? Ведь по идее PPTP уменьшает стандартный размер пакета как минимум на следующие заголовки: IPv4+TCP+GRE. То есть там как минимум будет уменьшение на 20+20+8 = 48 байт. MTU должно быть 1452. Дело тут скорее всего в том, PPTP для передачи данных использует отдельное соединение с помощью протокола GRE. Сначала выполняется управляющее подключение по TCP порту 1723. А потом данные передаются по отдельному GRE соединению. Если верить калькулятору, то GRE с ключом как раз забирает для своих заголовков 8 байт и MTU будет 1492.
Данный вопрос 100% актуален, если у вас используется PPPoE соединение с интернетом, а поверх него VPN туннель. Там точно нужно будет делать поправку на PPPoE. У меня есть одна точка с таким соединением. Без VPN mturoute показывает MTU 1480.
Надеюсь вам эта информация будет полезна и где-то пригодится. Писал больше для себя, чтобы разобраться. Тема с MTU сложная. Нужно хорошо понимать, как вообще устроена передача данных, из чего состоят пакеты, как передаются, фрагментируются и т.д. Я в отдельности всё это изучал, но без практики информация быстро забывается.
Написав текст, я лучше запоминаю и всегда могу к нему вернуться, если понадобится. Главное, не забыть, что об этом уже писал и разбирался 😁 Не всегда удаётся. Успокаивает то, что это не только для меня проблема. Читал недавно статью на сайте, где автор в комментариях написал, что вышел на свою статью через google. Тупо забыл, что уже сталкивался и писал об этом. У меня так тоже не раз бывало.
☝️Из этой заметки стоит сохранить на память как минимум:
◽️Visual packet size calculator, пример расчёта
◽️mturoute.exe
◽️Чем отличаются утилиты traceroute, tracert и tracepath?
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#network
2👍256👎3
Расскажу об одной банальной вещи. Возможно кому-то она поможет, если в голову не приходило такое решение.
Ночь - время для обслуживания и бэкапов. Хорошо, когда ты за ночное окно успеваешь всё сделать и перекинуть данные на бэкап сервера. Но рано или поздно ночного окна начинает не хватать, особенно если бэкапы льются через интернет. Решать вопрос лучше всего комплексно, уменьшая объём передаваемых данных и двигая сервер с бэкапами ближе к источнику.
Если перечисленное выше не приводит к желаемому результату, то я настраиваю ограничение трафика. Вопрос этот непростой, если подразумевать полноценную приоритизацию на основе типов данных. Если ты не занимаешься этим вопросом постоянно, то довольно муторно вникать во все нюансы. Но конкретно в этой задаче не придётся сильно погружаться, так как я предлагаю просто ограничить в определённое время полосу пропускания на основе IP адреса сервера с бэкапами. А это самый простой случай.
В Mikrotik такое ограничение можно настроить с помощью Simple Queue. В шлюзах на базе Linux с помощью tc из пакета iproute2. В других шлюзах и роутерах этот как-то по-другому может решаться.
Для нормальной настройки шейпирования, чтобы не мешать привычной дневной работе, нужно обязательно иметь мониторинг полосы пропускания. Тот же Zabbix или Prometheus без особых проблем решают в типовых ситуациях эти вопросы. Надо знать среднюю загрузку канала и разрешить бэкапам литься с такой скоростью, чтобы днём не было полной утилизации полосы пропускания.
Я обычно делаю отдельные дашборды в мониторинге с загрузкой канала, чтобы во-первых, быстро оценить среднюю дневную загрузку, во-вторых, чтобы потом удобно контролировать загрузку, если бэкапы в ночь не успевают скопироваться.
Делается всё это обычно для того, чтобы если до утра задержится копирование, не парализовать работу. Если бэкапы уже сильно не успевают заливаться и уходят в день, то надо что-то менять. Потому что даже с таким ограничением они мешают полноценной работе. У тебя полезная ёмкость канала уменьшается.
#network #backup
Ночь - время для обслуживания и бэкапов. Хорошо, когда ты за ночное окно успеваешь всё сделать и перекинуть данные на бэкап сервера. Но рано или поздно ночного окна начинает не хватать, особенно если бэкапы льются через интернет. Решать вопрос лучше всего комплексно, уменьшая объём передаваемых данных и двигая сервер с бэкапами ближе к источнику.
Если перечисленное выше не приводит к желаемому результату, то я настраиваю ограничение трафика. Вопрос этот непростой, если подразумевать полноценную приоритизацию на основе типов данных. Если ты не занимаешься этим вопросом постоянно, то довольно муторно вникать во все нюансы. Но конкретно в этой задаче не придётся сильно погружаться, так как я предлагаю просто ограничить в определённое время полосу пропускания на основе IP адреса сервера с бэкапами. А это самый простой случай.
В Mikrotik такое ограничение можно настроить с помощью Simple Queue. В шлюзах на базе Linux с помощью tc из пакета iproute2. В других шлюзах и роутерах этот как-то по-другому может решаться.
Для нормальной настройки шейпирования, чтобы не мешать привычной дневной работе, нужно обязательно иметь мониторинг полосы пропускания. Тот же Zabbix или Prometheus без особых проблем решают в типовых ситуациях эти вопросы. Надо знать среднюю загрузку канала и разрешить бэкапам литься с такой скоростью, чтобы днём не было полной утилизации полосы пропускания.
Я обычно делаю отдельные дашборды в мониторинге с загрузкой канала, чтобы во-первых, быстро оценить среднюю дневную загрузку, во-вторых, чтобы потом удобно контролировать загрузку, если бэкапы в ночь не успевают скопироваться.
Делается всё это обычно для того, чтобы если до утра задержится копирование, не парализовать работу. Если бэкапы уже сильно не успевают заливаться и уходят в день, то надо что-то менять. Потому что даже с таким ограничением они мешают полноценной работе. У тебя полезная ёмкость канала уменьшается.
#network #backup
1👍105👎3
Уже не первый раз сталкиваюсь с ситуацией, что получаешь арендную VPS, а там по умолчанию уже настроены сетевые интерфейсы и ipv4, и ipv6. Делаешь обновление системы через apt, он подключается по ipv6 и ничего не качает, пишет, что no longer has a Release file. Столкнулся вчера лично с репозиторием от Яндекса:
В рунете он популярен. Я и сам всегда его использую. Не знаю, кто тут виноват, сам провайдер или Яндекс (позже выяснилось, что Яндекс, подробности в конце). Не вижу смысла разбираться и тратить время. В данном случае проще отключить ipv6. Это можно сделать разными способами. Можно конкретно apt заставить работать через ipv4. У него есть параметр для этого:
Постоянно так писать не будешь, можно добавить в конфигурацию, создав файл
Я лично поступил проще. Отключил ipv6 на уровне системы. Добавил в
И применил их:
Настройки ipv6 на сетевом интерфейсе сразу пропали, apt успешно заработал по ipv4.
Более радикальный способ отключения через GRUB, но тогда придётся обновлять загрузчик, пересобирать initramfs. Плюс, понадобится перезагрузка. Для этого в его конфиг
После этого нужно обновить загрузчик. В зависимости от системы выглядеть это может по-разному. В Debian можно так:
Заметил ещё такую особенность. До того, как отключил ipv6, заметил, что apt работает то по ipv4, то по ipv6. Можно было несколько раз его запустить и получить желаемый результат. Не знаю, с чем это может быть связано. Возможно первый резолв доменного имени идёт на DNS запись AAAA, а если подключение неудачно, то потом на A. Но не уверен, что это так. Просто догадки.
Уже после написания заметки решил повнимательнее разобраться, что реально происходит в apt при обращении по ipv6 и ipv4. Для этого сделал два отдельных запроса по разным протоколам:
Первый нормально отрабатывает и загружает файл InRelease. А во втором случае репозиторий Яндекса отвечает:
То есть DNS запись для mirror.yandex.ru есть:
Но Nginx, который раздаёт контент, не настроен для работы по ipv6. Не знаю, зачем так сделали. Если не настроили Nginx, зачем настроили ipv6? 🤷♂️ Может какие-то временные проблемы.
☝️В целом, с ipv6 такое бывает, поэтому если не используете, лучше сразу отключить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network #ipv6
http://mirror.yandex.ru/debian bookworm mainВ рунете он популярен. Я и сам всегда его использую. Не знаю, кто тут виноват, сам провайдер или Яндекс (позже выяснилось, что Яндекс, подробности в конце). Не вижу смысла разбираться и тратить время. В данном случае проще отключить ipv6. Это можно сделать разными способами. Можно конкретно apt заставить работать через ipv4. У него есть параметр для этого:
# apt -o Acquire::ForceIPv4=true upgradeПостоянно так писать не будешь, можно добавить в конфигурацию, создав файл
/etc/apt/apt.conf.d/disable-ipv6 следующего содержания:Acquire::ForceIPv4 "true";Я лично поступил проще. Отключил ipv6 на уровне системы. Добавил в
/etc/sysctl.conf пару параметров:net.ipv6.conf.all.disable_ipv6 = 1net.ipv6.conf.default.disable_ipv6 = 1И применил их:
# sysctl -pНастройки ipv6 на сетевом интерфейсе сразу пропали, apt успешно заработал по ipv4.
Более радикальный способ отключения через GRUB, но тогда придётся обновлять загрузчик, пересобирать initramfs. Плюс, понадобится перезагрузка. Для этого в его конфиг
/etc/default/grub, конкретно в параметр GRUB_CMDLINE_LINUX, нужно добавить значение ipv6.disable=1. Если там уже указаны другие значения, то перечислены они должны быть через пробел. Примерно так:GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet ipv6.disable=1"После этого нужно обновить загрузчик. В зависимости от системы выглядеть это может по-разному. В Debian можно так:
# dpkg-reconfigure grub-pcЗаметил ещё такую особенность. До того, как отключил ipv6, заметил, что apt работает то по ipv4, то по ipv6. Можно было несколько раз его запустить и получить желаемый результат. Не знаю, с чем это может быть связано. Возможно первый резолв доменного имени идёт на DNS запись AAAA, а если подключение неудачно, то потом на A. Но не уверен, что это так. Просто догадки.
Уже после написания заметки решил повнимательнее разобраться, что реально происходит в apt при обращении по ipv6 и ipv4. Для этого сделал два отдельных запроса по разным протоколам:
# apt -o Debug::Acquire::http=true -o Acquire::ForceIPv4=true update# apt -o Debug::Acquire::http=true -o Acquire::ForceIPv6=true updateПервый нормально отрабатывает и загружает файл InRelease. А во втором случае репозиторий Яндекса отвечает:
Answer for: http://mirror.yandex.ru/debian/dists/bookworm/InReleaseHTTP/1.1 404 Not FoundServer: nginx/1.24.0 (Ubuntu)............................................................Err:2 http://mirror.yandex.ru/debian bookworm Release 404 Not Found [IP: 2a02:6b8::183 80]То есть DNS запись для mirror.yandex.ru есть:
# dig +short mirror.yandex.ru AAAA2a02:6b8::183Но Nginx, который раздаёт контент, не настроен для работы по ipv6. Не знаю, зачем так сделали. Если не настроили Nginx, зачем настроили ipv6? 🤷♂️ Может какие-то временные проблемы.
☝️В целом, с ipv6 такое бывает, поэтому если не используете, лучше сразу отключить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network #ipv6
3👍191👎8
Столкнулся на днях с необычной ситуацией. Zabbix прислал уведомление, что внешний канал на одном из Mikrotik забит. Зашёл на него, смотрю локальный трафик, его особо нет, а на WAN интерфейсе всё забито. Я сначала по привычке бридж локальный открыл, чтобы посмотреть через Torch, кто источник повышенного трафика. Там ничего подозрительного не увидел.
Дальше открыл Torch в WAN и вижу там кучу входящего трафика, но что самое интересное, не на мой внешний IP адрес. У меня настроен .242.39, а трафик идёт на другие адреса из выделенной провайдером подсети. Судя по всему это уже давно так продолжается, но канал весь забили только в этот раз. Потом трафик ушёл и всё нормализовалось. Но левые пакеты всё равно светятся на внешнем интерфейсе, хоть и в небольшом количестве.
Первый раз с такой ситуацией сталкиваюсь. Даже не знаю, что делать. Этот трафик адресован не мне, по идее роутер его на входе сразу отбрасывает. Я его ни в списке соединений не вижу, ни файрволом не могу заблокировать. Он и так не обрабатывается. Но при этом в графике загрузки интерфейса я его вижу. То есть он реально забивает канал, или нет?
Я так понимаю, надо писать провайдеру. Его косяк, что он трафик разных абонентов перемешивает, чего при нормальных настройках быть не должно. Это какой-то местечковый провайдер-монополист в одном из бизнес центров. Кто-то сталкивался с подобной ситуацией? Если провайдер ничего не сделает, мне со своей стороны нужно что-то делать? Насколько я понимаю, сам я тут ничего не сделаю, так как входящим трафиком не могу управлять, только отбрасывать его.
#mikrotik #network
Дальше открыл Torch в WAN и вижу там кучу входящего трафика, но что самое интересное, не на мой внешний IP адрес. У меня настроен .242.39, а трафик идёт на другие адреса из выделенной провайдером подсети. Судя по всему это уже давно так продолжается, но канал весь забили только в этот раз. Потом трафик ушёл и всё нормализовалось. Но левые пакеты всё равно светятся на внешнем интерфейсе, хоть и в небольшом количестве.
Первый раз с такой ситуацией сталкиваюсь. Даже не знаю, что делать. Этот трафик адресован не мне, по идее роутер его на входе сразу отбрасывает. Я его ни в списке соединений не вижу, ни файрволом не могу заблокировать. Он и так не обрабатывается. Но при этом в графике загрузки интерфейса я его вижу. То есть он реально забивает канал, или нет?
Я так понимаю, надо писать провайдеру. Его косяк, что он трафик разных абонентов перемешивает, чего при нормальных настройках быть не должно. Это какой-то местечковый провайдер-монополист в одном из бизнес центров. Кто-то сталкивался с подобной ситуацией? Если провайдер ничего не сделает, мне со своей стороны нужно что-то делать? Насколько я понимаю, сам я тут ничего не сделаю, так как входящим трафиком не могу управлять, только отбрасывать его.
#mikrotik #network
👍67👎3
Заметил в 7-й версии RouterOS на Микротике в настройках DHCP сервера новую кнопку Send Reconfigure. Она находится в списке выданных аренд (Leases). Специально заглянул в старое устройство. Её там не было. Стало интересно, что это такое.
Как оказалось, DHCP сервер может инициировать обновление сетевых настроек. Для этого есть специальное DHCP-сообщение типа FORCERENEW. Вообще не знал и никогда не слышал, что это возможно. И не видел, чтобы кто-то так делал. Я всегда обновлял настройки со стороны клиента. Думал, только он может решать, когда ему это делать. Соответственно, если ты поменял настройки на сервере, то либо ждешь, когда закончится аренда, либо клиентом инициируешь обновление.
На эту тему есть RFC 3203 (DHCP reconfigure extension) аж от 2001 года. То есть это не что-то новое и уникальное. Просто в RouterOS добавили поддержку этой функциональности. Дай, думаю, попробую, как это работает. Выглядит удобно. Поменял IP адрес в аренде и отправил команду на обновление настроек. Но ничего не вышло.
Тут не всё так просто. Для того, чтобы кто попало не рассылал по сети сообщения на обновление настроек, в этот механизм добавлена защита, описанная в RFC 6704 (Forcerenew Nonce Authentication). При получении аренды от сервера, клиент сообщает, что он поддерживает механизм аутентификации. В ответ сервер отправляет ему ключ аутентификации.
В Mikrotik этот ключ можно посмотреть в статусе аренды, на вкладке Active, в поле Reconfigure Key. Если ключа там нет, значит обмена ключами не было, клиент не примет запрос FORCERENEW на смену настроек. Сервер, соответственно, когда отправляет запрос, в заголовок добавляет ключ для аутентификации.
Будет или нет работать команда FORCERENEW зависит опять от клиента. В клиенте того же Mikrotik сделали удобно. Там просто добавили опцию в свойства клиента - Allow Reconfigure Messages. Ставишь галочку и клиент обменивается с сервером ключами.
С другими клиентами сложнее. Стандартный
Стандартный DHCP клиент в Windows тоже не имеет такой поддержки.
В итоге фичу в RouterOS завезли, причём весьма удобную, а на практике применить её негде. Только если в качестве DHCP клиентов у вас выступают те же устройства RouterOS. На практике это не особо и нужно, хотя и может где-то пригодиться.
Вы вообще знали о такой возможности? Не понимаю, почему её не реализовали в популярных клиентах. Удобно же.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mikrotik #network #dhcp
Как оказалось, DHCP сервер может инициировать обновление сетевых настроек. Для этого есть специальное DHCP-сообщение типа FORCERENEW. Вообще не знал и никогда не слышал, что это возможно. И не видел, чтобы кто-то так делал. Я всегда обновлял настройки со стороны клиента. Думал, только он может решать, когда ему это делать. Соответственно, если ты поменял настройки на сервере, то либо ждешь, когда закончится аренда, либо клиентом инициируешь обновление.
На эту тему есть RFC 3203 (DHCP reconfigure extension) аж от 2001 года. То есть это не что-то новое и уникальное. Просто в RouterOS добавили поддержку этой функциональности. Дай, думаю, попробую, как это работает. Выглядит удобно. Поменял IP адрес в аренде и отправил команду на обновление настроек. Но ничего не вышло.
Тут не всё так просто. Для того, чтобы кто попало не рассылал по сети сообщения на обновление настроек, в этот механизм добавлена защита, описанная в RFC 6704 (Forcerenew Nonce Authentication). При получении аренды от сервера, клиент сообщает, что он поддерживает механизм аутентификации. В ответ сервер отправляет ему ключ аутентификации.
В Mikrotik этот ключ можно посмотреть в статусе аренды, на вкладке Active, в поле Reconfigure Key. Если ключа там нет, значит обмена ключами не было, клиент не примет запрос FORCERENEW на смену настроек. Сервер, соответственно, когда отправляет запрос, в заголовок добавляет ключ для аутентификации.
Будет или нет работать команда FORCERENEW зависит опять от клиента. В клиенте того же Mikrotik сделали удобно. Там просто добавили опцию в свойства клиента - Allow Reconfigure Messages. Ставишь галочку и клиент обменивается с сервером ключами.
С другими клиентами сложнее. Стандартный
dhclient в Linux по умолчанию не поддерживает реализацию RFC 3203 и RFC 6704. Нужно брать какой-то другой. Например, цисковский поддерживает, но я не знаю, можно ли его запустить в Linux. Не изучал этот вопрос.Стандартный DHCP клиент в Windows тоже не имеет такой поддержки.
В итоге фичу в RouterOS завезли, причём весьма удобную, а на практике применить её негде. Только если в качестве DHCP клиентов у вас выступают те же устройства RouterOS. На практике это не особо и нужно, хотя и может где-то пригодиться.
Вы вообще знали о такой возможности? Не понимаю, почему её не реализовали в популярных клиентах. Удобно же.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mikrotik #network #dhcp
👍155👎3
Сейчас появилось очень много программ для построения mesh-сетей. Это локальные сети поверх других сетей, где хосты могут соединяться друг с другом напрямую, если есть возможность. А каждый из членов сети может выступать маршрутизатором для доступа к другим ресурсами.
Известными представителями подобных продуктов являются Nebula, Tailscale, Netmaker, Netbird и ZeroTier. На последнем я бы хотел остановиться поподробнее. Он выделяется из этого списка своим протоколом передачи данных, в то время как остальные в основном используют WireGuard. Плюс, Mikrotik в RouterOS7 имеет реализацию, как клиента, так и своего контроллера на базе ZeroTier.
Я раньше только слышал про него, сам не пробовал. Решил исправить это, развернул и протестировал. Сразу скажу, что это не инструмент для обхода блокировок. Он не для этого придуман и в данной роли работает плохо. Не стоит эту тему развивать.
ZeroTier - платный SaaS сервис. Регистрируетесь, платите деньги и получаете личный кабинет для управления всеми своими сетями. Но при этом серверная часть выложена в open source. Каждый может развернуть свой локальный сервер и управлять им через CLI. Я немного изучил команды, там на самом деле всё относительно просто.
В связи с этим появилось очень много реализаций бесплатного веб интерфейса для управления сервером. Я недавно читал статью про настройку Self-Hosted ZeroTier с помощью интерфейса ZTNET, поэтому не стал смотреть другие интерфейсы, а их много, взял сразу этот. В целом, там всё необходимое для управления есть.
Запускаем так:
Можно и вручную всё это сделать. В репозитории есть описание. Теперь можно идти на 3000 порт сервера и регистрировать учётку админа.
Принцип объединения устройств в единую сеть следующий:
1️⃣ Скачиваете клиента под свою систему (есть под все, в том числе мобильные)
2️⃣ В клиенте указываете Network ID или сканируете QR код, который видно в веб интерфейсе. В этом ID, как я понял, закодирован IP контроллера.
3️⃣ Клиент подключается к серверу, на сервере вы подтверждаете его подключение.
4️⃣ Клиент получает IP адрес внутренней сети.
Я объединил Windows, Linux и Mikrotik. Получилось всё без проблем. Узлы сети сразу же напрямую увидели себя по внутренним адресам сети ZeroTier. Заработали RDP, SSH, Winbox.
Вы можете назначить Mikrotik шлюзом для какой-то подсети, которая находится за ним. Клиенты, которые подключатся к общей mesh-сети, могут ходить в ту сеть через него. А какой-нибудь Linux сервер назначить шлюзом для доступа в другую инфраструктуру. То есть каждый узел может выступать в роли и клиента, и шлюза для других. Настраивается это очень просто, буквально в несколько кликов в веб интерфейсе.
Если клиенты не видят друг друга напрямую, то общаются через контроллер. По умолчанию локальный ZeroTier подключается к набору публичных серверов для связи клиентов, которые не могут через ваш сервер увидеть друг-друга. Например, если сервер не в публичном доступе для всех.
В ZTNET это отключается в разделе настроек ZT Controller, где вы можете создать так называемый Custom Planet, который будет работать только локально и никуда подключаться не будет. Вам нужно будет обеспечить к нему прямой доступ всех клиентов, либо опубликовав контроллер напрямую в интернете, либо пробросив к нему порт 9993/udp.
Я всё это настроил. Разобрался со всем за пару-тройку часов. Не могу подробно расписать установку клиентов и команды, потому что лимит на длину заметки. В сети всё это есть, там ничего сложного.
Продукт простой, функциональный, бесплатный и известный. Много кем поддерживается. Так что если нужно что-то подобное, то можете смело использовать. Единственное, я бы поискал какой-то другой GUI. Этот показался немного кривоват, хотя вся необходимая функциональность присутствует.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#vpn #network
Известными представителями подобных продуктов являются Nebula, Tailscale, Netmaker, Netbird и ZeroTier. На последнем я бы хотел остановиться поподробнее. Он выделяется из этого списка своим протоколом передачи данных, в то время как остальные в основном используют WireGuard. Плюс, Mikrotik в RouterOS7 имеет реализацию, как клиента, так и своего контроллера на базе ZeroTier.
Я раньше только слышал про него, сам не пробовал. Решил исправить это, развернул и протестировал. Сразу скажу, что это не инструмент для обхода блокировок. Он не для этого придуман и в данной роли работает плохо. Не стоит эту тему развивать.
ZeroTier - платный SaaS сервис. Регистрируетесь, платите деньги и получаете личный кабинет для управления всеми своими сетями. Но при этом серверная часть выложена в open source. Каждый может развернуть свой локальный сервер и управлять им через CLI. Я немного изучил команды, там на самом деле всё относительно просто.
В связи с этим появилось очень много реализаций бесплатного веб интерфейса для управления сервером. Я недавно читал статью про настройку Self-Hosted ZeroTier с помощью интерфейса ZTNET, поэтому не стал смотреть другие интерфейсы, а их много, взял сразу этот. В целом, там всё необходимое для управления есть.
Запускаем так:
# wget -O docker-compose.yml https://raw.githubusercontent.com/sinamics/ztnet/main/docker-compose.yml
# sed -i "s|http://localhost:3000|http://$(hostname -I | cut -d' ' -f1):3000|" docker-compose.yml
# docker compose up -d
Можно и вручную всё это сделать. В репозитории есть описание. Теперь можно идти на 3000 порт сервера и регистрировать учётку админа.
Принцип объединения устройств в единую сеть следующий:
Я объединил Windows, Linux и Mikrotik. Получилось всё без проблем. Узлы сети сразу же напрямую увидели себя по внутренним адресам сети ZeroTier. Заработали RDP, SSH, Winbox.
Вы можете назначить Mikrotik шлюзом для какой-то подсети, которая находится за ним. Клиенты, которые подключатся к общей mesh-сети, могут ходить в ту сеть через него. А какой-нибудь Linux сервер назначить шлюзом для доступа в другую инфраструктуру. То есть каждый узел может выступать в роли и клиента, и шлюза для других. Настраивается это очень просто, буквально в несколько кликов в веб интерфейсе.
Если клиенты не видят друг друга напрямую, то общаются через контроллер. По умолчанию локальный ZeroTier подключается к набору публичных серверов для связи клиентов, которые не могут через ваш сервер увидеть друг-друга. Например, если сервер не в публичном доступе для всех.
В ZTNET это отключается в разделе настроек ZT Controller, где вы можете создать так называемый Custom Planet, который будет работать только локально и никуда подключаться не будет. Вам нужно будет обеспечить к нему прямой доступ всех клиентов, либо опубликовав контроллер напрямую в интернете, либо пробросив к нему порт 9993/udp.
Я всё это настроил. Разобрался со всем за пару-тройку часов. Не могу подробно расписать установку клиентов и команды, потому что лимит на длину заметки. В сети всё это есть, там ничего сложного.
Продукт простой, функциональный, бесплатный и известный. Много кем поддерживается. Так что если нужно что-то подобное, то можете смело использовать. Единственное, я бы поискал какой-то другой GUI. Этот показался немного кривоват, хотя вся необходимая функциональность присутствует.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#vpn #network
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍129👎3