j’avoue que je suis perdu et que je ne sais plus trop où chercher, je n’ai pas trouvé (ou mal cherché peut-être) de solutions à mon souci.
J’utilise en LAN un raspberry pi 4, peu importe ce qu’il contient finalement mais j’y accède seulement en ssh.
depuis le LAN, aucun souci. pareil pour le ping.
J’ai voulu aujourd’hui tester via le VPN Wireguard et il m’est impossible de faire un ping ou un accès ssh vers mon Pi (test via IP et hostname).
J’ai pensé à une règle de routage mais j’accède sans problème à d’autres équipement (par exemple une prise connectée flashée sur Tasmota : ping OK et accès web ok). On oublie donc l’histoire de routage, aucune raison pour que la freebox empêche d’aller sur mon LAN en .10 et accepte que j’aille en .90.
le Pi est en IP fixe (résa dhcp), pas de firewall a priori (le service iptable ne tourne pas, j’ai quand même flush les règles par précaution, j’ai même essayé d’en ajouter pour autoriser le réseau proposé par Wireguard.
Bref, je suis perdu…
est-ce que l’un de vous est parvenu par hasard à accéder à un raspberry dans une configuration similaire ? (je n’ai pas forcément envie d’ouvrir à l’extérieur mais de pouvoir me connecter si besoin en ssh via mon VPN)
Si tu utilise un VPN, tu n’est plus sur ton réseau, alors normal que tu ping pas ton RPi (ni aucun autre appareil de ton réseau). Il faut que tu sorte de ton VPN pour atteindre ton réseau local.
Si tu veux accéder depuis ton VPN (un VPN est un truc qui est inutile dans 99% des usages du monde lambda), il faut que le RPi soit accessible depuis Internet, ou est la sortie du VPN. Alors faut configurer ton routeur pour redirectionner un port vers le SSH de ton RPi, qui lui doit avoir un IP statique sur ton réseau local.
Je ne veux pas être insultant, mais si tu utilise un VPN et tu n’as pas compris ce principe AVANT au sujet de ton RPi, tu fais partie alors du monde qui utilise un VPN pour rien. Vire moi ton VPN et simplifie toi la vie… mais si tu as un usage spécifique pour le VPN, alors renseigne toi sur ce qu’est un VPN.
J’allais répondre à corly, mais tu à tout résumé levelKro…
Personnellement derrière un routeur mes pi ne sont accessible qu’avec anydesk
chaque pi paramétré avec un mdp et un pseudo pour s’ouvrir automatiquement.
j’ai rien trouvé de mieux pour du lan de l’extérieur.
Ce qui me permet de démarrer mes serveurs en wol dans une crontab à partir d’un pi.
je vous remercie pour vos réponses mais malheureusement j’ai l’impression que ma question n’a pas été bien comprise.
Tout d’abord, même si à la première réponse de levelKro j’ai eu un sentiment de condescendance, je pense que j’ai juste lu cela trop vite puisqu’il doit s’agir plutôt de bienveillance et je pense que je ne me suis pas assez clairement exprimé.
Je suis admin systèmes et réseaux de métier, je pense donc comprendre tout à fait ce qu’est un VPN.
L’idée principale dans mon cas d’utiliser un VPN est que je souhaite apporter un peu de sécurité et ne pas ouvrir l’accès à mon SSH (même via un port custom, une redirection en passant par l’ip publique de ma box,…) en utilisant un tunnel sécurisé pour me connecter aux équipements de mon réseau interne.
Concernant l’idée de tempsx92, j’utilise la version sans interface graphique et je ne me connecte donc à mon pi qu’en SSH (après je pourrais en effet faire un anydesk sur un équipement de rebond mais ce n’est pas le fonctionnement que je recherche)
Pour en revenir à mon interrogation, et c’est là où je suis perdu, c’est que lorsque je suis connecté en VPN, comme je l’ai indiqué, d’autres équipements de mon LAN sont accessibles sans problèmes et répondent au ping. (@levelKro, c’est là où j’ai compris que je m’étais probablement exprimé lorsque tu me réponds :
Si tu utilise un VPN, tu n’est plus sur ton réseau, alors normal que tu ping pas ton RPi (ni aucun autre appareil de ton réseau). Il faut que tu sorte de ton VPN pour atteindre ton réseau local.
)
Je ne vais pas reprendre tous les point mais si tu relis mon post :
OUI mon Pi est en IP fixe
un VPN ne sert pas qu’à utiliser l’ip publique de son réseau en sortie, convenablement configuré avec les règles de routage adéquates permet de se connecter à son LAN et aux équipement internes (comme en entreprise)
je ne m’explique simplement pas pourquoi seul le Pi ne réponds pas.
C’est pour cela que j’excluais un souci de configuration de Wireguard (qui est configuré pour n’autoriser qu’un équipement spécifique à se connecter à mon LAN) et que je venais voir si des personnes plus compétentes que moi en conf Pi avaient des idées de diagnostiques parce que c’est bien quelque chose que j’ai du mal à comprendre, ou du moins j’ai bien l’impression de comprendre que le réseau attribué par mon pi est différent de mon LAN, et même si lui permet de contacter le LAN il doit y avoir quelque part sur mon pi quelque chose qui bloque. Je ne trouve pas où.
Comme je l’ai indiqué, je n’ai pas configuré de firewall mais je ne suis pas un expert en Pi, je ne sais plus trop où chercher.
Pour le moment bien entendu j’ai fait une règle pour ouvrir depuis l’extérieur, n’étant pas chez moi c’est quand même le plus simple, mais pas le plus sécure (je pense que vous êtes assez calés pour ne pas avoir à vous expliquer) et j’aimerai pouvoir fonctionner comme initialement indiqué.
Merci pour vos réponses, si vous avez des idées de diag (orientées Pi) je suis preneur.
J’ai une dent contre les VPN car je regarde beaucoup de vidéo et Nord VPN vend un produit avec des affirmations pas tout à fait exacte et parfois trompeur. Et je remarque que plusieurs pense qu’un VPN sécurise et camouffle à 100% ton usage d’internet, ce qui est totalement faux. Je rappel que je suis Québécois et peut-être que mes tournures de phrases sont « dérangeantes ». Mais si je ne chercherais pas a t’aider, je ne répondrais tout simplement pas.
En effet, quand on parle de VPN tout de suite c’est pour Internet, mais si tu te crée un réseau VPN local (ce que je trouve totalement absurde) c’est autre chose. Quand tu di rejoindre les autres, est-ce sur le même service (SSH) ?
(Je suis direct, désolé, mais je suis surpris…)
Alors pourquoi as tu un problème? Tu as la formation requise pour régler ça de toi même, non ? J’ai aucune étude en informatique, seulement 26 ans d’apprentissage « sur le tas ». Mais d’un autre côté, j’ai des amis TI à qui je monte leur réseau, faute de formation sur l’équipement « lambda ». Mais tu as le droit de demander de l’aide, juste que je trouve drôle qu’un I Admin Sys est ce genre de question. (mais tu est étrangement pas le premier TI qui semble en « connaitre moins » que le poste requis, je m’attend plus a des questions beaucoup plus technique)
SI tu as défini le IP sur le RPi directement, vire le et configurer via le DHCP, laisse ton RPi en mode « par défaut » et es problèmes réseaux seront plus simple a analyser, car il sera sur une config « generaliste ». Le RPi n’a rien de spécial au niveau réseau, il réagis comme tout système linux.
Cela dit, … si ton ensemble de réseau répond et pas le PI, … as tu essayer de valider cette information avec d’autres appareils du même réseau local ?
As-tu essayé de changer de port sur ton équipement réseau ? Es-tu en filaire ou Wifi ? Si en Wifi, marche tu en filaire, et vice-versa ?
Est-ce que tu t’identifie sur ton RPi via un host ou un user/pass pour le SSH ?
As-tu un appareil connecté sur le même « hub/routeur/gateway » que ton Pi ?
Qui gère l’allocation d’IP ? Qui est le DHCP ? Ton RPi a tu un ip libre défini par le routeur (ce que je conseille) ou tu défini de manière dur le IP dans le RPi ? (ce que je déconseille)
Définir un IP static dans un appareil peut mener à des problèmes… et la je parle de ce que j’ai vu. Si le IP désiré est non autorisé par le gestionnaire, alors l’appareil aura une connexion limité. Le problème est que souvent l’appareil indiquera le IP (mais qui est configuré dans ce dernier) et n’indiquera pas que le lien n’est pas « complet ». Ce qui peut laisser croire que l’appareil est connecté adéquatement au réseau, mais en fait n’en fait pas partie. Ce refus peut être une différence dans le Mac Addr. ou parce que le IP est déja alloué sur le réseau. Il peu également exister d’autre motifs, selon la solidité du gestionnaire.
As-tu tenté un Traceroute ?
Peut-être une partie de ton réseau est isolé pour des raisons matériel autre que le PI et le VPN ?
As tu tenté d’utiliser un autre port que le 22 pour le SSH ? Ou as tu (et réussi) à utiliser un SSH sur un autre appareil ? Ou je veux en venir c’est … ton VPN redirige ou bloc peut-être le port 22…
Ces questions sont les choses que j’examinerais avant de chercher de l’aide, j’espère que tu as déjà fait ces exercices, sinon je crois tu peux t’en servir comme base pour analyser la situation.
Moi perso, je touche pas au VPN et j’ai jamais eu à n’en configurer, trouvant l’idée d’en utiliser un ridicule pour les inconvénient que ça apporte, et j’ai rien à cacher. La sécurité est bonne car je monitoring mon réseau autrement et filtre les entrées aussi d’une autre manière. Le choix de mes ports vers l’extérieur ne laisse pas deviner l’usage (je n’utilise pas 2222 au lieu de 22 pour le SSH par exemple). EN fait seul mes services ayant besoin d’un accès extérieur son « ouvert » sur le routeur, le reste, je me sert de mon PC comme passerelle pour y accéder, SI j’ai besoin de le faire depuis l’extérieur.
Alors configurer un VPN et gérer les « caprices » de ce dernier, je ne peu rien dire d’exacte, il est possible de gérer plus d’un réseau, mais avec de bonnes configuration Windows/Linux et au mieux d’aller au plus simple. Si tu à configurer un VPN en local uniquement, je vois mal, en effet, pourquoi il ne répond pas.
Mon avis sur les VPN.
Comme dit plus tot, je n’ai jamais utilisé de VPN, mais connaissances sont des lecture généraliste sur le sujet, de source fiable et vérifier. C’est de la que je conclut que les VPN vendu, comme via Nord VPN, sont distribué comme un produit miracle qu’y en n’ai pas un. Je prend Nord VPN comme référence (connu) mais c’est le même principe pour tout VPN Internet.
Un VPN permet de sécuriser la connexion entre toi et l’extérieur (Internet) ou un réseau privé sécurisé (toi qui contact le VPN qui donne accès au réseau qu’il partage).
Changement de région
Ce n’est pas faux, mais faut savoir que rien n’empêche de bloquer des range ou un seul adresse IP pour les services, par exemple Netflix pourrait bloquer les IPs associés à Nord VPN pour éviter le changement de région. Si quelqu’un commet un crime avec un IP d’un VPN, tout les utilisateurs qui partagerons cette IP seront visé par l’enquête (si il y a). Je parle de partage de IP car je sais que les IPv4 sont pas mal rare et coûteux, et ça m’étonnerais qui alloue 1 ip pour 1 client, surtout si ce dernier peut changer de région.
Sécurisation des informations
La connexion entre le client et le VPN peut être en effet sécurisé, mais tout accès extérieur peut ne pas l’être. L’anonymat ce résume plus au fait de la source du client (IP/Région) réel est masqué par celui du VPN. Mais reste que tout fournisseur de service de ce style doit répondre aux demandes des autorité, soit une date précise pour un IP, e que le fournisseur de service va souvent donner la liste des clients ayant utiliser cette adresse à ce moment, question de ce protéger. Alors il est faux de penser que l’anonymat es totale. Et si un « mouchard » est sur le PC client, ou sur le service cible, rien n’empêche la collecte d’informations par un pirate (SSL non sécurisé ou avec la clé dévoilé, comme pour Symantec voila quelques années). Des applications mal configuré peut divulguer les informations du client. (uTorrent par exemple)
Rapidité
Une chose que le monde oublie, est que le fait d’utiliser un VPN fait en sorte que le débit est géré par ce dernier. Pour maintenir un débit haut sur un VPN, avec nos connexion déjà haut débit, est très exigent. Si le IP es partagé, alors la connexion l’est surement. En espérant que dans mon exemple, Nord VPN gère des connexions à plusieurs Gbps. Le téléchargement P2P (Torrent par exemple) peut affecter d’autres clients, écouter un film Netflix peut aussi charger la connexion. Quelques clients, l’impact ne ce feras pas sentir, mais si tout les client VPN décide de faire de gros transfert, la, la connexion est ressentie.
De la mon dégout pour les VPN, car le produit annoncé ne respecte pas vraiment ce que le monde en comprennent. Les VPN sont pratique pour par exemple les entreprises de commerce au détail ou les prix sont gérer de manière centrale. Il est moins coûteux d’utiliser internet (que d’installer la fibre) pour relier la boutique au siège sociale par exemple, et permet de sécuriser ce lien, c’est comme étendre le réseau de ta maison chez les membres de la famille. Ce qui fait que les membres peuvent contacter ton réseau local et ce dans la discrétion.
Bonjour @levelKro, je te remercie pour la réponse détaillée.
Désolé pour le temps de réponse, j’ai assez peu de temps en ce moment.
Pour commencer : Non, ce n’est pas parce qu’on est admins sys / réseaux que l’on connait tout.
j’ai eu très peu de configuration de VPN à faire, et j’ai très peu travaillé sur Linux (et j’ai également pas mal travaillé en équipe avec un périmètre technique restreint).
comme toute chose, moins tu pratiques, plus vite tu « oublies ».
Je n’apporte pas de questions plus « techniques » également parce que c’est une question qui était plutôt généraliste, à savoir est-ce que quelqu’un avait déjà été dans ce cas.
En effet, mon VPN ne me sert pas à me « protéger », ou à me « cacher » (j’ai le même avis que toi sur le sujet NordVPN et la publicité (mensongère) qu’ils en font) mais bien à me connecter à mon LAN depuis n’importe où. (et même pas pour utiliser l’iP de mon domicile en sortie…)
Pour répondre un peu en vrac :
je gère mon dhcp depuis mon routeur
je ne fais jamais d’IP statique, seulement des réservations
j’ai plusieurs équipements connectés sur le même LAN (je n’ai pas vu l’intérêt de gérer des vlans en interne, même si j’avoue y avoir pensé concernant la partie IOT
je n’ai pas d’autres équipement accessibles en ssh, il faudra que j’allume mon pi de dev pour tester, mais je penche aussi pour la probabilité que cela soit bloqué par le VPN (ce que je trouve inutile du coup) ou je n’ai pas trouvé le moyen de le gérer encore…
je le rappelle, c’est la première fois que je gère Wireguard, qui plus est pluggé directement sur la box (d’où la question de savoir si quelqu’un avait déjà testé cette configuration)
Pour le moment, j’ai également routé le port SSH vers un port custom qui n’indique en rien son service.
En conclusion, je n’ai rien trouvé d’anormal dans la conf du Pi, à voir si le fonctionnement est identique avec une config neuve sur mon pi de dev ce qui validerait que cela vient du VPN.
je regarderai cela lorsque j’aurai plus de temps.
et si quelqu’un a bien sûr testé cette configuration et est parvenu à se connecter en ssh à son pi, je veux bien comprendre ce qui bloque. (mais pour être honnête, je n’ai pas envie de sniffer des paquets ou de pousser l’analyse à la maison, c’est probablement nul mais la flemme lorsque tu fais ça la journée déjà )
Moi je vais arrêter la mon aide, car la configuration semble trop nébuleuse et chaotique pour moi. N’utilisant pas de VPN de toute façons, je ne serais pas d’une grande aide.
Si le RPi est en effet visible dans une situation, mais pas dans l’autre, faut voir avec ce que tu as modifié, ici le VPN qui est ajouté. Il semble que c’est que lui qui cause tout tes ennuis.
Petit flash qui mes venu, as tu tenté de contacter depuis le RPi vers le PC dans le contexte problématique ?
Le problème est peut-être que le RPi reçois la demande du PC sur le VPN, mais il est incapable de correctement répondre car le « routage » (traceroute) lui fait défaut (mauvais IP fournir et retour de passerelle).
En « image ».
Ton PC contact le RPi en passant par le VPN, qui lui est fournis par un device du réseau.
Le RPi reçois la demande, et doit retourner une réponse. La ici il peut avoir plusieurs pensés.
Le RPI répond via le réseau standard, il passe donc en passerelle Internet (routeur) que par le chemin du VPN.
Le RPi reçois un IP du réseau, et lui répond sans tenir compte de d’autres paramètres qui permet de communiquer correctement le retour vers le bon expéditeur. Le « device » ne traite pas le retour pour le VPN mais pour lui.
Le RPi répond, mais il n’a pas les bonnes informations technique; certificat de sécurité, protocole, méthode de réponse , etc…
Bon, c’est l’idée brouillon qui met venu. Il peut contenir des non-lieu du à la config du réseau que tu as.
Ton VPN est installé ou ? Su un PC/RPi dédié autre que les appareils concerné dans ce problème ou non. Car si je comprend bien ta config, c’est celle utiliser en entreprise; Tu veux accéder en VPN à ton réseau à la maison de manière sécurisé.
Alors c’est soit le routeur, soit un appareil de ton réseau qui fait office de porte d’entrée sécurisé. Si ce n’est pas le routeur, c’est peut-être la le problème, un imbriquement de deux réseaux dont le RPi ne sait que géré l’un, le principal. Ou que l’appareil qui gère le VPN est mal configuré pour ce type d’accès. (solution envisagé plus tot, et qui est fort plausiable)
Tout comme le « low ID » et « high ID » dans les logiciels P2P ou le mode « passif/actif » sur un FTP, c’est la qualité du lien établie. Ce problème existe avec toutes demande P2P.
Par exemple, avec les DCC sous IRC (système de transfert direct, tout comme les autres nommé avant), il n’était pas possible de le faire si le port de réception (59 dans l’exemple) n’est pas défini de manière direct pour l’adresse internet. Il fallait alors que soit;
L’utilisateur crée la connexion depuis le PC ou il est, à fin que l’adresse IP internet soit celle du PC, bref, il n’est pas sur un réseau local avant d’atteindre Internet,
L’utilisateur défini le port 59 du routeur pour le diriger vers le PC avec un IP défini sur le même port (ou un autre si c’est un masque de port)
Je n’ai pas de formation en réseau, ce qui suit est ma propre interprétation des systèmes, alors il peut y avoir des erreurs. C’est le résultat de tests vécu. En pratique, j’ai jamais eu a manipuler le NAT. À contre vérifier alors
C’est que dans certains protocoles, la définition ne passe pas par le NAT car il est défini en port dur. En simple, sur un mode passif, ce qui est d’usage, le client (toi) contacte un serveur (sur internet) sur un port que ce serveur écoute. Tu l’informe au passage que les réponses seront sur un port donné, fournis par le NAT.
Dans mon exemple avec le DCC de IRC, il est défini sur le port 59 pour le destinataire et le client ouvre un port en écoute que sur ce port, en attente de connexion. Il peut être changé, mais ne peut pas être fournis et modifié sur demande pour chaque connexion.
Ce qui fait que sans les modifications adéquate, l’accès était dur. Ce problème existe avec les vieux protocole, et des logiciels soit trop sécurisé, soit mal ajusté pour l’usage demandé.
Par exemple, le FTP est en mode passif, avec un client comme Filezilla, ont voit les messages, dont celui du port de retour des communications. Si je passe en mode actif, la connexion est problématique sur un routeur, si ce dernier ne gère pas ou de mauvaise façon le NAT. C’est que le retour en direct requière que les informations ne soit pas remanipulé, car non fait dans ce sens.
Les connexion direct (par défaut) requière une réponse sur le même port que par celui la demande est initié.
Alors est-ce que le VPN arrive a faire un bon travail de gestion des appels, via un NAT ou un routage adéquat ?
Wireguard est axé sur la gestion de multi-machines, sont mécanisme ce base sur le UDP. Je ne sais pas si c’est une norme des VPN, mais elle me fait également penser à la gestion adéquat de la forme des packet. J’dis ça… j’dis rien aussi.
Bon j’avais dit que je ne t’aiderais plus, c’est que je me sens un peu limité sur ma capacité à le faire sans avoir l’ensemble du réseau et configuration en vu. Mais ton problème est le VPN en lui-même de mon avis (et du tient). Ce qui faut regarder est;
Les modes et support possible (NAT…)
La sécurité en générale (port, certificats, limitation)
Hello @levelKro, je te remercie pour te pencher sur le sujet à nouveau mais le problème est « résolu ».
si je le mets entre guillemets c’est que je n’ai pas réussi à trouver la véritable source du problème… je pense que j’avais un peu trop testé de truc sur ce Pi et qu’à un moment il a du se passer quelque chose (désolé de ne pas être plus précis, j’ai vraiment essayé de trouver quoi mais… le système linux est encore très vaste pour moi)
j’avais du temps hier, j’ai donc essayé de résoudre ce souci d’abord, puis j’ai baissé les bras.
j’ai donc testé sur mon Pi de Dev, avec une image neuve et cela fonctionnait (image propre, rien d’installé si ce n’est raspbian en arm64)
J’avais également d’autres petits soucis avec Docker suite à l’abandon du armhf. j’ai donc décidé de repartir sur une version en arm64 sur mon Pi de prod.
Nouvelle image, reconfiguration de mes containers à l’identique et récupération de mes données (facile lorsque tu utilises un disque pour le système et un disque pour les datas)… Une fois que j’ai eu la certitude que tout était fonctionnel, et avant de ranger le disque système en armhf, j’ai vérifié le comportement VPN via la connexion partagé 4G… et ô miracle, tout fonctionne comme ça devrait.
J’ai réessayé ce jour depuis le boulot et je confirme que tout fonctionne.
je n’ai rien changé au niveau du routeur / VPN, le problème provenait donc bien d’une conf de mon pi… j’aurai aimé comprendre quoi parce que finalement je ne fait pas évoluer mes connaissances / compétences en la matière.
Quoi qu’il en soit, je te remercie de t’être creusé les méninges pour essayer de me sortir de là.
Bien heureux de savoir que tu as trouvé une solution. Idéalement il faut toujours tester dans un environnement qu’on connaît les paramètres. Une base vierge est parfait. tu avais sûrement un paramètre réseau ou de sécurité qui bloquait le tout.
Regarder le RPi lors des essais peux te permettre de repéré le problème. Regarder du côté client et serveur et analyser la situation avec les logs, etc… par exemple quand je code python pour service web, je reste en script log sur le RPi et je passe mes demandes depuis un autre poste, je sais donc ou j’ai un problème. Mais j’avoue que ce n’est pas toujours simple.
)