Назад | Перейти на главную страницу

SSH-туннель для прокси socks5 медленный при одновременной загрузке

Я подключился по ssh к удаленному серверу AWS с помощью Ubuntu. Для этого я использую возможности переадресации портов ssh. Я пробовал перенаправить динамический порт (ssh -D) или один порт (ssh -L с dante, работающим как удаленный сервер socks). Оба одинаково медленные. Еще пробовал разные шифры (ssh -c).

Параллельные TCP-соединения практически не работают. Например, я могу зайти на speedtest.net и запустить тест (который довольно быстр, возможно, максимальная скорость моей линии), и если я попытаюсь сделать что-нибудь (например, загрузить google.com), пока тест все еще запущен, все дополнительные подключения вроде зависают, пока не закончится тест скорости.

Я понимаю, что OpenSSH однопоточный. Это проблема? Это даже не отображается на моем топе. То же самое и с sshd на удаленном сервере - процессор не работает.

Есть ли способ повысить производительность ssh или мне следует перейти на OpenVPN или что-то более подходящее для этого?

Попытайтесь исключить данте из уравнения.
просто

ssh -D 1080 username@server

Затем установите в браузере свой прокси socks 5 как localhost: 1080

И повтори свой тест.

Допустим, я сейчас не использую прокси и нахожусь в районе Чикаго
Ниже тест был проведен мной до ближайшего возможного сервера, без прокси

http://beta.speedtest.net/result/5790745951

Теперь давайте настроим прокси ssh -D и настроим мой браузер на использование прокси. Тест скорости теперь определит, что моя точка выхода трафика находится где-то в Калифорнии (поскольку я использую AWS в зоне доступности Калифорнии)
Вот мой тест с носками 1080 (без данте)

http://beta.speedtest.net/result/5790754004

Очевидно, что есть снижение скорости. Прежде всего, мой трафик должен идти от меня в Калифорнию, а затем выйти на другой стороне туннеля ssh и попасть на сервер speedtest, а затем вернуться. Вдобавок ко всему, поскольку он работает внутри туннеля ssh, также добавляется задержка, поскольку ssh необходимо шифровать / дешифровать каждый пакет.

Однако во время тестирования скорости я мог нормально просматривать другие сайты. Медленнее, но не до боли

Теперь я удалю прокси из настроек своего браузера и выберу прямое соединение где-нибудь в Калифорнии.

http://beta.speedtest.net/result/5790802203

Очевидно, что сейчас это быстрее, это практически такая же скорость, как прямое соединение с Чикаго.
Это доказывает, что 99% задержки добавляется туннелем ssh.
Как предлагали другие, вы можете настроить squid и проверить свою скорость с помощью squid. Возможно, у него будет лучшая производительность.

Вероятно, это связано с тем, что каждый раз, когда SSH необходимо настроить соединение с хостом, он должен пройти весь путь до AWS, а затем вернуться на сервер, с которым вы пытаетесь связаться. По сути, это увеличивает задержку от вашей машины к машине AWS и машины AWS к серверу, к которому вы обращаетесь.

Попробуйте проверить связь с машиной AWS со своей рабочей станции и запишите задержку, затем отправьте эхо-запрос на хост, к которому вы обращаетесь, с машины AWS и запишите эту задержку. Сложите их вместе, и это будет теоретическая максимальная задержка, которую вы можете достичь по этой ссылке. OpenVPN и SSH не могут превзойти этот предел, однако, если ваш трафик в основном HTTP, вы можете настроить кэширующий сервер squid на машине AWS или на вашем локальном компьютере, чтобы уменьшить количество запросов, которые должны проходить по этой ссылке.