На http://www.voip-info.org/wiki/index.php?page_id=2716 говорится:«Обратите внимание, что SSH-туннелирование не является жизнеспособным методом для VoIP-шифрования медиа-тракта». Почему нельзя использовать SSH-туннелирование (в отличие от VPN) для шифрования VOIP при использовании незащищенных протоколов VOIP (таких как обычный SIP)?
3 ответа
3
Протокол SSH запускается поверх TCP-части стека TCP/IP. SIP или другой тип VoIP обычно работает поверх протокола UDP.
Одним из существенных различий между TCP и UDP является то, что TCP (в некоторой степени) гарантирует доставку каждого пакета. UDP с другой стороны нет. Это огонь и забыл. Следствием этого является то, что при некотором сбое в сети TCP остановится и попытается повторно отправить отсутствующие / поврежденные пакеты. С UDP они будут просто потеряны.
Когда вы применяете его к VOIP, пропущенный пакет UDP превращается вызывающим абонентом в просто искаженное слово. Отсутствующий TCP-пакет становится непоследовательным и раздражающим: задержки, все еще искаженные слова и другие помехи во время вызова.
В приложениях, где некоторая потеря пакетов не является критичной, таких как передача голоса или потоковая музыка или определенные типы потокового видео или некоторые другие приложения, связанные с в реальном времени, UDP является вполне приемлемым, а TCP обеспечивает ненужные накладные расходы и сложности.
Протокол SSH ожидает соединение без потерь, потому что для него каждый пакет имеет решающее значение для обеспечения целостности данных, зашифрованных внутри соединения SSH.
1
Обратите внимание, что SSH туннелирование не является жизнеспособным методом для шифрования медиа-пути VoIP.
Акцент мой.
Медиапоток обычно согласовывается во время вызова SIP с использованием протокола описания сеанса, часто в качестве двунаправленного аудиопотока с использованием транспортного протокола реального времени.
Из статьи в Википедии для RTP:
Протокол управления передачей (TCP), хотя и стандартизированный для использования RTP, обычно не используется в приложениях RTP, потому что TCP предпочитает надежность по сравнению с своевременностью. Вместо этого большинство реализаций RTP основаны на протоколе пользовательских дейтаграмм (UDP).
Другие ответы о различиях между UDP и TCP применимы (особенно при попытке туннелирования UDP по SSH), но они не так важны для SIP, как для RTP. SIP вполне способен работать поверх TCP (и даже SCTP). Задержка и / или повторные передачи сети могут быть обработаны транспортным протоколом (TCP / SCTP) или, в случаях, когда эти функции не предоставляются на транспортном уровне (UDP), SIP имеет свои собственные механизмы для повторных передач и тайм-аутов.
Однако вы можете столкнуться с проблемами при маршрутизации SIP через туннелирование TCP через SSH. Это по тем же причинам, почему SIP, пересекающий NAT, не очень прост. Многие заголовки в телах SIP и SDP содержат соответствующие IP-адреса, которые вы можете неявно скрывать в туннеле. Шлюзы прикладного уровня обычно обрабатывают это в сценариях NAT.
На самом деле, если вы не будете осторожны, вы можете в конечном итоге туннелировать SIP через SSH, вообще не туннелируя RTP!
1
Я думаю, что мы можем только догадываться о намерениях авторов и целевой аудитории (и иметь в виду, что было написано более 5 лет назад). Я бы сказал, что проблема в том, что SSH предназначен для обработки потоков TCP, а не UDP.
Несмотря на то, что я нашел ссылку на туннелирование UDP через SSH, похоже, что это более сложный взлом, вероятно, не идеальный для сети VOIP. Точно так же, хотя некоторые VPN (например, OpenVPN) могут создавать TCP-туннели, я думаю, вы найдете наиболее предпочтительные UDP-туннели, поскольку они более терпимы к потере пакетов.
Рассматривая характеристики туннеля TCP против UDP, если туннель UDP теряет пакет, который ему не нужен, он отбрасывает его и ожидает, что инкапсулированный поток (если его TCP) или приложение (если его UDP) его обработают. Туннель TCP будет пытаться повторно отправить пакет, что может привести к внезапному и значительному увеличению дрожания соединения, что сделает соединение VOIP очень несчастным, особенно если конечные точки находятся далеко.