Чи є недоліки в тунелізації SSH?

Нещодавно я "купив" VPS, який я хочу використовувати як проксі, щоб мати можливість використовувати деякі сайти та речі, до яких я не можу дістатися з Німеччини.

Оскільки я ще лінувався налаштовувати Squid та OpenVPN (що, на даний момент, на мою думку, потрібно), я використовую ssh-тунелювання.

Тепер, через пару тижнів, я запитав себе, чи не туш-тунелювання не просто добре, або - і це моє питання - чи є якісь застереження / противаги / недоліки, про які я маю мати на увазі?

ssh proxy ssh-tunneling

— Нілс Рідеман
джерело

Для чого це варто, налаштувати OpenVPN надзвичайно просто, використовуючи статичний ключ, якщо ви переходите з Linux на Linux. Трохи складніше, якщо одна з ваших машин є Windows, але виконана. bit.ly/ujkD2

— транзистор1

Відповіді:

Проблема продуктивності виникає, коли ви налаштовуєте TCP через TCP, оскільки у вас два шари роблять адаптаційні корективи (повільний старт, уникнення заторів, швидка передача, див. RFC2001 ).

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

На цій сторінці детально описано явище.

редагувати:

Замість того, щоб дотримуватися проблеми TCP над TCP, подивіться на sshuttle, що запобігає його.
Перегляньте розділ під назвою " Теорія роботи ", щоб отримати детальнішу інформацію про цю ситуацію.

— Шадок
джерело

Хіба внутрішній шар не знає, що він спілкується з інтерфейсом петлі?

— Випадково832

Що стосується вашого питання, проблема полягає в тому, що TCP не підтримує відключення цих "оптимізацій", навіть якщо він якось "усвідомлює свою позицію" як внутрішній потік, він нічого не може зробити. Проблема тут полягає в тому, що зовнішнє адаптаційне поведінка порушить внутрішню, яка спробує адаптуватися, уповільнивши, наприклад, повторну передачу, хоча зовнішній потік TCP вже адаптується до цього.

— Шадок

Я думав про випадок, коли це звичайне тунельне TCP-з'єднання, а не "TCP через IP через PPP через TCP" - у цьому випадку насправді немає другого стека протоколу TCP - ssh просто пересилає потік байтів. І я не мав на увазі "усвідомлення своєї позиції як внутрішнього потоку", я мав на увазі, як у цій ситуації він матиме інтерфейс зворотного зв'язку (місцевий порт ssh слухає) як його місце призначення.

— Випадково832

OP говорив про "деякі сайти", я припускав, що він робив HTTP через SocksV5 через SSH, це означає, що він робить TCP через TCP (сам SSH - це TCP, а HTTP всередині тунелю протікає через інші потоки TCP, які інкапсульовані в SSH).

— Шадок

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

— jpc

Одне, про що я можу придумати, - це продуктивність. Але це дійсно залежить від того, які речі ви тунелюєте.

— Маркус
джерело

Який виступ? Пропускна здатність? Зараз я використовую його для доступу до hulu та деяких відео на YouTube, які заблоковані.

— Нілс Рідеманн

Найбільш вірогідні CPU (шифрування) та, можливо, затримка.

— XTL

Зазвичай я виявив, що затримка збільшується, але пропускна здатність нормальна (90%) від норми при тунелюванні SSH. Не забудьте встановити, ServerAliveIntervalщоб запобігти відключенню, і загорніть його в сценарій, щоб продовжувати перезапуск тунелю при відмові.

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

Можливо, вам доведеться запустити GatewayPortsна клієнті або SSH-сервері, щоб дозволити іншим підключатися через ваш тунель. На сервері для цього потрібен кореневий доступ до sshd_config.

Основний застереження щодо ефективності (як зазначають інші) полягає в тому, що ненадійні з'єднання, ймовірно, не відповідають успіхам при такому підході, оскільки алгоритми TCP не реагують добре під час інкапсуляції.

Однак, SSH, здається, "робить правильно" більшу частину часу.

— Стю Чарлтон
джерело

Проблема з ненадійними з'єднаннями, які ви спостерігаєте, ймовірно, пов'язана із збільшеною затримкою та рукостисканням, які потрібно повторити, коли падіння з'єднань. Переадресація портів SSH не робить інкапсуляцію tcp-over-tcp.

— jpc