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

ОТРЕДАКТИРОВАННЫЙ найдя сценарий обновления.

Список OUI составлен в двоичный файл Netdiscover, таким образом, необходимо будет перекомпилировать его для обновления списка. Можно загрузить источник с сайта Netdiscover, но выпуски (через 0.3beta6) очень стары (приблизительно 2007), так загрузите снимок.

Сам список хранится в src/oui.h в исходном дереве Netdiscover. Можно отредактировать это вручную, если Вам нравится, но существует также названный сценарий генератора update-oui-database.sh который загружает oui.txt от IEEE и повторно создает src/oui.h с нуля. Запустите этот скрипт перед компиляцией.

Это похоже на стандарт ./configure && make && make install скомпилирует и установит программу. (Если ./configure не существует, Вы, возможно, должны работать ./autogen.sh сценарий сначала.) По умолчанию это устанавливает в /usr/local/sbin, но прочитанный вывод ./configure --help удостоверяться.

Я первоначально предложил отправить oui.h возвращается автору, но так как существует сценарий, он вряд ли найдет отправленные изменения полезными.

11
19.03.2012, 12:43
4 ответа

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

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

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

править:

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

10
27.01.2020, 19:58
  • 1
    Разве внутренний слой не знает, что говорит с петлевым интерфейсом? –  Random832 19.03.2012, 15:56
  • 2
    О Вашем вопросе проблема состоит в том, что TCP не поддерживает отключение той "оптимизации", даже если это так или иначе "знало, это - позиция" внутреннего потока, это ничего не может сделать. Проблемой здесь является внешнее адаптивное поведение, разрушит внутренний, который попытается адаптироваться путем замедления повторной передачи, например, хотя внешний поток TCP уже адаптируется к этому. –  Shadok 19.03.2012, 16:10
  • 3
    , я думал о случае, где это - нормальное туннелированное соединение TCP, не "TCP по IP по PPP по TCP" - в этом случае нет на самом деле второго стека протоколов TCP - ssh, просто передает поток байтов. И я не имел в виду "знающий о его позиции внутреннего потока", я имел в виду, как в этой ситуации он будет иметь петлевой интерфейс (локальный порт ssh слушает на) как его место назначения. –  Random832 19.03.2012, 16:30
  • 4
    OP говорил о "некоторых сайтах", я предположил, что он делал HTTP по SocksV5 через SSH, что означает, что он делает TCP по TCP (самим SSH является TCP и HTTP в туннельных потоках по другому TCP потоки, который инкапсулируется в SSH). –  Shadok 19.03.2012, 18:21
  • 5
    @Shadok я вполне уверен Ваши заключения, не верен. apenwarr относился к tun/tap туннелирование, которое приводит к tcp-over-tcp. SOCKSv5, не страдает от тех же проблем, но не работает прозрачно со всеми приложениями (в то время как бочка/касание является просто другим сетевым интерфейсом, таким образом, это может быть обработано прозрачно). –  jpc 25.10.2016, 00:32

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

3
27.01.2020, 19:58
  • 1
    Какая производительность? Пропускная способность? Я в настоящее время использую его для доступа hulu и некоторых видео YouTube, которые заблокированы. –  Nils Riedemann 19.03.2012, 13:34
  • 2
    , служебный (шифрование) и возможно задержка, скорее всего. –  XTL 20.03.2012, 12:19

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

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

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

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

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

1
27.01.2020, 19:58
  • 1
    Проблема с ненадежными соединениями, которые Вы наблюдаете, вероятно, связана с увеличенной задержкой и квитированиями, которые должны быть повторены, когда соединения отбрасывают. Перенаправление портов SSH не делает tcp-over-tcp инкапсуляции. –  jpc 25.10.2016, 00:35

Не должно быть проблем TCP -через -TCP для туннелирования SSH.

ssh decapsulates and re-encapsulates TCP, so you don't have classic TCP-over-TCP issues

Ссылка:

https://en.wikipedia.org/wiki/Tunneling_protocol#cite_note-6

https://marc.info/?l=openssh-unix-dev&m=105554033415532

0
03.09.2021, 23:27

Теги

Похожие вопросы