Удаленное управление шеком - вопросы, ответы, практика

[R4FCN]

К сожалению, так и не понял из Вашего ответа, почему L2TP. Понял, что использовали чат в телеграмме, понял, что углубились в удалённое управление, понял, что есть практики, понял про сети и стабильность, понял, что работать не будет, но не понял почему, а вот почему L2TP - так и не понял....

Можно Вас попросить дать линк на хорошую инструкцию от харьковчан?

Товарищ не смог донести главного. Для работы того же сан сдр нужен статический "белый" ip адрес. Получить его особенно у мобильных провайдеров скажем так, сложно. Вот собственно для этого и решается вопрос с туннелем, а каким образом он реализован разница около нулевая. Главное, что бы адрес самого устройства маршрутизировался в сети и был доступен для ПК с которого управляет. Но коллега умолчал один важный нюанс, какая ширина канала интернета нужна для работы по такому алгоритму с тем же сан сдр?

[RA3GN]

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

[RA3GN]

ly2qn
Некоторые провайдеры используют свою сеть впн, работать внутри ваша сеть не будет, если провайдер использует тип ван PPPoE, то работать впн будет однозначно.
Вот подобная инструкция по настройки l2tp на микротике, посмотрите, если найду ссылку на харьковских ребят, обязательно продублирую.

- - - Добавлено - - -

https://serveradmin.ru/nastrojka-vpn...er-v-mikrotik/

[RU6B]

Вот подобная инструкция по настройки l2tp на микротике
https://serveradmin.ru/nastrojka-vpn...er-v-mikrotik/

Да, именно по этой статье в свое время (несколько лет назад, 3-5) и настроил VPN на микротиках между Краснодаром и Туапсе по L2TP, связал два "шека".
Все работает, всем доволен

[YL2QN]

преимущество тут одно - защищенный канал. От сюда и недостаток - он медленнее. По логике для удаленного шека лучше использовать PPTP - он быстрее будет. Но в принципе, если L2TP устраивает - то почему бы и нет.

PPTP тоже имеет шифрование, но достаточно примитивное по современным меркам.

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

В результате был выбран VPN на PPTP.
- Oбеспечивает минимальную потерю скорости внутри VPN. При зажатии канала до 50 MBPS внутри VPN оставалось 30-40 MBPS. Современные VPN протоколы оставляли 10 MBPS а то и меньше.
- Шифрование в нашем деле задача маловажная (ну по крайней мере для меня), поэтому отключаю, чтобы не увеличивать ширину канала и не нагружать компьютеры-клиенты шифрованием-дешифрованием. У нас в шеках зачастую стоят устаревшие или несамые производительные компьютеры.
- Подключение делается стандартными средствами windows (встроенный VPN Client). Мелочь, но приятно.
- Сервер есть практически в каждом роутере (но не в каждом удобен или будет работать качественно). Не обязательно покупать дорогие микротики. Т.е. VPN Server легко поднять в нужном, оптимальном по топологии сети месте.

Для работы того же сан сдр нужен статический "белый" ip адрес. Получить его особенно у мобильных провайдеров скажем так, сложно.

В мобильных сетях получить внешний IP не возможно.

Как раз эту задачу и решает развёртывание VPN.
VPN Server поднимается на каком-нибудь хосте, где есть внешний IP с отрытыми портами. Все клиенты подключаются к нему и оказываются "внутри одной сети". По топологии сети VPN Server надо поднять на хосте, где будет обеспечена максимально качественная связь между всеми участниками сети (клиентами).

Можно, конечно, поднять VPN Server на любом хостинге в Европе, Америке, Австралии и т.д. и подключаться к нему. В теории всё будет работать, но скорости будет не хватать.

Другое решение - использование STUN/TURN, но оно не самое очивидное и разработчики радиолюбительского софта не замарачиваются с его применением. Более того, в применении VPN есть свои преимущества, если речь идёт о более или менее продвинутой конфигурации, где есть больше, чем трансивер на радио и компьютер дома.

Для нормальной работы, при грамотной упаковке аудио, хватает 2 MBPS. При 30-40 MBPS, как получилось у меня, тaскаю даже IQ дату для SDR, естественно не raw, а упакованную. Такую возможность даёт пока только один софт (точнее я знаю только один софт) - SDR Console.

Единственная проблема, которая время от времени беспокоит - это рваная манипуляция в CW через прокидку COM порта через TCP/IP. Проблема возникает из-за нехватки процессорных ресурсов в real-time на стороне радио.

используют свою сеть впн, работать внутри ваша сеть не будет

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

[RU6B]

Не обязательно покупать дорогие микротики

Да микротики не такие и дорогие. Раскрученные zyxel keenetic начинаются с цен повыше.
Использую одни из самых "начальных":
MikroTik hAP lite (RB941-2nD) - сейчас можно найти в продаже от 3000 руб
MikroTik hAP (rb951ui-2nd) - около 5000 руб (чуть больше памяти, есть 5G WiFi).
Даже эти, довольно старые уже и самые начальные модели достаточны по производительности для поддержания L2TP канала с IPsec шифрованием и шириной канала 10-20-30 Mb/s.

На MikroTik-ах технически можно сделать практически все на что хватит воображения, правда, настройки всего относительно "нестандартного" нетривиальны для обычного пользователя.
Сейчас любой MikroTik имеет возможность через относительно дружественный WEB-интерфейс настроить стандартные сценарии для "домашнего" использования, а еще лет 10-15 назад их конфигурирование в большинстве случаев сводилось к командной строке и различным скриптам.

[RM2A]

До полной миграции на WEB осталось решить проблему только с ротатором и коробочками RA6LBS

Огромная благодарность Андрею RA6LBS за то, что сегодня терпеливо выслушал и помог с решением .
Теперь коммутатор RA6LBS прекрасно работает удаленно БЕЗ рабочего стола )

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

Осталось найти теперь только WEB/IP интерфейс для поворотки G-2800 и комп из шэка можно убирать. Комп в шэке сейчас используется только для управления повороткой

[RW3XA]

Осталось найти теперь только WEB/IP интерфейс для поворотки G-2800...

А сделать самому, например, чем K3NG не подходит? Пример на фото.

[RM2A]

А сделать самому, например, чем K3NG не подходит? Пример на фото.

Можно попробовать, но ... это же не коммутатор или стэкматч\согласующее забабахать )

Если Вам не сложно - черканите короткую статейку на примере.
1. Покупаем ардуино такую-то
2. Покупаем такую-то плату и цепляем на нее ардуино
3. Прошивку берем вот эту самую от сюда (зуб на мясо даете сразу заработает и ничего править не надо)
4. Программа вот эта самая от сюда берется и т.д.

Вообщем нужен мануал для полных ламеров )

[RC3M]

Можно попробовать, но ... это же не коммутатор или стэкматч\согласующее забабахать

Для полных ламеров наверное проще купить что то готовое, но можно и самому поизобретать, вот как вариант что то такое.
https://rutube.ru/video/973bdcb965b6...09e7d7dae2ff6/

[RM5F]

Для полных ламеров наверное проще купить что то готовое, но можно и самому поизобретать, вот как вариант что то такое.
https://rutube.ru/video/973bdcb965b6...09e7d7dae2ff6/

Дмитрий здравствуйте.

Посмотрел Ваш следующий ролик , https://rutube.ru/video/5dc95ce35083...a0bd9e0472595/ , и не очень понял применяемую технологию.

Выглядит так, как будто смартсдр-ом создали несколько виртуальных портов, с параметром CAT - и раскидали их между управляющей программой усилителя и логом.
Ну и действительно это, казалось бы, простое решение которое за пару минут делается.

Но в описание Вы пишите о FlexAPI ( а это же по сути TCP/IP https://github.com/flexradio/smartsd...tSDR-TCPIP-API ). Значит у Вас есть свой клиент , который считывает необходимые данные и перенаправляет их в интерфейсы усилка и лога ( ком-порты? ). Не понятно зачем, опять виртуальные порты, если см. решение выше.

И еще Вы пишите что с SunSDR такой "фокус" не прокатывает - а почему ? Ну если Вы сделали TCP/IP для флекса, почему не сделать аналогичный WS клиент?
А если этого клиента нет, ну так же точно можно виртуализацией раскидать кенвудовский протокол по нужным устройствам.

Поясните , пожалуйста, в двух словах архитектуру этого решения - если , конечно, это не секрет

[RN3QKG]

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

[RM2A]

Для полных ламеров наверное проще купить что то готовое

Так я только за )
Готов встать в очередь за WEB или IP контроллером к повороткам YAESU серии DXA

Рынок таких контроллеров сегодня к сожалению сильно ограничен , мне известно только о двух законченных устройствах в продаже - но там цены ИМХО неадекватные и начинаются от 700 вашингтонов за устройство.

Мое мнение, что такой контроллер не должен стоить дороже 300 вашингтонов.
Эта цена в 300 складывается из стоимости нового компьютера (лэптопа) на винде за 200 вашингтонов и собственно стоимости контроллера USB к повороткам за 100 вашингтонов.

[RC3M]

Дмитрий здравствуйте.

Посмотрел Ваш следующий ролик , https://rutube.ru/video/5dc95ce35083...a0bd9e0472595/ , и не очень понял применяемую технологию.

Выглядит так, как будто смартсдр-ом создали несколько виртуальных портов, с параметром CAT - и раскидали их между управляющей программой усилителя и логом.
Ну и действительно это, казалось бы, простое решение которое за пару минут делается.

Но в описание Вы пишите о FlexAPI ( а это же по сути TCP/IP https://github.com/flexradio/smartsd...tSDR-TCPIP-API ). Значит у Вас есть свой клиент , который считывает необходимые данные и перенаправляет их в интерфейсы усилка и лога ( ком-порты? ). Не понятно зачем, опять виртуальные порты, если см. решение выше.

В ролике который вы указали была проба технологии FlexAPI, поэтому и был показан отдельный от основной системы одноплатник, по сути он управляет там только перестройкой усилителя, делалось это по просьбе одного из друзей, чтобы исправить работу его коммутации SO2R которая отказывается корректно переключаться от USB интерфейсов Флекса, а заодно туда же решил привязать перестройку его двух усилителей привязанных каждый к своему слайсу в Флексе.

Откуда вы взяли про виртуальные порты я не очень понял, в указанном ролике не было ни слова про них. Но если описать еще это, то уйти от использования виртуальных ком-портов не получится по банальной причине: работу Флекса надо разбирать, так сказать, на 2 половины, само железо, которое подключено к сети (где то, не важно в локальной сети оно работает или удаленно) к которому непосредственно подключена или нет какая то периферия, и ПО Смарт СДР, так вот если брать работу связки СмартСДР <-> Логгер, то связывать их придется внутри localhost компьютера на котором они и запущены, для этого вам и потребуются виртуальные порты, никакой Логгер не может работать непосредственно с самим железом(трансивером), и даже для работы с применением панели Маэстро на компьютере с логгером запускаются виртуальные порты в которых привязка идет от панели, а не от трансивера.

И еще Вы пишите что с SunSDR такой "фокус" не прокатывает - а почему ? Ну если Вы сделали TCP/IP для флекса, почему не сделать аналогичный WS клиент?
А если этого клиента нет, ну так же точно можно виртуализацией раскидать кенвудовский протокол по нужным устройствам.

Поясните , пожалуйста, в двух словах архитектуру этого решения - если , конечно, это не секрет

Что касаемо СанСДР, тут все просто, у ребят из Таганрога не реализовано API на самом железе как это сделано у Флекса, а протокол TCI хоть и работает на основе технологии WebSocket, но работает только внутри опять же localhost, то есть с ПО EESDR. Попытки как то коммуницировать непосредственно с железом были, клиент вроде подключается и не отбрасывается трансивером, но трансивер ни на какие команды не реагирует, по крайней мере у меня не получилось что то сделать.

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

- - - Добавлено - - -

Так я только за )
Готов встать в очередь за WEB или IP контроллером к повороткам YAESU серии DXA

Рынок таких контроллеров сегодня к сожалению сильно ограничен , мне известно только о двух законченных устройствах в продаже - но там цены ИМХО неадекватные и начинаются от 700 вашингтонов за устройство.

Мое мнение, что такой контроллер не должен стоить дороже 300 вашингтонов.
Эта цена в 300 складывается из стоимости нового компьютера (лэптопа) на винде за 200 вашингтонов и собственно стоимости контроллера USB к повороткам за 100 вашингтонов.

так сделайте сами, там нет ничего сложного на самом деле, 700 конечно дороговато, по железу в 10к деревянных легко укладывается ))

[RA3GN]

rc3m
tci вы явно не оценили, это сетевой протокол, указал ip адрес и порт, сансдр2 ставил в деревне, а споты получал в городе, посмотрите на сайте iw7dmh, как можно управлять сансдром, человеку нравиться, особенно - по воздуху.