Есть ли недостатки в SSH туннелировании?

Недавно я «купил» VPS, который хочу использовать в качестве прокси-сервера, чтобы иметь возможность использовать некоторые сайты и материалы, которые я не могу получить из Германии.

Так как я еще не поленился настроить Squid и OpenVPN (что в настоящее время считаю необходимым), я использую ssh-туннелирование.

Теперь, спустя пару недель, я спросил себя, не подходит ли ssh-туннелирование, или - и это мой вопрос - есть ли какие-то предостережения / недостатки / недостатки, которые я должен иметь в виду?

ssh proxy ssh-tunneling Нильс Ридеманн
источник

Что бы это ни стоило, OpenVPN чрезвычайно легко настроить, используя статический ключ, если вы переходите с Linux на Linux. Немного сложнее, если на одной из ваших машин установлена Windows, но выполнимо. bit.ly/ujkD2

транзистор1

Ответы:

Проблема производительности возникает, когда вы туннелируете TCP через TCP, потому что у вас есть два уровня, выполняющих адаптивные исправления (медленный запуск, предотвращение перегрузки, быстрая повторная передача, см. RFC2001 ).

Не осознавая друг друга, они будут испытывать большие трудности, если вы потеряете внешнюю связь.

Эта страница подробно описывает это явление.

редактировать:

Вместо того, чтобы придерживаться проблемы TCP через TCP, взгляните на sshuttle, который ее предотвращает.
Загляните в раздел « Теория работы », чтобы узнать больше об этой ситуации.

Shadok
источник

Разве внутренний уровень не знает, что он говорит с интерфейсом обратной связи?

Random832

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

Шадок

Я думал о случае, когда это обычное туннельное TCP-соединение, а не «TCP через IP через PPP через TCP» - в этом случае фактически нет второго стека протокола TCP - ssh просто пересылает поток байтов. И я не имел в виду «осведомленность о своей позиции как внутреннего потока», я имел в виду, как в этой ситуации он будет иметь интерфейс обратной связи (локальный порт, который прослушивает ssh) в качестве пункта назначения.

Random832

OP говорил о «некоторых сайтах», я предположил, что он делал HTTP через SocksV5 через SSH, что означает, что он делает TCP через TCP (сам SSH - TCP, а HTTP внутри туннеля течет через другие потоки TCP, которые инкапсулированы в SSH).

Шадок

@Shadok Я уверен, что ваши выводы не соответствуют действительности. apenwarr имел в виду tun/tapтуннелирование, которое приводит к tcp-over-tcp. SOCKSv5 is не страдает от тех же проблем, но не работает прозрачно со всеми приложениями (хотя tun / tap - это просто еще один сетевой интерфейс, поэтому он может обрабатываться прозрачно).

jpc

Одна вещь, о которой я могу подумать, это производительность. Но это действительно зависит от того, какие вещи вы туннелируете.

Маркус
источник

Какого рода производительность? Пропускная способность? В настоящее время я использую его для доступа к hulu и некоторым видео на YouTube, которые заблокированы.

Нильс Ридеманн

Скорее всего, загрузка процессора (шифрование) и, возможно, задержка.

XTL

Обычно я обнаружил, что задержка увеличивается, но пропускная способность в порядке (90%) по сравнению с SSH-туннелированием. Обязательно установите, ServerAliveIntervalчтобы предотвратить разъединения, и оберните его в сценарий, чтобы продолжить перезапуск туннеля при сбое.

Основным недостатком является то, что это туннель порта для TCP, если вы не используете SOCKS. С SOCKS все в порядке, но задержка при этом увеличивается еще больше, и, конечно, не каждый клиент поддерживает SOCKS.

Вам может потребоваться запустить GatewayPortsна клиенте или сервере SSH, чтобы позволить другим подключаться через ваш туннель. На сервере это требует root-доступа к sshd_config.

Главное предостережение в отношении производительности (как отмечают другие) заключается в том, что ненадежные соединения, скорее всего, не будут подходить для этого подхода, так как алгоритмы TCP плохо реагируют при инкапсуляции.

Тем не менее, SSH, кажется, "делает правильные вещи" большую часть времени.

Стю Чарлтон
источник

Проблема с ненадежными соединениями, которую вы наблюдаете, вероятно, связана с увеличенной задержкой и рукопожатиями, которые необходимо повторять при разрыве соединений. Переадресация порта SSH не выполняет инкапсуляцию tcp-over-tcp.

jpc