Jak mogę tunelować cały mój ruch sieciowy przez SSH?

117

Ilekroć korzystam z Internetu z niepewnej lokalizacji (takiej jak publiczne Wi-Fi), lubię korzystać z tunelu ssh ( ssh -D port host), aby zapobiec wąchaniu mojego ruchu. Niestety wydaje się, że istnieje wiele aplikacji, które nie umożliwiają określenia serwera proxy (jednym z głównych przykładów jest Flash).

Wydaje się, że powinien istnieć sposób wykorzystania tunelu dla całego ruchu sieciowego z mojego komputera, ale jestem całkowicie nieświadomy, jak to zrobić. Każda pomoc byłaby bardzo mile widziana.

Jeremy Banks
źródło
16
Oczywiście nie możesz tunelować dosłownie CAŁEGO swojego ruchu przez ssh, ponieważ oznaczałoby to tunelowanie ssh przez siebie, ale wiemy, co masz na myśli. :)
CarlF,
1
to dobry pomysł, ale jesteś chroniony tylko między komputerem a punktem końcowym ssh. potem twój ruch jest czysty (chyba że inaczej chroniony, np. SSL). to prawda, o wiele bardziej prawdopodobne jest, że będzie to przez przewód, ale nadal ... tak naprawdę nie możesz ufać drutom, których nie kontrolujesz.
quack quixote
6
Ale kiedy jesteś w Internecie, masz pewne bezpieczeństwo będąc jednym z miliardów pakietów, prawda? Kiedy łączysz się z publicznym Wi-Fi, jesteś jednym z 3 połączeń, możesz zostać zidentyfikowany osobiście itp.
endolith

Odpowiedzi:

62

Aby zrobić to, czego chcesz, polecam sshuttle .

Używasz go w ten sposób:

./sshuttle -r username@sshserver 0.0.0.0/0 -vv

Będzie automatycznie tunelował cały ruch TCP. Możesz dodać --dnsargument, aby tunelował również ruch DNS. Serwer zdalny musi mieć tylko zainstalowany Python.

Jeśli chcesz tylko tunelować określone programy, poleciłbym proxy .

Po zainstalowaniu uruchom proxy ssh socks w następujący sposób:

ssh -fND 127.0.0.1:<local port> username@sshserver

Spowoduje to uruchomienie serwera proxy „SOCKS” na <porcie lokalnym>.

Następnie edytuj plik /etc/proxychains.conf, aby wskazywał ten sam port co <port lokalny>.

Na koniec uruchom program, który chcesz proxy:

proxychains <program name>

Powinno po prostu działać. Jednak kilka programów będzie miało problemy z działaniem z łańcuchami proxy. Pamiętaj również, że w Firefoksie musisz zmienić dodatkowe elementy w about: config, aby zmusić go do wyszukiwania DNS przez proxy zamiast ominięcia.

Dodatkowo, w przeglądarkach internetowych. Jeśli obsługują one proxy skarpet, nie musisz robić nic więcej, aby zmusić je do korzystania z wyżej wspomnianego tunelu ssh, po prostu wpisz 127.0.0.1 dla serwera proxy SOCKS i <port lokalny> dla portu proxy.

EDYCJA 3/29/16

Ponieważ w tym poście nadal pojawiają się głosy poparcia, pomyślałem, że go zaktualizuję. Proxychains jest nadal w większości repozytoriów Linuksa i nadal działa w systemie Linux. Jednak projekt został skutecznie porzucony i nie działa na OSX. W przypadku systemu Linux lub OSX bardzo polecam aktualizację do nadal utrzymywanego rozwidlenia: proxychains-ng: https://github.com/rofl0r/proxychains-ng

Oprócz pracy zarówno w systemie Linux, jak i OSX, jest łatwy do skompilowania, a także ma znacznie lepszą obsługę tunelowania DNS.

Powinienem również wspomnieć o innej opcji, którą jest redsocks. Działa podobnie do serwerów proxy (-ng) i jest również prawdopodobne w Twoim repozytorium: https://github.com/darkk/redsocks

skorupiak
źródło
Uwaga dla nowszych systemów Linux korzystających z sshuttle: w momencie pisania jest błąd jądra, który da ci zepsuty potok. W takim przypadku użyj:sshuttle -r root@host -x host 0/0
aggregate1166877
49

man sshpodaje przykład dokładnie tego. VPN oparty na ssh:

SSH-BASED VIRTUAL PRIVATE NETWORKS
     ssh contains support for Virtual Private Network (VPN) tunnelling using
     the tun(4) network pseudo-device, allowing two networks to be joined
     securely.  The sshd_config(5) configuration option PermitTunnel controls
     whether the server supports this, and at what level (layer 2 or 3 traf-
     fic).

     The following example would connect client network 10.0.50.0/24 with
     remote network 10.0.99.0/24, provided that the SSH server running on the
     gateway to the remote network, at 192.168.1.15, allows it:

       # ssh -f -w 0:1 192.168.1.15 true
       # ifconfig tun0 10.0.50.1 10.0.99.1 netmask 255.255.255.252

~~ snip ~~

     Since a SSH-based setup entails a fair amount of overhead, it may be more
     suited to temporary setups, such as for wireless VPNs.  More permanent
     VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8).

Po skonfigurowaniu nowego interfejsu wystarczy ustawić domyślną trasę, co jest innym pytaniem.

PriceChild
źródło
1
Czy możesz wyjaśnić coś więcej? Polecenie ifconfig tworzy nowe interfejsy o nazwie tun0, prawda? A może tun0 jest tworzony przez ssh i po prostu dalej konfigurowany przez ifconfig? Może dodać przykład odpowiedni do pytania?
Nikt
6

Poszukaj opcji „Tunnel” w ssh. Spowoduje to utworzenie urządzenia tunelowego, do którego możesz przypisać adres IP, a następnie zmienisz domyślną trasę korzystania z tego tunelu.

Peter Eisentraut
źródło
4

Opracowałem oprogramowanie, które umożliwia przekazywanie całego TCP i opcjonalnie UDP przez proxy SOCKS5, w całym systemie.

http://code.google.com/p/badvpn/wiki/tun2socks

Można go nawet zainstalować na routerze, aby przekazywać wszystkie połączenia z komputerów w sieci LAN.

Ambroz Bizjak
źródło
0

WIRTUALNE SIECI PRYWATNE W OPARCIU O SSH ssh zawiera obsługę tunelowania wirtualnej sieci prywatnej (VPN) za pomocą pseudo-urządzenia tun (4), umożliwiając bezpieczne połączenie dwóch sieci. Opcja konfiguracji sshd_config (5) PermitTunnel kontroluje, czy serwer to obsługuje i na jakim poziomie (ruch warstwy 2 lub 3).

 The following example would connect client network 10.0.50.0/24 with
 remote network 10.0.99.0/24 using a point-to-point connection from
 10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway
 to the remote network, at 192.168.1.15, allows it.

 On the client:

       # ssh -f -w 0:1 192.168.1.15 true
       # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
       # route add 10.0.99.0/24 10.1.1.2

 On the server:

       # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
       # route add 10.0.50.0/24 10.1.1.1

 Client access may be more finely tuned via the /root/.ssh/authorized_keys
 file (see below) and the PermitRootLogin server option.  The following
 entry would permit connections on tun(4) device 1 from user “jane” and on
 tun device 2 from user “john”, if PermitRootLogin is set to
 “forced-commands-only”:

   tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
   tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

 Since an SSH-based setup entails a fair amount of overhead, it may be
 more suited to temporary setups, such as for wireless VPNs.  More perma‐
 nent VPNs are better provided by tools such as ipsecctl(8) and
 isakmpd(8).
Kristian Hermansen
źródło
1
dodaj źródło informacji. Uwaga: to stare pytanie.
Lorenzo Von Matterhorn
-2

Chciałem tylko wyjaśnić, że (host portu ssh -D) nie jest w 100% bezpiecznym sposobem, aby ruch nie był wąchany. Dodanie (host-port blowfish ssh -D -c) byłoby lepszym wyborem, ponieważ co najmniej dodajesz szyfrowanie do swojej sesji. Możesz dodać więcej opcji, ale wystarczy wpisać „man ssh” w terminalu lub w Google, aby uzyskać pełną listę.

Myślę, że opcją, której szukasz, jest skonfigurowanie VPN (Virtual Private Network)

Przeczytaj ten artykuł, aby zrozumieć różnicę między nimi ( SSH vs. VPN ) lub dobrą podsumowaną wersją , zanim zaczniesz konfigurować własną sieć VPN. Jeśli zdecydujesz się na trasę VPN, polecam OpenVPN , jego darmową i dużą ilość dokumentacji i wsparcia.

Ricbax
źródło
6
zła rada. „Blowfish” to szyfr SSH-1; jest szybki, uważany za bezpieczny (od 1999: unixhelp.ed.ac.uk/CGI/man-cgi?ssh+1 ), ale nadal. prawdopodobnie chcesz ssh -2 -C -D [...](wymuś SSH2, użyj kompresji) i upuść -c. według mojego systemu man sshdomyślnie lista szyfrów w SSH2 to aes128-cbc,3des-cbc,blowfish-cbc,[etc]. Chodzi mi o to, że jeśli -c blowfishpoprosisz, możesz skończyć z SSH1, który jest znacznie mniej bezpieczny niż SSH2.
quack quixote
2
To prawda, ale Jeremy miał wrażenie, że połączenie jest bezpieczne tylko z -D 8080, po prostu stwierdziłem, że było lepsze niż to, czego używał. Podajesz słuszny punkt i dlatego wymieniam instrukcję, aby uzyskać więcej opcji.
ricbax
Może powinieneś zmienić swoją odpowiedź, ponieważ w innym przypadku jest to pomocne.
endolith
Zapomniałem, że o to pytałem, nie korzystaj z tej strony regularnie. Dzięki za wyjaśnienie ... Miałem wrażenie, że SSH jest domyślnie bezpieczny.
Jeremy Banks,
9
WTF nie jest domyślnie szyfrowany przez SSH?
LatinSuD
-3

Skorzystaj z tych przykładów:

  • Przekaż port 80 ze zdalnego hosta do 8888 na lokalnym hoście

    ssh -fnN -L8888: localhost: 80 użytkownik @ serwer

    Użyj tego, aby uzyskać dostęp do usług na zdalnym hoście, które są dostępne tylko tam

  • Przekaż port 80 z yourlocalhost do 8888 na zdalnym hoście

    ssh -fnN -R8888: localhost: 80 użytkownik @ serwer

    Użyj tego, aby zezwolić innym użytkownikom na dostęp do twoich usług: serwera WWW lub cokolwiek innego.

Twoje zdrowie! :)

kolypto
źródło
Dobry komentarz, ale wcale nie związany z tym, o czym tu mówimy. Odwrotne ssh pozwala SERWEROWI zażądać, aby KLIENT skierował JEDEN port ruchu do niego. Potrzebna byłaby większa konfiguracja, aby następnie skierować ten ruch do Internetu. Trzeba też skonfigurować tunel SSH dla każdego portu. I musi być inicjowane z serwera, a nie klienta - dlaczego miałbyś to robić, gdybyś nie musiał?
Beachhouse