sshuttle против полноценного VPN: что на самом деле покрывает его метод
sshuttle переносит только то, что поддерживает его метод пересылки: сначала проверьте охват TCP, DNS и UDP, необходимые локальные права и удалённого помощника.
sshuttle выбирают потому, что SSH уже работает и криптография выглядит знакомой, а это рассуждение пропускает единственный вопрос, который решает, подходит ли он. Какие пакеты покидают машину, какая учётная запись несёт их на другой стороне и сколько локальных прав требует инструмент. Эти три ответа различаются в зависимости от метода пересылки, поэтому конфигурация, работающая для одного приложения, может тихо отказать для следующего. Разбор ниже начинается с протокола, который приложению действительно нужен.
Начните с протокола, который нужен приложению
Поддержка протоколов в sshuttle 2.0 зависит от выбранного метода. Методы NAT и nft в Linux обрабатывают TCP и DNS, а TPROXY добавляет общий UDP. У каждой платформы и каждого метода свои границы, а macOS перехватывает совершенно иным механизмом. Запишите установленную версию, выбранный метод и протоколы, нужные приложению, прежде чем что-то выбирать.
Поэтому работающий запрос TCP очень мало доказывает о приложении UDP или о каждом запросе DNS. sshuttle также рассматривает TCP как потоки, а не туннелирует целые пакеты IP, поэтому вывод о пропускной способности, взятый у обычного VPN, здесь не переносится. Сравните механизм, который вы действительно запускаете, с нагрузкой, которая у вас действительно есть.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
Что нужно клиенту локально
Документированная схема клиента требует root или sudo, потому что она устанавливает локальные правила перехвата, а не создаёт интерфейс туннеля. Этот единственный факт меняет историю безопасности: процесс с такими правами может перенаправлять трафик всей машины, а не только одного приложения. Относитесь к правам как к части проекта, а не как к детали установки.
Убедитесь, какие правила установил инструмент и что они исчезают при выходе. Сеанс, который упал и оставил правила перехвата, может отправить трафик в чёрную дыру намного позже того, как оператор считает, что соединение пропало, и симптом выглядит как сбой сети, а не как забытое правило.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeПервая команда — это форма типичного вызова с действительно нужным префиксом. Вторая показывает, что установил инструмент, а третья подтверждает, что интерфейс туннеля не появился, что и ожидается для этого проекта.
Что запускает удалённая сторона
Удалённая сторона — это авторизованная учётная запись SSH плюс совместимая среда помощника на Python. Вход, который удаётся в ограниченной оболочке, не даёт автоматически разрешения запускать этого помощника, а учётная запись, способная запускать помощника, не достигает автоматически каждой целевой службы. Оба факта относятся к запросу доступа, а не к заметкам по устранению неполадок.
Защищайте проверку подлинности узла и аутентификацию учётной записи. Принятие неизвестного ключа узла, чтобы первое соединение заработало, убирает проверку того, что удалённая сторона — нужная машина, и здесь это весит больше, чем при пересылке для одной цели.
Ограничьте удалённую учётную запись службами, которые нужны рабочему процессу, и согласуйте этот объём с теми, кто управляет узлом. Они часть отношений доверия, и никакая настройка на стороне клиента этого не меняет.
Где проходит граница доверия
Пересылка частного соединения API через SSH не даёт прав на каждую операцию API. TLS приложения и вход в приложение по-прежнему действуют, и инструмент не может сделать безопасной службу без аутентификации. Следующий переход с удалённого узла тоже не становится автоматически тем же защищённым сегментом, что и канал SSH, потому что это второе соединение следует той политике, которая есть на удалённом узле.
Запишите границу одним предложением: трафик к этим префиксам выходит через эту учётную запись на том узле. Если предложению нужен абзац исключений, проект делает больше, чем заявляет его документация, и заслуживает второго взгляда до выхода в производство.
Докажите это по каждому протоколу, затем выбирайте инструмент
Проверьте каждый нужный протокол безвредным запросом, включая путь распознавателя и семейства адресов, которые использует приложение. Включите в тест и обрыв соединения, чтобы допустимое поведение приложения при сбое стало известным результатом, а не неожиданностью во время инцидента. Сеанс, который пересылал правильно, пока работал, ничего не говорит о том, что происходит после его падения.
Для нескольких явно названных служб обычная локальная пересылка проще в обслуживании и аудите. Для трафика приложений, который подходит его методу, sshuttle предлагает законную середину. Когда требование — широкая связность IP, проектирование VPN и есть честный ответ, и выбор следует за охватом и операционной ответственностью, а не за рейтингом алгоритмов шифрования.