sshuttle - En ligne dans le Cloud

PROGRAMME:

Nom

sshuttle - documentation sur la navette

SYNOPSIS

navette [Options] [-r [nom d'utilisateur@]sshserver[:port]]sous-réseaux ...>

DESCRIPTION

navette vous permet de créer une connexion VPN depuis votre machine vers n'importe quel serveur distant qui
vous pouvez vous connecter via ssh, tant que ce serveur dispose de python 2.3 ou supérieur.

Pour travailler, vous devez avoir un accès root sur la machine locale, mais vous pouvez avoir un compte normal
sur le serveur.

C'est valable pour courir navette plusieurs fois simultanément sur une même machine cliente,
vous connecter à un serveur différent à chaque fois, vous pouvez donc être sur plusieurs VPN à la fois.

Si exécuté sur un routeur, navette peut transférer le trafic de l'ensemble de votre sous-réseau vers le VPN.

OPTIONS

sous-réseaux
Une liste de sous-réseaux à router sur le VPN, sous la forme abcd[/largeur]. Valide
les exemples sont 1.2.3.4 (une seule adresse IP), 1.2.3.4/32 (équivalent à 1.2.3.4),
1.2.3.0/24 (un sous-réseau 24 bits, c'est-à-dire avec un masque de réseau 255.255.255.0), et 0/0 ('juste
tout acheminer via le VPN').

-l, --listen=[ip:]port
Utilisez cette adresse IP et ce numéro de port comme port proxy transparent. Par défaut
navette trouve automatiquement un port disponible et écoute sur IP 127.0.0.1
(localhost), vous n'avez donc pas besoin de le remplacer et les connexions sont uniquement proxy
de la machine locale, pas des machines extérieures. Si vous voulez accepter
connexions à partir d'autres machines sur votre réseau (c'est-à-dire pour exécuter navette sur un routeur)
essayez d'activer le transfert IP dans votre noyau, puis utilisez --Ecoutez 0.0.0.0:0.

Pour la méthode tproxy, cela peut être une adresse IPv6. Utilisez cette option deux fois si
requis, pour fournir les adresses IPv4 et IPv6.

-H, --auto-hôtes
Recherchez les noms d'hôte distants et mettez à jour le / Etc / hosts fichier avec correspondance
entrées tant que le VPN est ouvert. C'est plus agréable que de changer votre système
DNS (/ Etc / resolv.conf), pour plusieurs raisons. Tout d'abord, les noms d'hôtes sont ajoutés
sans noms de domaine attachés, vous pouvez donc ssh ce serveur sans vous soucier si votre
le domaine local correspond au domaine distant. Deuxièmement, si vous navette en plus d'un
VPN à la fois, il est de toute façon impossible d'utiliser plus d'un serveur DNS à la fois, mais
navette fusionne correctement / Etc / hosts entrées entre toutes les copies en cours d'exécution. Troisièmement, si
vous ne routez que quelques sous-réseaux sur le VPN, vous préféreriez probablement garder
en utilisant votre serveur DNS local pour tout le reste.

-N, --auto-nets
En plus des sous-réseaux fournis sur la ligne de commande, demandez au serveur qui
sous-réseaux qu'il pense que nous devrions acheminer et les acheminer automatiquement. Les propositions
sont automatiquement extraits de la table de routage du serveur.

--DNS Capturez les requêtes DNS locales et transférez-les au serveur DNS distant.

--python
Spécifiez le nom/chemin de l'interpréteur python distant. La valeur par défaut est juste
python, ce qui signifie utiliser l'interpréteur python par défaut sur le système distant
CHEMIN.

-r, --remote=[nom d'utilisateur@]sshserver[:port]
Le nom d'hôte distant et le nom d'utilisateur facultatif et le numéro de port ssh à utiliser pour la connexion
au serveur distant. Par exemple, exemple.com, testuser@exemple.com,
testuser@exemple.com:2222, ou example.com:2244.

-X, --exclude=sous-réseau
Excluez explicitement ce sous-réseau du transfert. Le format de cette option est le
même que le option. Pour exclure plusieurs sous-réseaux, spécifiez le -x
option plus d'une fois. Vous pouvez dire quelque chose comme 0/0 -x 1.2.3.0/24 à transmettre
tout sauf le sous-réseau local sur le VPN, par exemple.

-X, --exclude-from=fichier
Excluez les sous-réseaux spécifiés dans un fichier, un sous-réseau par ligne. Utile quand on a
beaucoup de sous-réseaux à exclure.

-dans, --verbeux
Imprimez plus d'informations sur la session. Cette option peut être utilisée plusieurs fois
pour une verbosité accrue. Par défaut, navette imprime uniquement les messages d'erreur.

-e, --ssh-cmd
La commande à utiliser pour se connecter au serveur distant. La valeur par défaut est juste ssh. utilisation
ceci si votre client ssh se trouve dans un emplacement non standard ou si vous souhaitez fournir des informations supplémentaires
options à la commande ssh, par exemple, -e 'chut -v'.

--hôtes-semences
Une liste de noms d'hôtes séparés par des virgules à utiliser pour initialiser le --auto-hôtes balayage
algorithme. --auto-hôtes fait des choses comme interroger les serveurs SMB locaux pour les listes de
hostnames, mais peut accélérer les choses si vous utilisez cette option pour lui donner quelques noms à
commencer à partir de.

--pas de contrôle de latence
Sacrifiez la latence pour améliorer les références de bande passante. ssh utilise un très gros socket
tampons, qui peuvent surcharger la connexion si vous commencez à faire des transferts de fichiers volumineux,
rendant ainsi toutes vos autres sessions à l'intérieur du même tunnel lentes. Normalement,
navette essaie d'éviter ce problème en utilisant un « contrôle d'intégralité » qui n'autorise qu'un
certaine quantité de données en attente à mettre en mémoire tampon à la fois. Mais en haut débit
liens, cela peut laisser une grande partie de votre bande passante sous-utilisée. Cela fait aussi
navette semblent lents dans les benchmarks de bande passante (les benchmarks testent rarement la latence du ping,
lequel est quoi navette essaie de contrôler). Cette option désactive la latence
fonction de contrôle, maximisant l'utilisation de la bande passante. À utiliser à vos risques et périls.

-RÉ, --démon
Passez automatiquement à l'arrière-plan après la connexion au serveur distant.
Implique --syslog.

--syslog
après la connexion, envoyez tous les messages de journal au syslog(3) service au lieu de stderr.
Ceci est implicite si vous utilisez --démon.

--pidfile=nomfichier pid
lors de l'utilisation --démon, enregistrer navetteest pid à nomfichier pid. La valeur par défaut est
navette.pid dans le répertoire courant.

--disable-ipv6
Si vous utilisez la méthode tproxy, cela désactivera la prise en charge d'IPv6.

--pare-feu
(usage interne uniquement) exécutez le gestionnaire de pare-feu. C'est la seule partie de navette
qui doit s'exécuter en tant que root. Si vous commencez navette en tant qu'utilisateur non root, il
exécuter automatiquement sudo or su pour démarrer le gestionnaire de pare-feu, mais le cœur de
navette fonctionne toujours en tant qu'utilisateur normal.

--hostwatch
(usage interne uniquement) exécutez le démon hostwatch. Ce processus s'exécute côté serveur
et collecte les noms d'hôtes pour le --auto-hôtes option. Utiliser cette option seule
facilite grandement le débogage et le test du --auto-hôtes fonction.

EXEMPLES

Testez localement en proxy toutes les connexions locales, sans utiliser ssh :

$ navette -v 0/0

Démarrage du proxy de navette.
Écoute activée ('0.0.0.0', 12300).
[local sudo] Mot de passe :
gestionnaire de pare-feu prêt.
c : connexion au serveur...
s : itinéraires disponibles :
s : 192.168.42.0 24/XNUMX XNUMX
c : connecté.
gestionnaire de pare-feu : démarrage de transproxy.
c : Accepter : 192.168.42.106:50035 -> 192.168.42.121:139.
c : Accepter : 192.168.42.121:47523 -> 77.141.99.22:443.
...etc...
^C
gestionnaire de pare-feu : annuler les modifications.
ClavierInterruption
c : Interruption clavier : sortie.
c : SW#8:192.168.42.121:47523 : suppression
c : SW#6:192.168.42.106:50035 : suppression

Testez la connexion à un serveur distant, avec recherche automatique du nom d'hôte et du sous-réseau :

$ sshuttle -vNHr exemple.org

Démarrage du proxy de navette.
Écoute activée ('0.0.0.0', 12300).
gestionnaire de pare-feu prêt.
c : connexion au serveur...
s : itinéraires disponibles :
s : 77.141.99.0 24/XNUMX XNUMX
c : connecté.
c : seed_hosts : []
gestionnaire de pare-feu : démarrage de transproxy.
hostwatch : Trouvé : testbox1 : 1.2.3.4
hostwatch : Trouvé : mytest2 : 5.6.7.8
hostwatch : Trouvé : domaincontroller : 99.1.2.3
c : Accepter : 192.168.42.121:60554 -> 77.141.99.22:22.
^C
gestionnaire de pare-feu : annuler les modifications.
c : Interruption clavier : sortie.
c : SW#6:192.168.42.121:60554 : suppression

DISCUSSION

Quand ça démarre, navette crée une session ssh sur le serveur spécifié par le -r option.
If -r est omis, il démarrera à la fois son client et son serveur localement, ce qui est parfois
utile pour les tests.

Après vous être connecté au serveur distant, navette télécharge son code source (python) dans le
l'extrémité distante et l'exécute là-bas. Ainsi, vous n'avez pas besoin d'installer navette sur la télécommande
serveur, et il n'y a jamais navette conflits de version entre le client et le serveur.

Contrairement à la plupart des VPN, navette transfère les sessions, pas les paquets. C'est-à-dire qu'il utilise le noyau
proxy transparent (iptables RÉORIENTER règles sous Linux) pour capturer les sessions TCP sortantes,
crée ensuite des sessions TCP entièrement séparées vers la destination d'origine à l'autre
bout du tunnel.

Le transfert au niveau des paquets (par exemple, en utilisant les périphériques tun/tap sous Linux) semble élégant au début,
mais il en résulte plusieurs problèmes, notamment le problème 'tcp over tcp'. Le protocole TCP
dépend fondamentalement des paquets abandonnés afin de mettre en œuvre sa congestion
algorithme de contrôle ; si vous transmettez des paquets tcp à travers un tunnel basé sur tcp (tel que ssh), le
les paquets tcp internes ne seront jamais abandonnés, et donc le contrôle de congestion du flux tcp interne
sera complètement cassé et les performances seront terribles. Ainsi, les VPN basés sur des paquets
(comme IPsec et openvpn) ne peut pas utiliser de flux chiffrés basés sur TCP comme ssh ou ssl, et
doivent implémenter leur propre cryptage à partir de zéro, ce qui est très complexe et erreur
enclin.

navettela simplicité de s vient du fait qu'il peut utiliser en toute sécurité le ssh existant
tunnel crypté sans encourir de pénalité de performance. Il le fait en laissant le
le noyau côté client gère le flux TCP entrant et le noyau côté serveur gère le
flux TCP sortant ; il n'est pas nécessaire que le contrôle de congestion soit partagé entre les deux
des flux séparés, donc un tunnel basé sur TCP convient.

Utiliser sshuttle en ligne à l'aide des services onworks.net