Не больше 2ГБ через SSH за раз? Так должно быть?

У вас же х64 системы, да?

Да, конченные точки - х64. А что внутри Микротика с Асусом - не знаю. Думаете там что-то 32-битное может мешать?

Напрашивается флешка гигабайт на 16 и обмен файлом через неё.

Так-то да. Но в город ехать лень. Приспичило вот.

ну как вариант.

А если через scp?

Возможно правильный порядок все же

-> Микротик -> OpenVPN Client -> МТС модем -> интернеты -> ?

На микротике по логам openvpn соединение не рвется? может добрый мтс против скачивания больших файлов по сотовой сети?

На микротике по логам openvpn соединение не рвется?

Да, действительно, рвётся.

971	Mar/10/2023 16:15:11	memory	ovpn, info	ovpn-out1: disconnected <poll error>	
972	Mar/10/2023 16:15:11	memory	ovpn, info	ovpn-out1: terminating... - poll error	
973	Mar/10/2023 16:15:11	memory	ovpn, info	ovpn-out1: disconnected	
974	Mar/10/2023 16:15:11	memory	ovpn, info	ovpn-out1: initializing...	
975	Mar/10/2023 16:15:11	memory	ovpn, info	ovpn-out1: connecting...	
976	Mar/10/2023 16:15:14	memory	ovpn, info	ovpn-out1: using encoding - AES-128-CBC/SHA1	
977	Mar/10/2023 16:15:14	memory	ovpn, info	ovpn-out1: connected	
978	Mar/10/2023 16:28:46	memory	ovpn, info	ovpn-out1: disconnected <poll error>	
979	Mar/10/2023 16:28:46	memory	ovpn, info	ovpn-out1: terminating... - poll error	
980	Mar/10/2023 16:28:46	memory	ovpn, info	ovpn-out1: disconnected	
981	Mar/10/2023 16:28:46	memory	ovpn, info	ovpn-out1: initializing...	
982	Mar/10/2023 16:28:46	memory	ovpn, info	ovpn-out1: connecting...	
983	Mar/10/2023 16:28:49	memory	ovpn, info	ovpn-out1: using encoding - AES-128-CBC/SHA1	
984	Mar/10/2023 16:28:49	memory	ovpn, info	ovpn-out1: connected	

Если не сильно нужен ssh, может тогда через bittorrent?

Версия прошивки на мокротыке актуальная? Я свои недавно до 7.8 обновлял все.

OpenVPN Server -> ASUS

Я правильно понял, что это OpenVPN Server на роутере Asus?

Я правильно понял, что это OpenVPN Server на роутере Asus?

Да, там своя родная прошивка, со своим родным OpenVPN.

Версия прошивки на мокротыке актуальная? Я свои недавно до 7.8 обновлял все.

Угу. Вот только что до 7.8 обновился. Полазил по RDP через VPN. Пока никаких обрывов, если ничего не закачивать большого не было. Минут 40 уже всё стабильно. Пойду, попробую опять тот файл выдернуть. Уже из чистого любопытства.

Да, там своя родная прошивка, со своим родным OpenVPN.

Не страшно выпускать в интернет такое? Версия ovpn у корейцев хоть какая?

Не страшно выпускать в интернет такое?

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

Версия ovpn у корейцев хоть какая?

Понятия не имею. В ВебМорде не написано. Пойду, попробую к нему самому по ssh подключиться, может там увижу.

------

Смотрите какая штука теперь стала:

При первой попытке вызвать rsync - мгновенно и сразу Микротик моргнул ovpn'ом. Естественно и rsync ответил сразу

Connection reset by 192.168.71.95 port 22
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(231) [Receiver=3.2.7]

При второй попытке (после переподключения ovpn) - rsync пошел качать и качает уже минут 20 без остановки. Уже 4ГБ накачал и останавливаться вроде не собирается.

---

Накаркал

rsync: connection unexpectedly closed (4291919926 bytes received so far) [receiver]

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

Так угроза здесь не в «понадобится», угроза со стороны китайских скриптов, которые скопом сканируют весь интернет и влезают везде, где только получится. А там уже обширный спектр от подкидывания майнеров до постинга экстремистского ЦП через твою сеть. Если только имеется дыра - вероятность стремится к единице.

Версия ovpn у корейцев хоть какая?

# uname -a
Linux RT-AC65P 3.10.14 #1 SMP Thu Mar 4 14:50:56 CST 2021 mips GNU/Linux

# /etc/openvpn/vpnserver1 --version
OpenVPN 2.4.7 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar  4 2021

Это плохо?

OpenVPN 2.4.7 – Released 21 February 2019

Я не уверен, что корейцы бэкпортируют патчи.

Vulnerabilities in OpenVPN 2.4.7:

«Authentication bypass in OpenVPN», «Denial of service in OpenVPN», «Denial of service in OpenVPN»

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

Поэтому и надеюсь на миллионы других селёдок, которые и этого не сделали, а акулы ими насытятся.

Справедливости ради, все они ни о чём (а когда бывало по-другому с этими вашими буязвимостьями…) - authentication bypass касается отсроченной аутентификации через плагины (да ещё и требуется, чтоб таких плагинов было включено несколько), первый DoS так же, но уже одного плагина аутентификации. Второй DoS возможен в течение нескольких секунд между подключением а инициализацией шифрования.

Нашел обсуждение. Правда, там решения нет, одни предположения.

омг.. 2004. это какой-то мертвый тред.

Через VPN в другой стране попробуйте первым делом. Если всё в порядке, то виноват Роскомнадзор. Вижу на некоторых провайдерах переподключение OpenVPN-сессий ровно раз в 3 часа, вполне вероятно, что есть и по трафику ограничение.

Рассказываю обстановку на текущий момент )

Первый запуск rsync - стабильно рвёт соединение. И судя по логам на OpenVPN сервере (ASUS)

SIGTERM[soft,remote-exit] received, client-instance exiting

Если сразу тут же запустить второй раз rsync - всё хорошо, соединяется.

Если подождать N секунд (вот не засекал точно) и опять попробовать rsync - снова разрыв.

По-моему теперь уже речи нет про какое-то ограничение в 2ГБ. По-моему теперь выглядит так, что когда обращение через SSH (мы же тут получаем что-то вроде шифрования внутри шифрования? нет?) - Микротик рвёт существующую сессию и создает новую зачем-то. Что-то ему не нравится именно в SSH. Вроде бы.

нет. у меня по 20 гигов качается

2 в 32 степени же, а если с отрицательными, то 2 в 31 как раз 2 гига (2147483647 байт)

Что-то ему не нравится именно в SSH

Чтобы проверить эту теорию хочу попробовать через rcp подергать за файлы.

И не могу победить. Может кто поможет запустить?

Делаю так: на машине-источнике запускаю systemctl start rsh.socket и systemctl start rlogin.socket Вижу по ss -ltunp появились порты 513 и 514.

на машине-приемнике запускаю rcp vasya@192.168.71.95 bla_bla_bla, в ответ получаю Password incorrect.

$HOME/.rhosts на обеих машинах заполнил. Что забыл сделать? Как запустить копирование с удаленной машины мимо SSH?

перевернув в UDP всю эту кухню

По существу проблемы нет хороших идей, однако. Пробовали TCP?

через rcp

Если оно до сих пор живо, то rtfm.

Можно ещё попробовать magic wormhole: https://github.com/magic-wormhole/magic-wormhole

Если оно до сих пор живо, то rtfm.

RTFM-то, RTFM'ом

А почему оно меня видит не конечной точкой, а промежуточной VPN-овской? Так должно быть при tun+udp ?

rshd[1336]: vasya@::ffff:10.8.0.6 as vasya, PAM: Authentication failure

Во-первых я бы попробовал (как тут уже упоминалось) SCP
Во-вторых если это только на один раз, то как же старый-добрый колхоз смекалка? Заархивируйте и «порежьте» на той стороне файл частями, равными ~ 1.5 Гб. Передайте куда надо и соберите воедино

И не могу победить.

Победил максимально топорно - тупо в /etc/pam.d/rsh разрешил всё всем. Без всяких .rhosts. Всё одно ж - только на посмотреть.

Посмотрел. Да, rcp никаких обрывов не вызывает. Всё ровно и тихо.

Всё-таки что-то с двойным заворачиванием в VPN+SSH не так. Возможно ValdikSS даже теорию знает, что там может запутываться.

SCP - оно ж тоже через SSH, поэтому даже не пытался. Но если вы настаиваете - пойду, попробую )

---

Попробовал

Connection reset by 192.168.71.95 port 22
scp: Connection closed

Можно ещё попробовать magic wormhole

Честно попробовал. Просто чтоб отблагодарить за совет.

Не смог запустить.

На одну машину оно притащило 35 каких-то питоньих файлов из pacman. Но хоть запускается.

На другую машину оно притащило 19 из того же pacman. И не запускается. Что-то у него там «deprecated» в районе OpenSSL crypto.py. Подозреваю что-то из pip у меня там было установлено мимо pacman. Лень разбираться.

fat16?

Почитал...

fat16?

Где? Почему?

Конечные ОС - практически одинаковые ArchLinux с ext4. Сейчас вот полчаса убил - ещё и питоньи запчасти в единообразие привёл на обеих.

---

Не. Это точно что-то с самим SSH внутри VPN. Возможно я как-то неправильно настроил на роутерах - то ли маршруты, то ли правила между двумя сетями.

Сижу вот целый день тренируюсь. После перерыва в ~10 минут делаешь ssh vasya@192.168.71.95 - сразу же обрыв соединения и ovpn на Микроотике переподключается. Сразу второе соединение туда же, той же командой - всё нормально.

Ждешь ~10 минут - и опять первый обрыв при попытке подключится.

В голову лезут всякие временные метки, тикеты и подобная ерунда. Почему-то именно после простоя и попытке нового SSH Микротик решает, что сессия протухла. Как-то так, что ли.

Пересылал по scp с одного одноплатника на другой файл 64гб. Ничего не рвалось.

Добавь другой ssh порт на целевой машине и пробуй его. ХЗ куда ты вообще стучишь

Добавь другой ssh порт на целевой машине

Разверните мысль. Второй sshd что ли запустить? А так бывает? Научите?

Dropbear еще могу более-менее себе представить параллельно на другом порту. Пойду, попробую.

targitaj Запустил dropbear рядом с sshd на 222 порту. Теперь их оба два.

Обрывает VPN на Микротике точно так же. И какой вывод должен быть из сего?

Просто в конфиге ssh демона две строки Port.

Цель - исключить возможные промежуточные сервисы с портом 22.

Другие сервисы на 22 порту на этом же IP? И такое бывает?

Между тем - dropbear-то иначе себя ведёт.

Когда я пытаюсь ssh vasya@192.168.71.95 -p 222 - на Микротике VPN таки падает. В логах те же ошибки появляются ovpn-out1: disconnected <poll error>

Но

В отличие от 22 порта, где настоящий sshd сразу разрывает соединение - на 222 порту оно тупо висит и ЖДЁТ когда там Микротик переподкючится. И таки дожидается без разрыва, и таки спрашивает пароль.

До чего же весёлая игра.

В отличие от 22 порта, где настоящий sshd сразу разрывает соединение - на 222 порту оно тупо висит и ЖДЁТ когда там Микротик переподкючится. И таки дожидается без разрыва, и таки спрашивает пароль.

ну вот разное поведение и указывает на то, что ты попадаешь в разные места в твоей цепи

Как по мне - это больше похоже на разную реализацию протокола.

«Более честный» sshd хочет быстрее и больше разговаривать - и не получив какого-то протокольного ответа - закрывает клиента.

«Более легкий» dropbear в каком-то упрощенном режиме тупо укладывается в свои таймауты ответов за те 3-5 секунд пока Микротик заново туннель поднимает.

Пойду, sshd перевешу на какой-нибудь 333.

----

$ ssh vasya@192.168.71.95 -p 333
Connection reset by 192.168.71.95 port 333

От порта точно не зависит.

tcp    LISTEN  0        1000             0.0.0.0:222           0.0.0.0:*      users:(("dropbear",pid=1463,fd=3))  
tcp    LISTEN  0        128              0.0.0.0:333           0.0.0.0:*      users:(("sshd",pid=1697,fd=3))

Вот что больше всего смущает, так это:

Last login: Sat Mar 11 23:52:40 2023 from 10.8.0.6

А! Так, собственно, Send-Q у dropbear 1000, а у sshd 128.

Если я правильно понимаю, это очередь пакетов для отправки где-то на уровне ядра. Вот у dropbear и хватает этой очереди дождаться переподключения VPN. Наверное.

VPN может «обрывать» из-за rekeying’а. Не знаю особенности реализации конкретно в Mikrotik (она там плохая), но по умолчанию OpenVPN делает его каждый час либо каждые 64 мегабайта для 64-битных шифров Blowfish.
См. опции --reneg-bytes и --reneg-sec. Возможно, у вас где-то несовместимость.

OpenVPN делает его каждый час

Да, так и есть. Эти разрывы ровно 1 раз в час на Микротике. При условии, если его не теребить просьбами подключиться через ssh.

160	Mar/11/2023 01:21:21	memory	ovpn, info	ovpn-out1: disconnected <poll error>	
167	Mar/11/2023 02:21:27	memory	ovpn, info	ovpn-out1: disconnected <poll error>	
174	Mar/11/2023 03:21:32	memory	ovpn, info	ovpn-out1: disconnected <poll error>	
181	Mar/11/2023 04:21:37	memory	ovpn, info	ovpn-out1: disconnected <poll error>	

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

437	Mar/12/2023 00:14:21	memory	ovpn, info	ovpn-out1: disconnected <poll error>	
444	Mar/12/2023 00:24:35	memory	ovpn, info	ovpn-out1: disconnected <poll error>

Rekeying должен проходить незаметно, без реальных разрывов. Если у вас при этом разрывается сессия — проблема в совместимости/настройках.

ArchLinux куда закачиваю

cat /proc/sys/net/ipv4/tcp_keepalive_time

если значение большое (час и более), то попробуй уменьшить до 10 мин на хосте где запускаешь копирование

Если у вас при этом разрывается сессия — проблема в совместимости/настройках.

Равномерные разрывы раз в час - удалось убрать.

Настройки reneg-sec на Микротике нет. Зато нашел её на Асусе. Не уверен, что это хорошо - в ноль её ставить на сервере. Тем не менее - вот ночь прошла - разрывов не было.

Только это вообще никак не повлияло на разрыв при попытке подключения по ssh. Там всё осталось так было:

[--- тут можно пингами потрогать 192.168.71.95 - отвечает---]
$ ssh vasya@192.168.71.95
Connection reset by 192.168.71.95 port 22
[--- тут на Микротике ovpn-out1: disconnected <poll error>---]
$ ssh vasya@192.168.71.95
vasya@192.168.71.95's password: 
Last login: Sun Mar 12 01:29:56 2023 from 10.8.0.6