sshuttle обирають тому, що SSH уже працює і криптографія виглядає знайомою, а це міркування оминає єдине питання, яке вирішує придатність. Які пакети залишають машину, який обліковий запис несе їх на іншому боці і скільки локальних прав вимагає інструмент. Ці три відповіді різняться залежно від методу пересилання, тому конфігурація, що працює для одного застосунку, може тихо зламатися для наступного. Розбір нижче починається з протоколу, який застосунку справді потрібен.

Почніть із протоколу, потрібного застосунку

Підтримка протоколів у sshuttle 2.0 залежить від обраного методу. Методи NAT і nft у Linux обробляють TCP і DNS, а TPROXY додає загальний UDP. Кожна платформа й метод мають власні межі, а macOS перехоплює зовсім іншим механізмом. Запишіть встановлену версію, обраний метод і протоколи, потрібні застосунку, перш ніж щось обирати.

Тож робочий запит TCP дуже мало доводить про застосунок UDP або про кожен запит DNS. sshuttle також розглядає TCP як потоки, а не тунелює цілі пакети IP, тому висновок про пропускну здатність, позичений у звичайного VPN, тут не переноситься. Порівняйте механізм, який ви справді запускаєте, з навантаженням, яке ви справді маєте.

ApproachWhat it carriesWhat it needs locally
SSH local forwardOne explicitly named TCP destinationNothing beyond the SSH client
sshuttle, nft or nat methodTCP and DNS to the routed prefixesRoot or sudo for firewall rules
sshuttle, tproxy methodTCP, DNS and general UDPRoot or sudo, and kernel support
IP VPNRouted IP traffic in a tunnelA 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 і є чесною відповіддю, і вибір іде за охопленням і операційною відповідальністю, а не за рейтингом алгоритмів шифрування.

Схожі статті