[fun105]

Есть одно устройство (одноплатник с armbian), у него есть доступ в интернет через сотовый модем. На нем запущен vpn для удаленного доступа к нему через vpn-сервер.

Есть компьютер, на котором настроено подключение к этому же vpn серверу и с которого подключаются к этому устройству через vpn.

С компьютера подключаются к устройству через ssh. С этого же устройства на сервер передаются данные по отдельному подключению (data1).

Проблема в том, что иногда, когда устройство передает много данных, подключение по ssh начинает тормозить и устройство перестает реагировать на команды.

Что можно предпринять чтобы ssh работал при любых условиях стабильно?

Если не будет хватать интернет канала, то можно дропнуть часть данных которые передает устройство.

Поскольку у устройства подключение через модем, то нет точного значения для доступной ширины канала, зависит от уровня сигнала.

Примерно это можно было бы описать так - если есть данные по ssh - передавай их, есть есть возможность передать что-то еще - передавай data1.

Пока идет поиск в интернерте, есть пара идей (могут быть неточности в формулировках т.к. раньше с такими вещами не работали).

1. Т.к. источником data1 являетс устройство, то манипуляции с трафиком нужно производить на нем.

2. Настроить классы траффика через iproute2 + tc htb и там задать отдельный класс для подключения по ssh c заданной гарантированной скоростью. Но тут есть несколько непонятных моментов.

Будет ли это работать если подключение по ssh идет на устройство (для устройства - входящий трафик), данные data1, которые передает устройство на сервер получается исходящий трафик. Если я правильно понял, то tc может регулировать только исходящий трафик. Если нам нужно гарантировать полосу для ssh, за счет урезания трафика data1, это будет работать? Получится ли такое настроить через tc?

3. Поможет ли тут использование таких вещей как IFB/IMQ? Как я понял с их помощью, условно, можно задавать глобальные ограничения для общего потока трафика.

4. Использовать QoS. Как я понял, если настроить для подключения по ssh высший приоритет, это может решить проблему. Но не понял как это лучше сделать, тоже через tc?

[naves]

14 hours ago, fun105 said:

Если я правильно понял, то tc может регулировать только исходящий трафик

не совсем так.

когда-то по этой инструкции делал

https://unix.stackexchange.com/questions/545033/limit-bandwidth-on-a-specific-port-in-centos-7

[Saab95]

В 09.05.2025 в 20:12, fun105 сказал:

Проблема в том, что иногда, когда устройство передает много данных, подключение по ssh начинает тормозить и устройство перестает реагировать на команды.

Тут можно попробовать включить сжатие на VPN, ведь ssh это текстовые данные и они хорошо сжимаются, если выходные данные тоже в текстовом виде - то и они сжимаются.

 

В 09.05.2025 в 20:12, fun105 сказал:

Будет ли это работать если подключение по ssh идет на устройство (для устройства - входящий трафик), данные data1, которые передает устройство на сервер получается исходящий трафик. Если я правильно понял, то tc может регулировать только исходящий трафик. Если нам нужно гарантировать полосу для ssh, за счет урезания трафика data1, это будет работать? Получится ли такое настроить через tc?

Можно управлять только исходящим трафиком, входящим должно управлять некое другое устройство на дальней стороне VPN канала.

[straus]

А меня озадачила сама формулировка названия темы. Ведь нынче интернет-каналы  практически всегда дуплексные. То есть, сама постановка "распределение канала между входящим и исходящим трафиком" - некорректна. Можно говорить о входящих и исходящих соединениях, но они не равны трафику.

И возможно, что томозит само устройство (ресурсов процессора не хвататет). А полисинг на процессоре только ухудшит ситуацию.

 

А вообще для решения пробдемы недостаточно информации. Сначала нужно определить, где "бутылочное горло", а уже потом выбирать методы решения.

[fun105]

Да, с формулировкой могут быть проблемы, т.к. не большой специалист в этой области.

Попробую описать еще раз.

Есть устройство, подключенное к vpn серверу.

Есть пользователь, тоже подключенный к этому vpn-серверу.

Пользователь подключается к устройству по ssh через vpn.

На компьютере у пользователя запускается софт, который принимает данные от устройства.

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

Если отключить передачу данных с устройства, то ssh начинает работать стабильно.

 

Какая у меня была идея. Есть интернет канал у устройства. Через него к нему подключаются по ssh и по нему же оно передает данные data1. Как бы сделать так, чтобы часть этого канала была всегда зарезервирована для ssh, пусть и за счет передачи данных data1.  Например, из общего канала выделить примерно 100 kbit/s для ssh, а все остальное чтобы использовалось для передачи data1. Если канала не хватает для передачи и ssh и data1, то тогда ssh передавать в первую очередь, а data1 - как получится.

Только в этом случае данные ssh получается это будет входящий трафик на устройство, а data1 - исходящий.

 

Инструкции, которые я находил, предлагают использовать tc для контроля полосы. Но, как я понял, через tc можно регулировать только исходящий трафик. Т.е. в моем случае я, как я предполагаю, могу ограничить канал data1 до какого-то искуственного значения, 500 kbit/s, например. Но если канал в интернет будет более скоростной (чем 500 kbit/s), то получится что я искуственно ограничиваю скорость передачи, чего не хотелось бы.

 

Идея tc + htb с классами траффика подошла бы, как я думаю, если бы можно было бы регулировать весь трафик, и входящий и исходящий. А в явном виде через tc можно ограничить только исходящий.

Поэтому подумал, что может быть это получится сделать через IFB/IMQ (какие-то псевдо интерфейсы, на разобрался с ними еще).

Или может тут будет достаточно где-то (tc + prio?) указать, что у траффика ssh наивысший приоритет и он будет обрабатыватьтся в первую очередь.

 

Quote

 Тут можно попробовать включить сжатие на VPN, ведь ssh это текстовые данные и они хорошо сжимаются, если выходные данные тоже в текстовом виде - то и они сжимаются.

VPN  сейчас используется Wireguard (не обязательно его использовать), не видел у него в настройках ничего про сжатие.

SSH вроде же по умолчанию работает со сжатием и шифрованием, не думаю что там текстовые данные передаются в явном виде.

Edited May 11 by fun105

[fun105]

Quote

Можно говорить о входящих и исходящих соединениях, но они не равны трафику.

И возможно, что томозит само устройство (ресурсов процессора не хвататет). А полисинг на процессоре только ухудшит ситуацию.

Когда проверяем работу устройства в офисе с быстрым проводным интернетом (тоже через vpn), все работает нормально, процессор на устройстве не загружен. Проблемы похоже начинаются когда устройство выходит в интернет через мобильный интерне с не широким каналом.

[fun105]

Quote

 не совсем так.

когда-то по этой инструкции делал

https://unix.stackexchange.com/questions/545033/limit-bandwidth-on-a-specific-port-in-centos-7

Если я правильно понял, там используют IFB чтобы шейпить входящий трафик.

Но там получается есть разные настройки для разных интрефейсов, отдельно для входящего и исходящего траффика.

 

А вот если бы можно было бы построить такое "дерево классов" для htb, которое работает сразу с входящим и исходящим трафиком. И там задать что для ssh мы используем 100kbit/s и их не занимать, а остальную полосу для всего остального.

Но похоже так пока не получится, по крайней мере так я понял мехнизм работы tc.

[fun105]

Если, например, задать для исходящего и входящего трафика дисциплину prio

tc qdisc add dev eth0 root handle 1:0 prio
tc qdisc add dev eth0 ingress handle 1:0 prio

и потом через фильтры задать что трафик для ssh относится к первому классу (у которого самый высокий приоритет)

tc filter add dev eth0 parent 1:0 protocol ip prio 1 \
u32 match ip dport 22 0xffff flowid 1:1

подсмотрел здесь.

Так получится настроить? Или через tc так не будет работать?

[Saab95]

В таком случае нужно ВПН сервер сделать, например, на микротике. Перед устройством установить тоже роутер микротик, который можно подключать как к проводной сети, так и к беспроводной по Wi-Fi, и через сотовую сеть.

 

Туннель они поднимут между собой. На каждом микротике промаркируете трафик по портам и установите приоритеты. Но работать все будет только на исходящем трафике. Микротик у устройства обработает исходящий канал в сторону центра. А микротик в центре исходящий канал в сторону устройства.

 

 

[straus]

В 11.05.2025 в 20:04, fun105 сказал:

Когда проверяем работу устройства в офисе с быстрым проводным интернетом (тоже через vpn), все работает нормально, процессор на устройстве не загружен. Проблемы похоже начинаются когда устройство выходит в интернет через мобильный интерне с не широким каналом.

Понятно. Почему это не было указано в первом посте?

 

Далее необходимо знать, в каких пределах изменяется скорость мобильного канала, какие задержки, и сколько в пике скорость исходящих данных от устройства, а также реальный график исходящего потока (распределение полосы во времени).

[naves]

16 hours ago, fun105 said:

А вот если бы можно было бы построить такое "дерево классов" для htb, которое работает сразу с входящим и исходящим трафиком. И там задать что для ssh мы используем 100kbit/s и их не занимать, а остальную полосу для всего остального.

Вы не с той стороны заходите.

VPN-сервер вливает трафик на устройство через трубу условного сотового оператора. Если труба забита, устройство ничего не сможет сделать.

Следовательно приоритеты трафика нужно делать на VPN-сервере, и по ssh ходить через VPN-тоннель, в котором трафик управления будет иметь приоритет над остальным трафиком.

 

Перечитал еще раз, вы хотите расставить приоритеты исходящему трафику с устройства, а вопрос, про ограничение входящего трафика. И непонятно, чего и зачем тогда все...

 

И отдельно тогда стоит вопрос симметричности вашего канала, нормально ли работает входящий канал, если забит исходящий.

Edited May 12 by naves

[Goog]

>>> Что можно предпринять чтобы ssh работал при любых условиях стабильно?

 

mosh (mobile shell) который поверх udp не вариант?

[alibek]

А обычный screen или tmux не удобнее будет?

[TheUser]

В 12.05.2025 в 17:23, alibek сказал:

обычный screen

https://www.opennet.ru/opennews/art.shtml?num=63226

Не забудьте обновить screen.