Encore une situation qui ravira ceux pour qui l'administration réseau est innée !
Voici le problème :
Je souhaite me connecter depuis le poste A au poste B, par ssh/vnc/ms-rd en utilisant ma console ou un logiciel type Connexions de GNOME.
Le poste A est une Debian classique connectée au réseau de manière classique avec une box internet et un proxy exclusif. Pas trop de problème de ce côté-là.
EDIT : je précise que le poste A ne peux accepter de connexions entrantes type ssh à cause du proxy très restrictif sur lequel je n'ai pas la main.
Le poste B est l'ordi portable d'un ami, équipé de Linux Mint, qui se connecte à internet en partageant la connexion de son ordiphone.
Que faut-il faire pour pouvoir me connecter directement au post B depuis le poste A ?
De ce que j'ai compris, il faudrait :
- Activer/autoriser les connexions à distance (facile)
- Trouver l'adresse IP de l'ordiphone et faire en sorte qu'elle reste fixe (heu…?)
- Rediriger les connexions à un port correspondant au post B vers ce poste, qui aura donc toujours la même adresse IP sur son réseau (…???)
J'ai très peu d'informations utiles pour le moment, j'essayerais d'en obtenir plus dès que possible.
Si vous avez des pistes de procédures à suivre, je suis preneur.
# Ce que j'avais fait à une époque .....
Posté par totof2000 . Évalué à 5.
Le besoin était de pouvoir se connecter sur le PC de l'utilisateur B pour pouvoir l'assister dans l'utilisation/administration de son ordinateur (mise à jour du système, des antivirus, aide à l'installation d'outils, accompagnement à l'utilisation … Le prérequis était bien sûr d'avoir un PC avec une connection réseau opérationnelle.
L'utilisateur du poste B avait un compte sur mon poste A, et pouvait s'y connecter en ssh via NAT. Lorsqu'il avait besoin que je me connecte sur sa machine, il ouvrait un tunnel ssh, que je pouvais utiliser pour accéder à son poste en session VNC il me semble (c'était des machines windows à l'époque).
Avantages pour l'utilisateur du poste B :
- je ne pouvais pas me connecter à son insu : le tunnel ssh était activé à son initiative.
- Le problème d'IP fixe n'était plus le sien mais le mien (et comme j'étais chez Free, j'avais une IP fixe).
L'inconvénient était que j'avais du scripter le truc pour que la personne se connecte depuis sa session windows en ssh (je lui avais fait utiliser putty), et faire en sorte que VNC ne tourne pas en permanence (pour éviter que n'importe qui n'établisse une connection) mais soit exécuté à la demande. Mais ça se configure une fois et ensuite on n'en parle plus …
[^] # Re: Ce que j'avais fait à une époque .....
Posté par alberic89 🐧 . Évalué à 3.
C'est en effet une très bonne piste, mais je ne pourrais pas l'utiliser. En effet, je n'ai pas la main sur le proxy et la box derrière lesquels je suis, et l'administrateur est très très très frileux sur l'ouverture des ports.
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: Ce que j'avais fait à une époque .....
Posté par totof2000 . Évalué à 3.
Dans ce cas je pense qu'il sera nécessaire de passer par un outil tiers qui assurera la liaison. Voir le post plus bas.
[^] # Re: Ce que j'avais fait à une époque .....
Posté par chimrod (site web personnel) . Évalué à 2.
Si A peut se connecter à B, tu peux dans ce cas ouvrir une connexion ssh avec reverse proxy. Cela permet de réutiliser la connexion ouvrir une connexion de B vers A, qui servira de tunnel pour VNC.
[^] # Re: Ce que j'avais fait à une époque .....
Posté par totof2000 . Évalué à 2.
Si j'ai bien compris l'énoncé, B se trouve sur un pc portable et utilise un téléphone mobile comme point d'accès à Internet
[^] # Re: Ce que j'avais fait à une époque .....
Posté par chimrod (site web personnel) . Évalué à 2.
J’ai inversé les lettres, au temps pour moi. Mais le principe reste le meme, tu utilises la connexion établie via le pc pouvant sortir du réseau pour remonter le courant et se connecter à rebours.
[^] # Re: Ce que j'avais fait à une époque .....
Posté par ChocolatineFlying . Évalué à 2.
le nom officiel serait plutôt : reverse ssh
celui qui est plus libre de faire ce qu'il veut reçois la connexion ssh, puis il "remonte" par la connexion existante.
https://doc.ubuntu-fr.org/tutoriel/reverse_ssh
le pb ici serais que le plus libre de sa configuration passe par une connexion un peu foireuse 4G de sfr par exemple ou ça devient impossible de se connecter en direct.
reste la solution de se connecter chacun a un serveur VPS chez ovh en ssh et à partir de là remonté la connexion dans le sens que vous voulez. Cela se fait très bien en une seule ligne de commande longue avec ssh
mais il faut payer un serveur quelques part, ou trouver une connexion fibre perso avec un rpi dédié.
# un outil tiers
Posté par NeoX . Évalué à 4.
un outil tiers,
cas 1) chacun se connecte à l'outil (donc connexion sortante pour chacun), et l'outil met les deux machines en relation ( nomachine il me semble le ferait)
cas 2)
[^] # Re: un outil tiers
Posté par alberic89 🐧 . Évalué à 1.
Le cas 1 me semble une très bonne idée, je note.
Ne serait-il pas possible, si on voulait pousser le bouchon un peu plus loin, d'imaginer qu'on héberge un service libre semblable à NoMachine chez un Chaton ou autre hébergeur dans ce style ? Je vais chercher.
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: un outil tiers
Posté par alberic89 🐧 . Évalué à 3.
Auto-réponse : Apache Guacamole semble pouvoir fournir un service semblable, à explorer plus en détail.
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: un outil tiers
Posté par dr191 . Évalué à 2. Dernière modification le 23 novembre 2023 à 12:07.
salut,
je ne vois pas ce qui peut marcher en dehors de l'option 1:
PC A non joignable depuis l'extérieur
PC B probablement derrière un CGNAT
Il faut un intermédiaire joignable depuis internet pour faire le lien entre les 2 machines.
Typiquement, un serveur vpn auqel se connecteront les 2 machines.
Possible que le proxy du réseau A soit très rigide et ne laisse pas passer autre chose que du http/https. En général, on arrive quand meme à faire passer du vpn ou du ssh sur le port 443. Mais dans ce cas, vérifiez que vous avez les autorisations pour faire ce montage dans le réseau A sinon vous allez vous faire rattraper par la patrouille.
# Script sur B
Posté par bertile . Évalué à 2. Dernière modification le 22 novembre 2023 à 20:56.
Bonjour,
Pour un problème similaire, mais le poste B était sous Windows, j'avais créé un script bat.
L'idée du script (sur le poste B) était :
Sur le poste A, lancement d'un client VNC avec l'ip reçu par courriel.
Dans les faits l'utilisateur lançait le script depuis un raccourcis sur son poste et m'envoyer un SMS pour me demander de me connecter. Pour le courriel, j'avais crée une adresse dédiée (pour l'envoi) à cet usage uniquement.
# Tmate peut-être ou Rustdesk ?
Posté par xandercagexxx . Évalué à 4. Dernière modification le 22 novembre 2023 à 22:58.
Je pense que l'utilisation de tmate te permettrait d'agir sur la machine distante.
Mais si c'est plus large comme besoin, tu peux utiliser rustdesk aussi (équivalent de TeamViewer mais opencore).
Les 2 sont auto-hébergeable donc tu peux tout gérer toi même.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.