sshuttle kontra pełny VPN: co jego metoda naprawdę obejmuje

sshuttle jest wybierany, bo SSH już działa, a kryptografia wygląda znajomo, i to rozumowanie pomija jedyne pytanie, które decyduje o przydatności. Które pakiety opuszczają maszynę, które konto przenosi je po drugiej stronie i ile lokalnych uprawnień wymaga narzędzie. Te trzy odpowiedzi różnią się w zależności od metody przekazywania, więc konfiguracja działająca dla jednej aplikacji może po cichu zawieść dla następnej. Poniższy przegląd zaczyna się od protokołu, którego aplikacja naprawdę potrzebuje.

Zacznij od protokołu, którego potrzebuje aplikacja

Obsługa protokołów w sshuttle 2.0 zależy od wybranej metody. Metody NAT i nft w Linuksie obsługują TCP i DNS, a TPROXY dodaje ogólny UDP. Każda platforma i metoda mają własne granice, a macOS przechwytuje za pomocą zupełnie innego mechanizmu. Przed wyborem czegokolwiek zapisz zainstalowaną wersję, wybraną metodę i protokoły potrzebne aplikacji.

Działające żądanie TCP dowodzi więc bardzo niewiele o aplikacji UDP albo o każdym zapytaniu DNS. sshuttle traktuje też TCP jako strumienie, zamiast tunelować całe pakiety IP, więc wniosek o przepustowości zapożyczony z typowego VPN nie przenosi się tutaj. Porównaj mechanizm, który naprawdę uruchamiasz, z obciążeniem, które naprawdę masz.

Czego klient potrzebuje lokalnie

Udokumentowany układ klienta wymaga roota lub sudo, ponieważ instaluje lokalne reguły przechwytywania, a nie tworzy interfejsu tunelu. Ten jeden fakt zmienia historię bezpieczeństwa: proces z tym uprawnieniem może przekierować ruch całej maszyny, nie tylko jednej aplikacji. Traktuj uprawnienie jako część projektu, a nie szczegół instalacji.

Potwierdź, jakie reguły zainstalowało narzędzie i że znikają przy wyjściu. Zawieszona sesja, która zostawia reguły przechwytywania, może wysłać ruch w czarną dziurę długo po tym, jak operator uzna, że połączenie zniknęło, a objaw wygląda na awarię sieci, a nie na pozostałą regułę.

sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route

Pierwsze polecenie to kształt typowego wywołania, z prefiksem, którego naprawdę potrzebujesz. Drugie pokazuje, co zainstalowało narzędzie, a trzecie potwierdza, że nie pojawił się interfejs tunelu, co jest oczekiwanym wynikiem dla tego projektu.

Co uruchamia zdalna strona

Zdalna strona to autoryzowane konto SSH oraz zgodne środowisko pomocnika w Pythonie. Logowanie, które udaje się w ograniczonej powłoce, nie daje automatycznie prawa do uruchomienia tego pomocnika, a konto, które potrafi uruchomić pomocnika, nie dociera automatycznie do każdej usługi docelowej. Oba fakty należą do wniosku o dostęp, a nie do notatek o rozwiązywaniu problemów.

Chroń weryfikację tożsamości hosta i uwierzytelnianie konta. Przyjęcie nieznanego klucza hosta, aby pierwsze połączenie zadziałało, usuwa sprawdzenie, że zdalna strona to zamierzona maszyna, i tutaj waży to więcej niż przy przekazywaniu do jednego celu.

Ogranicz zdalne konto do usług potrzebnych w procesie pracy i uzgodnij ten zakres z osobami obsługującymi hosta. Są oni częścią relacji zaufania i żadne ustawienie po stronie klienta tego nie zmienia.

Gdzie przebiega granica zaufania

Przekazywanie prywatnego połączenia API przez SSH nie autoryzuje każdej operacji API. TLS aplikacji i logowanie do aplikacji nadal obowiązują, a narzędzie nie potrafi uczynić bezpieczną usługi bez uwierzytelniania. Kolejny skok ze zdalnego hosta też nie jest automatycznie tym samym chronionym segmentem co kanał SSH, bo to drugie połączenie podlega polityce, jaką ma zdalny host.

Zapisz granicę jednym zdaniem: ruch do tych prefiksów wychodzi przez to konto na tym hoście. Jeśli zdanie wymaga akapitu wyjątków, projekt robi więcej, niż twierdzi jego dokumentacja, i zasługuje na drugie spojrzenie, zanim trafi na produkcję.

Udowodnij to dla każdego protokołu, potem wybierz narzędzie

Przetestuj każdy wymagany protokół nieszkodliwym żądaniem, łącznie ze ścieżką resolvera i rodzinami adresów używanymi przez aplikację. Uwzględnij w teście rozłączenie, aby dozwolone zachowanie aplikacji przy awarii stało się znanym wynikiem, a nie niespodzianką podczas incydentu. Sesja, która przekazywała poprawnie, dopóki działała, nic nie mówi o tym, co dzieje się po jej zerwaniu.

Dla kilku wyraźnie nazwanych usług zwykłe lokalne przekazywanie jest łatwiejsze w utrzymaniu i audycie. Dla ruchu aplikacji, który pasuje do jego metody, sshuttle oferuje uzasadnioną drogę pośrednią. Gdy wymaganiem jest szeroka łączność IP, projekt VPN jest uczciwą odpowiedzią, a wybór idzie za pokryciem i odpowiedzialnością operacyjną, a nie za rankingiem algorytmów szyfrowania.