LINUX.ORG.RU

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

 ,


0

2

Здравствуйте.

Пытаюсь загрузить файл 8 ГБ с домашней машины.

Что через обычный sshfs рвётся, что через

rsync --archive --verbose --progress --partial --append-verify vasya@192.168.71.95:/home/vasya/big_file.ext /home/vasya2/big_file.ext
похожая картина, только тут еще и видно сколько в байтах приходило перед обрывом.
rsync: connection unexpectedly closed (2145943606 bytes received so far) [receiver]
rsync: connection unexpectedly closed (2145943606 bytes received so far) [receiver]
rsync: connection unexpectedly closed (2145972317 bytes received so far) [receiver]
rsync: connection unexpectedly closed (2145944389 bytes received so far) [receiver]
Первые два - вообще с точностью до байта.

Сами машины соединены так: ArchLinux куда закачиваю -> провода -> Микротик -> МТС модем -> OpenVPN Client -> интернеты -> OpenVPN Server -> ASUS -> провода -> хост с Windows -> Hyper-V -> проброшенный диск с линуксами -> ArchLinux откуда хочу забрать.

Это в каком месте может быть ограничение подозрительно похожее на MAX_INT32 плюс/минус?

В итоге-то забрал в пять заходов. Просто теорию не знаю. Может это можно как-то починить, когда следующий раз захочется 8ГБ?

★★★★

Ответ на: комментарий от Toxo2

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

Так я больше скажу - оказывается ему даже самого факта попытки подключения не надо. Достаточно обратиться к живому хосту на том конце туннеля. Не важно - есть там кому отвечать или нет.

Сейчас вот забыл порт указать на Асусе - ткнулся к нему и VPN моргнул:

$ ssh vasya@192.168.71.1
ssh: connect to host 192.168.71.1 port 22: Connection refused
[--- тут на Микротике ovpn-out1: disconnected <poll error>---]
$ ssh vasya@192.168.71.1 -p xx22xx
vasya@192.168.71.1's password:

Что такого клиент ssh может слать в сеть, отчего VPN на Микротике сессию теряет?

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от ValdikSS

Пока ничего осмысленно не нашёл.

Если на Микротике включить логи уровня debug - то сам факт <poll error> никак не расшифровывается. Просто вот «ой». Дальше уже в debug всякое sent P_CONTROL_HARD_RESET_CLIENT_V2, которое уже следствие того «ой».

Если смотреть в tcpdump на самой машине откуда делаю ssh - то тоже ничего интересного - при первой попытке просто ответа нет (что и понятно - тот хост-то пропал в конце туннеля), при второй попытке просто нормальное соединение.

Запустил nginx на 80-порту на удаленной машине - соединение по 80му порту никак не влияет на VPN. Тупо работает всегда с первого раза.

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от ValdikSS

Посмотрел в Wireshark, там понятнее вроде:

При первом соединении:

Client: Key Exchange Init
шесть штук TCP Retransmission
и потом [RST]

При втором соединении:

Client: Key Exchange Init
Server: Key Exchange Init
Client: Diffie-Hellman Key Exchange Init
Server: Diffie-Hellman Key Exchange Reply, New Keys
ну и дальше у них уже всё хорошо, договорились

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от ValdikSS

Т.е. вы хотите сказать, что запрос ключей для сессии SSHv2 и установленное соединение в сессии клиент-сервер VPN точно никак не могут быть связаны? Это технически разные вещи и не могут друг другу мешать в принципе? Так?

---

Расскажите пожалуйста, что вы имеете в виду под «Через VPN в другой стране»?

Вот машина D, она ходит в интернеты через М.
М соединён с А через VPN
За А находится машина K, с которой хочу иметь стабильную связь.

Если я на машине D установлю соединение VPN в Голландию так, что для всего остального интернета машина D будет видна как «я в Голландии» - как это мне поможет добраться до машины K в городе через совсем другой туннель? Что поменяется-то? Маршрут 192.168.88.0/24 <-> 192.168.71.0/24 же всё равно останется мимо Голландии? Или в чем фокус?

---

Вот что разумно было бы попробовать - погасить VPN-клинета на М, и сделать D прямым клиентом на А, чтобы исключить особенности реализации OpenVPN на Микротике. Только это малоинтересно в практическом смысле. Обычная схема использования этой системы в обратную сторону - из K, через A и через М смотреть на видеокамеры. В ту сторону - раз в полгода приспичивает.

Toxo2 ★★★★
() автор топика
Последнее исправление: Toxo2 (всего исправлений: 2)
Ответ на: комментарий от ValdikSS

ValdikSS всё почитал, всё понял и всё починил )

Оказывается проблема была в слишком большом MTU.

Когда уже знаешь правильный ответ - кажется, что весь интернет кишит рекомендациями ставить MTU 1200,1300,1400 для OpenVPN на UDP )

Только там нигде не объясняется зачем/почему. А неспециалисту трындец как непросто догадаться, что из-за фрагментации на нижнем уровне такая фигня может происходить с тяжелыми протоколами уровнем выше.

Toxo2 ★★★★
() автор топика