Подключение к устройству по SSH через ip, назначенный OpenVPN

Копай в сторону проблем с MTU. Попингуй адрес большими пакетами, 1500+, посмотри, работает ли фрагментация.

пинг большими пакетами проходит норм (пробовал -l 60000), если пинговать без фрагментации то предел ~1472. Одинаково работает с обеими ip.

Обратил внимание, что когда пытаюсь соединиться с ip 10.8.0.104 (назначенным openvpn), то статус ssh RK3318 содержит информацию об успешно открытой сессии: Apr 07 15:59:18 rk3318-box sshd[4228]: Accepted password for user from 10.8.0.1 port 52362 ssh2 Apr 07 15:59:18 rk3318-box sshd[4228]: pam_unix(sshd:session): session opened for user user(uid=1000) by (uid=0)

Попытка соединения идет с ip 10.8.0.1, это ip домашнего компа, также назначенный openvpn.

А с рокчипа обратно пинг как ходит?

Обратно с пингом что то не то, но картина одинаковая что для пинга 192.168.1.180 (адрес компа в LAN), что 10.8.0.101 (адрес этого же компа как клиента openvpn):

ping 192.168.1.180 -l 1000 1003 packets transmitted, 282 packets received, 71% packet loss round-trip min/avg/max/stddev = 2.235/20.858/28.176/7.318 ms

ping 10.8.0.101 -l 1000 1007 packets transmitted, 454 packets received, 54% packet loss round-trip min/avg/max/stddev = 14.984/127.533/170.283/46.264 ms

Если отправлять большими пакетами, то картина еще хуже ^C— 10.8.0.101 ping statistics — 60002 packets transmitted, 493 packets received, +125 duplicates, 99% packet loss round-trip min/avg/max/stddev = 12.939/592.150/1220.578/495.185 ms

Но картина одинакова для пинга адресов что в LAN, что в openvpn!

При этом по локальной сети подключение c 192.168.1.180 по ssh работает и странный пинг с рокчипа этому будто не помеха …

ps пинг мелкими пакетами (до 200 байт) с рокчипа проходит ок, по обеим подсетям

+125 duplicates

Что у тебя за дичь с маршрутами там?

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

Проблему нашел! VPN туннель поднял по UDP, а SSH работает только по TCP. Установил mosh - получил соединение через VPN по UDP. Вопрос закрыт.

Есть такая вещь ngrok называется, он позволяет локальный ресурс проксировать в интернеты

Даже из своей локальной сети.

Как раз с начала нужно проверть заход по ssh не с компов локальной сети, а с openvpn сервера.

В целом у вас творится какая-то дичь с маршрутизацией, так как dup не должны появляться.

Но картина одинакова для пинга адресов что в LAN, что в openvpn!

И это нужно лечить не перестановкой armbian, а изучением маршрутов, дампов пакетов. Может на openvpn сервере что-то навёрнуто с фильтрацией пакетов и пр., раз он с белым ip-адресом.

А вы пишете ещё большую дичь про UDP. То, по какому протоколу поднят тунель не влияет на то, какие пакеты могут ходить по этому тунелю.

Лучше с этим разберитесь, пока есть время, а то потом захочется каким-нибудь другим софтом взаимодействовать с одноплатником, а там будет только tcp.

с ip 10.8.0.1, это ip домашнего компа, также назначенный openvpn.

Станный набор адресов 10.8.0.1, 10.8.0.101, 10.8.0.104, а сам openvpn-сервер на каком адресе?

Станный набор адресов 10.8.0.1, 10.8.0.101, 10.8.0.104, а сам openvpn-сервер на каком адресе?

OpenVPN cервер на 10.8.0.1, а клиенты 101, 102 итд. Выше в тексте немного напутал указав 10.8.0.1 домашним компом (домашний 10.8.0.101), но это сильно ничего не меняет.

В целом у вас творится какая-то дичь с маршрутизацией, так как dup не должны появляться.

Ну да, то что дичь согласен, буду разбираться.

И это нужно лечить не перестановкой armbian, а изучением маршрутов, дампов пакетов

Проблема с пингом c RK3318 большими пакетами любых устройств домашней сети, даже без OpenVPN.

А вот если пинговать сам RK3318 с других устройств, то все отлично. И другие устройства в сети между собой пингуются отлично любыми пакетами во всех направлениях.

Значит дело либо самом RK, либо в роутере (проверю настройки, переткну в другой порт), больше то негде… разве не так?

Значит дело либо самом RK, либо в роутере

Рассуждения, это хорошо, но лучше по максимуму использовать средства диагностики. Например, tcpdump. Можно просто запустить tcpdump на RK и на другом компе и при этом сделать пинг длинным пакетом, можно с фильтром:

# tcpdump -n -nn -i eth0 \( not tcp and not udp \)

Там должны быть показаны отдельные ip-пакеты, на которые фрагментируется «большой пинг». Первый icmp, а остальные фрагменты как просто ip-proto. И там можно понять, уходит пакет с RK, приходит на пингуемый комп, идёт от туда ответ и т.д.

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

Огромное спасибо!

Пока перешел с UDP на TCP, и все заработало (доступ по ssh есть, доступ к веб сервисам развернутым на RK тоже есть).

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

А так конечно, буду разбираться что за ситуация с этим RK. Тем более он работает 24/7 и через него идет доступ.

Еще раз благодарю всех причастных за помощь!

Есть такая вещь frp называется, он позволяет локальный ресурс проксировать в интернеты

Что это за набор слов?..

Есть такая вещь frp называется, он позволяет локальный ресурс проксировать в интернеты

Благодарю, коротенько прочитал, для меня это слишком сложно, да и пока ни к чему.

Дико извиняюсь за «набор слов», излагал не по природному скудоумию, а в связи с отсутствием специальных знаний сисадмина и совсем другой специализацией в жизни))

Короче все проблемы ушли, когда настроил VPN туннель по протоколу tcp вместо udp. И это несмотря на «дичь» с пингом с RK3318 большими пакетами. Прекрасно работает удаленное соединение с устройствами в локальной по протоколу ssh, веб-морды сервисов удаленно открваются, приложение HomeAssistant на телефоне работает, удаленный рабочий стол тоже функционирует, хоть с компов хоть с телефона) собственно больше ничего и не надо))