evenkimi a dit :
Tu parles de vpn d'anonymisation, or tous les vpn commerciaux ne sont pas des vpn d'anonymisation, si ? J'ai du mal à voir comment une ip fixe peut-être compatible avec l'anonymat.
Non, tous les vpn commerciaux ne sont pas des vpn d'anonymisation. Mais les offres vpn classiques sont plutôt pour les pro. Ne pas confondre adresse ip publique fixe et anonymisation : les 2 sont bien compatibles à partir du moment où on ne peut pas savoir qui utilise l'adresse ip publique (c'est le cas des vpn d'anonymisation qui ne conservent (soi-disant) pas l'origine du vpn et qui font partager la même ip publique avec plusieurs utilisateurs).
evenkimi a dit :
2. Tous les port seront disponibles ? En fait je ne comprend pas pourquoi vous changez de port à chaque fois dans votre exemple.
Si je veux me co a une machine locale au port 1024 (au pif)
Je me co au serveur extérieur au port 1024 via une URL (mondomaine.com:1024)
Le serveur extérieur transmet au raspberry avec le port 1024
le raspberry transport ce qu'il recoit a la machine locale avec le port 1024
Dans votre exemple tous les ports sont différents. Y-a-t-il une raison ?
Est-ce que mon exemple marcherait ?
Dans quel exemple ? avec un reverse-ssh, on définit les ports qu'on veut router (par défaut, tous les autres ne le sont pas). Et ils sont fixes. Il faut bien faire la différence entre le port du serveur ssh de la machine "amie", les ports locaux qui seront reroutés par le client ssh, et les ports des machines qu'on souhaite atteindre sur le LAN.
Dans l'exemple que tu donnes, le port local sera rerouté via le port ssh du serveur extérieur (par défaut 22, mais c'est une bonne idée en terme de sécurité de le changer). Mais c'est ssh qui routera le port local vers le serveur distant ssh puis vers la mahcine sur le lan. Il y a bien 3 ports impliqués (local, serveur ssh, machine LAN). Ces ports peuvent être identiques, mais c'est une source de confusion (celui du serveur ssh est de préférence unique, alors que les autres peuvent concerner plusieurs redirections).
Pour répondre précisément à la question, oui, ça marchera, mais ce n'est pas forcément une bonne idée.
evenkimi a dit :
3. Est-ce que cette solution offre les même possibilité que ce qu'on peut faire avec un routeur ? Est-ce que je peux dire au serveur distant "envoie tout ce qui arrive sur les port 1024-50 000 sur le rasberrypi en ssh" ?
Ou est-ce qu'il faut dire au rasberry pi pour CHAQUE application, une part une, "ouvre un socket ssh avec le serveur distant sur tel port" avec 1 port = un socket ssh
Pas de plage de port possible ?
Non, le serveur ssh n'est pas un vrai routeur.
evenkimi a dit :
4. le raspberry sert juste a la mise en relation, ou tout le trafic va passer par lui ?
Le trafic passe par le serveur ssh, donc par le raspberry.
S'il y avait un moyen de court-circuiter le serveur ssh, on aurait pas besoin de faire tout ça.
