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

[YL2QN]

почему L2TP, в сети есть хорошая инструкция от харьковчан.

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

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

[RX4HX]

Если перейти с PPTP на L2TP какие преимущества будут?

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

[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 клиент?
А если этого клиента нет, ну так же точно можно виртуализацией раскидать кенвудовский протокол по нужным устройствам.

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