framboise314.fr

Bonjour,
J'ai un truc curieux sur un Raspi Zero W installé depuis des années.
Tout fonctionnait parfaitement, jusqu'à un upgrade..... personne ne s'est aperçu du dysfonctionnement (sic) mais ça me prend la tête :

Depuis cet upgrade : tous les services ne répondent que sur l'interface eth0

Je m'explique : eth0 est bien connecté au réseau, il a son ip, wlan0 aussi et a une ip (c'est 192.168.0.n et 192.168.0.n+1)
On les voit très bien sur le routeur et je peux les pinger. un nmap me les liste et me dit bien qu'un s'agit d'un raspberry : aucun doute possible, l'adresse MAC fournis par nmap ne laisse aucun doute, ce sont bien les ip du raspberry zero (eth0 et wlan0)

Mais : un accès à tout service réseau hébergé par le raspberry zero via le LAN fonctionne parfaitement
et plus aucun service réseau hébergé par le raspberry zero via le WIFI ne fonctionne (ni ssh, ni apache, ni les autres)

Je précise pour le test : je ne tente l'accès que sur le réseau local (le NAT n'intervient pas ici)

En cherchant sur google, j'ai vu que je n'étais pas le seul dans ce cas (ssh accessible uniquement via le LAN) mais je n'ai pas trouvé de solution. (le paramétrage de sshd ne précise pas qu'elle interface est à l'écoute, ni apache, ni mes autres services pour moi, ça veut dire que les 2 le sont). Je n'ai pas de règles iptables, le seul pare-feu est une protection vis à vis du WAN dans la box donc quand sur suis sur le LAN, je ne passe pas par le pare-feu

Ce qui est drôle c'est que sur ce même LAN j'ai un autre rapsberry mais un 3. Il est accessible en ssh autant par son eth0 que par son wlan0
So, what the f... ??

Puisque personne n'a répondu, j'ai poursuivi la recherche et j'ai trouvé..... c'est bête comme crésus !

Ce Raspberry est un IoT qui met à disposition des services spécifiques par internet au travers d'une api soap
Comme il était attaqué (comme tout IoT connecté au web), j'avais ajouté des règles de pare-feu dans iptables très strictes.
Cela est possible car il ne doit répondre qu'à 4 serveurs .
Deux sont sur le web en ip fixe et 2 sont sur le LAN.
Donc seuls ses 2 ip internet et toutes les ip du LAN étaient autorisées via iptables.

Mais voilà : suite au fait qu'orange nous a imposé le remplacement de notre box pro par une nouvelle version, j'ai fait la migration au fur et à mesure pour ne pas couper tout le réseau pendant 2 jours.
Pendant une semaine, j'avais donc 2 box en fonctionnement : l'ancienne (avant de la rendre) en 192.168.0.0/24 et la nouvelle que j'ai mis en 192.168.2.0/24
Au fur et à mesure, les périphériques réseaux (une 50 aines) sont passés en 192.168.2.0 et les règles NAT ont été mises en place; il y a beaucoup de règles de routage.

Ce raspberry a été le dernier a migré, il est donc passé de 192.168.0.243 et 244 à 192.168.2.243 et 244
Et les règles iptables surveillant l'interface wifi n'avaient pas évoluées sur l'interface wlan0 : elles étaient restées à n'accepter du LAN que les 192.168.0.0/24 et pas les 192.168.2.0/24

Donc si ça vous arrive : pensez à vérifier votre pare-feu local (iptables ou firewallcmd) même si vous pensez qu'il n'y a pas de règles dedans.
Ce Raspberry tourne H24 depuis des années (En fait, je croyais que c'était un PiZéro, en ouvrant le périphérique, j'ai vu un Pi-1A avec un dongle Wifi !).
Ces petites bêtes sont tellement fiables qu'on oublie ce qu'on a mis dedans.

Salut Piper.

Trouver la solution d'un problème dont on n'a pas accès à l'environnement, n'est pas chose facile.
D'autant plus que dans ton premier message, tu n'as pas indiqué le changement de box, ainsi que les bidouilles que tu as faites aupréalable.

Pour mes accès par putty, en SSH, sans faire la distinction entre mes différentes Raspberry, j'utilise le même nom sous la forme "raspberrypi.local".
Ce qui fait que j'ignore si je passe en Ethernet ou en Wifi, mais aussi en IPv4 ou en IPv6.

Dans ma box Sfr, j'ai défini une adresse IPv4 et IPv6 pour chaque périphérique que je possède. Soit :
--> 2 RPi 2B, pas de wifi, mais eth0.
--> 2 RPi 3A+, wifi et pas de eth0.
--> 2 RPI 3B+, wifi et eth0.
--> 2 RPi 4B/8Go, wifi et eth0.
--> 2 RPi zero v1.3 , pas de wifi ni de eth0.
--> 4 RPi Zero W, wifi et eth0.
--> 2 Rpi Zero WH, wifi et eh0.

Soit un total de 16 Raspberry.
J'ai 10 adresses wifi et 10 adresses eth0, aussi bien en IPv4 qu'en IPv6 (=40).
Au total, je dois gérer 74 adresses dans ma Box Sfr.

J'utilise les noms DNS que j'ai introduit dans ma Box Sfr.
C'est mieux de procéder ainsi car je n'utilise jamais les adresses physiques IPv4 et IPv6.
Toutes mes adresses sont définies en DHCP et en DNS dans ma box Sfr.

J'utilise aussi, comme toi, l'iptables pour restreindre les accès à mes raspberry.
Mais je n'ai jamais introduit les noms de mes raspberry, ni les adresses physiques, ni les noms logiques (DNS).

Par contre, dans Resolv.conf, j'ai l'adresse du serveur DNS de ma box Sfr.

Si maintenant, je dois renuméroter les adresses physiques dans ma Box Sfr, cela n'aura pas d'impact sur mes Raspberry et mes autres périphériques.
Le nom W-RPi-4B-2 pointera sur l'adresse physique du Wifi de ma seconde Raspberry Pi 4B / 8Go , même si l'adresse vient à changer.

Afin de normaliser le suffixe des noms DNS, au lieu de mettre ".local" qui fonctionne sous linux mais pas sous Windows, j'ai préféré mettre ".localhost".
Une autre solution est d'utiliser le suffixe ".lan". L'important est que le nom DNS ne soit pas visible depuis internet.

En conclusion, un peu d'organisation au niveau des noms et des adresses physiques que tu centralises dans ta Box, permettra de résoudre bien des problèmes.

Cordialement.
Artemus24.
@+

Bonjour

Code : Tout sélectionner

En conclusion, un peu d'organisation au niveau des noms et des adresses physiques que tu centralises dans ta Box, permettra de résoudre bien des problèmes.

L'organisation y es déjà : tout est centralisé dans la box, comme toi. Et des documents sont rédigés pour qu'en cas où je suis absent mon backup puisse prendre le relais.

Le pb , tu l'as dit est que les noms .local sont mal reconnus sous windows (d'où mes reflexes d'utiliser fréquemment leur ip fixes réservées dans la box)

Le "bidouillage" est le résultat de tentatives de piratages répétitives sur plusieurs semaines par DOS qui a eu lieu il y a de nombreuses années (enfin 5 ou 6 ans) dans lequel, j'ai réagit en urgence et tu sais comme moi que dans l'urgence........on omet la documentation.

Artemus24 a écrit : ↑
sam. 27 nov. 2021 00:10
...au lieu de mettre ".local" qui fonctionne sous linux mais pas sous Windows...

piper a écrit : ↑
sam. 27 nov. 2021 18:15
... tu l'as dit est que les noms .local sont mal reconnus sous windows ...

Vous vous trompez (j'espère que c'est politiquement correct come ca?). J'ai des domaines ad qui cataloguent plusieurs millers de hosts qui sont en .local et qui ont été creés à l'époque de 2k server qui n'ont jamais posé le moindre problème et qui ont pus migrer sans aucun soucis par toutes les générations depuis et jusqu'au dernières versions de win.server. J'ajoute pour ceux que ca interesse que le .local était une règle de bonne pratique pour les domaines windows isolés (MCSA 70-216 70-292)

Ne dites donc pas n'importe quoi

Un peu de respect ne ferait pas de mal !
Je ne suis pas spécialiste réseau.
Et je n'exige pas de vous que vous soyez spécialiste des bases de données ou de topologie mathématiques, ce qui est mon cas.

Excuse piper, aucun manque de respect de ma part mais il y a des énormités qui piquent grave les yeux.
Je modifie mon message précédent pour qu'il ni ai pas de malentendu.

Un DNS d'un des domaines en .local que je citait (celui la c'est un petit de ~150 postes). Je l'ai créé en 2001 avec l'arrivé de Windows 2000 Server pour la migration d'un NT4. Ce domaine en .local a passé toutes les générations de clients et de serveurs depuis. Forcement tous les clients qui sont rattachés au domaine ont le suffixe .local. Tout ca pour dire que windows n'a aucun problème avec .local

: local.png (102.67 Kio) Vu 4339 fois

ps: moi je ne suis spécialiste en rien puisque tout ce que j'ai appris hier sera obsolète demain et tout ce que j'apprendrai demain ne m'a jamais servi

Salut à tous.

Artemus24 a écrit :Afin de normaliser le suffixe des noms DNS, au lieu de mettre ".local" qui fonctionne sous linux mais pas sous Windows, j'ai préféré mettre ".localhost".

Je me suis trompé. Je voulais dire l'inverse, à savoir que ".local" fonctionne sous windows mais pas sous linux.
".local" est une création de Microsoft. C'est la raison pour laquelle ça fonctionne sous windows.

Voici les explications des problèmes que j'ai rencontrés.
Je ne voulais pas utiliser les adresses IP physiques pour me connecter par putty à mes raspberry.
J'ai donc utilisé le serveur DNS de ma box SFR.

Au départ, je ne mettais aucun suffixe, et ça fonctionnait avec putty.
Dans la raspberry, j'avais accès à ces noms sans aucun problème.

Sauf que windows exigeait un suffixe. J'ai donc suffixé les noms par ".local".
Et j'ai constate que cela ne fonctionnait plus sous linux.

Comme ce choix ne répondait pas à mes attentes, j'ai cherché sur le net.

Il était conseillé de suffixer par son nom de domaine.
Sauf que mes déclarations sont faites dans un véritable serveur DNS qui se trouve sur le net.
Or les adresses sont locales à mon réseau et cette solution ne pouvait pas convenir.

J'avais le choix de suffixer mes adresses locales par mon nom de domaine dans le serveur DNS de ma box SFR.
Sauf que je pensais que cela aurait été visible dans le net. Je n'ai pas choisi cette solution.

Je cherchais un suffixe qui ne soit pas transmissible sur le net.
J'ai trouvé que l'on pouvait suffixer par ".localhost" ou par ".lan" que j'ai découvert bien plus tard.
J'ai choisi de mettre ".localhost", et depuis, plus aucun problème.

Pour les tests, j'ai utilisé nslookup aussi bien avec windows qu'avec linux.

Donc non, je ne dis pas n'importe quoi.
Je ne suis pas un spécialiste réseau, et il est fort probable que j'ai dû mal faire.
Comme la solution que j'ai trouvé sur le net me convenait, je l'ai adopté.

Bud Spencer a écrit :j'espère que c'est politiquement correct comme ca?

Et bien non, car le fait de le souligner pose déjà le problème du politiquement correcte.

Je ne sais pas pourquoi vous êtes aussi agressif !!!

@ Piper : tu travailles sur quelles SGBD ?
Je m'amuse beaucoup avec MySql et Firebird dans le forum developpez.
Sinon, jadis j'ai pratiqué sous BULL IDS II et sous IBM DB2.

@+

Artemus24 a écrit : ↑
lun. 29 nov. 2021 18:05
...
Je ne sais pas pourquoi vous êtes aussi agressif !!!
...

Agressif ? pas du tout. piper y voyait du manque de respect, je m’en suis excusé, tu y vois de l’agressivité, je m’en excuse, ce n’en était pas. Pour moi, tu as juste dit une énorme connerie (excuse encore je n’ai pas d’autre mots) et en plus piper la confirmait. Pour moi, l’un comme l’autre avez des compétences qui sont ce qu’elles sont mais qui sont toutefois certaines et qui font référence pour beaucoup de lecteurs du forum, d’où la spontanéité légèrement cavalière de mon intervention. Vous dites tous deux ne pas etre expert reseau (rassurez vous, j'en connais plein d'autres ...) et bien j'ai moi aussi mes carences. Je ne suis pas expert en psychologie et j'ai parfois un peu de mal a mesurer la susceptibilité de chacun.
Bref, la bonne nouvelle dans tout ça, c’est que ceux qui ne s’intéresseront qu’a l’aspect technique de ce post sauront à quoi s’en tenir et cerise sur le gâteau, vous avez tous les deux appris quelque chose et ça … c’est cadeau

ps: Promis, sans la moindre once d'agressivité de ma part, j'ose a peine te dire que tu te trompes encore

Artemus24 a écrit : ↑
lun. 29 nov. 2021 18:05
...
".local" est une création de Microsoft. C'est la raison pour laquelle ça fonctionne sous windows.
...

Bha non, .local n'est pas une création microsoft mais un suffixe normalisé qui a justement cette spécificité de ne pas avoir de propagation sur internet, donc il doit etre utilisé savamment. Correctement mis en place, et bien compris ce suffixe fonctionne aussi parfaitement sous linux (rfc 6762)

Salut Bud Spencer.

Les tests date de 2018, et je ne me souviens plus trop pourquoi j'avais ce problème avec le suffixe ".local" dans la raspberry.
Voici le sujet que j'avais ouvert dans le forum developpez.
J'utilise le suffixe ".localhost" qui fonctionne aussi bien sous windows que sous Raspbian (Raspberry Pi OS).

J'ai deux contraintes :

1) pourvoir utiliser les noms DNS qui sont stockés dans ma BOX SFR, avec et sans les préfixes, depuis windows ou depuis Raspberry Pi Os (raspbian).
J'utilise le suffixe "localhost" et ça fonctionne parfaitement. Je ne vais pas tous changer pour repasser au suffixe "local" qui ne m'apportera rien de plus.

2) pourvoir utiliser le nom des mes ordinateurs, que ce soit sous windows ou sous Raspberry Pi OS.
Sous Raspberry Pi OS, ça fonctionne mais pas sous windows et je ne comprends pas pourquoi. Voici le résultat :

Code : Tout sélectionner

C:\>nslookup orion
Serveur :   box
Address:  2a02:8435:342:3801::1

*** box ne parvient pas à trouver orion : Non-existent domain

C:\>nslookup orion.
Serveur :   box
Address:  2a02:8435:342:3801::1

Nom :    orion
Addresses:  2a02:8435:342:3801::200
          192.168.1.20

C:\>nslookup orion.local
Serveur :   box
Address:  2a02:8435:342:3801::1

*** box ne parvient pas à trouver orion.local : Non-existent domain

C:\>nslookup orion.localhost
Serveur :   box
Address:  2a02:8435:342:3801::1

*** box ne parvient pas à trouver orion.localhost : Non-existent domain

C:\>

Le suffixe est pourtant "localhost", mais je n'ai que "orion." qui soit renseigné. Pareil si j'interroge la raspberry :

Code : Tout sélectionner

C:\>nslookup raspberrypi
Serveur :   box
Address:  2a02:8435:342:3801::1

*** box ne parvient pas à trouver raspberrypi : Non-existent domain

C:\>nslookup raspberrypi.
Serveur :   box
Address:  2a02:8435:342:3801::1

Nom :    raspberrypi
Addresses:  2a02:8435:342:3801::710
          2a02:8435:342:3801::310
          192.168.1.71


C:\>nslookup raspberrypi.local
Serveur :   box
Address:  2a02:8435:342:3801::1

*** box ne parvient pas à trouver raspberrypi.local : Non-existent domain

C:\>nslookup raspberrypi.localhost
Serveur :   box
Address:  2a02:8435:342:3801::1

*** box ne parvient pas à trouver raspberrypi.localhost : Non-existent domain

C:\>

Même Résultat. Sous Windows, il semble que seul le nom suffixé par le point fonctionne.

Pour les ping, le comportement, toujours sous Windows est surprenant.

Code : Tout sélectionner

C:\>ping raspberrypi

Envoi d’une requête 'ping' sur raspberrypi.local [2a02:8435:342:3801:530::1] avec 32 octets de données :
Réponse de 2a02:8435:342:3801:530::1 : temps=16 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=8 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=2 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=11 ms

Statistiques Ping pour 2a02:8435:342:3801:530::1:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 2ms, Maximum = 16ms, Moyenne = 9ms

C:\>ping raspberrypi.

Envoi d’une requête 'ping' sur raspberrypi [2a02:8435:342:3801::310] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.

Statistiques Ping pour 2a02:8435:342:3801::310:
    Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),

C:\>ping raspberrypi.local

Envoi d’une requête 'ping' sur raspberrypi.local [2a02:8435:342:3801:530::1] avec 32 octets de données :
Réponse de 2a02:8435:342:3801:530::1 : temps=12 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=2 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=2 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=2 ms

Statistiques Ping pour 2a02:8435:342:3801:530::1:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 2ms, Maximum = 12ms, Moyenne = 4ms

C:\>ping raspberrypi.localhost
La requête Ping n’a pas pu trouver l’hôte raspberrypi.localhost. Vérifiez le nom et essayez à nouveau.

C:\>

Dans le cas d'Orion, il ignore carément mon suffixe et place toujours le suffixe que j'ai déclaré "localhost".

Code : Tout sélectionner

C:\>ping raspberrypi

Envoi d’une requête 'ping' sur raspberrypi.local [2a02:8435:342:3801:530::1] avec 32 octets de données :
Réponse de 2a02:8435:342:3801:530::1 : temps=16 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=8 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=2 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=11 ms

Statistiques Ping pour 2a02:8435:342:3801:530::1:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 2ms, Maximum = 16ms, Moyenne = 9ms

C:\>ping raspberrypi.

Envoi d’une requête 'ping' sur raspberrypi [2a02:8435:342:3801::310] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.

Statistiques Ping pour 2a02:8435:342:3801::310:
    Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%),

C:\>ping raspberrypi.local

Envoi d’une requête 'ping' sur raspberrypi.local [2a02:8435:342:3801:530::1] avec 32 octets de données :
Réponse de 2a02:8435:342:3801:530::1 : temps=12 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=2 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=2 ms
Réponse de 2a02:8435:342:3801:530::1 : temps=2 ms

Statistiques Ping pour 2a02:8435:342:3801:530::1:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 2ms, Maximum = 12ms, Moyenne = 4ms

C:\>ping raspberrypi.localhost
La requête Ping n’a pas pu trouver l’hôte raspberrypi.localhost. Vérifiez le nom et essayez à nouveau.

C:\>

Questions : Pourquoi ai-je un comportement différent selon l'origne du nom interrogé ?
D'où sort ce suffixe "local" pour le nom "RaspberryPi" ?
Pourquoi le suffixe que j'impose ne soit pas pris en compte dans le cas de "Orion" ?

Cordialement.
Artemus24.
@+

framboise314.fr

ssh qui n'écoute que le LAN

ssh qui n'écoute que le LAN

Re: ssh qui n'écoute que le LAN

Re: ssh qui n'écoute que le LAN

Re: ssh qui n'écoute que le LAN

Re: ssh qui n'écoute que le LAN

Re: ssh qui n'écoute que le LAN

Re: ssh qui n'écoute que le LAN

Re: ssh qui n'écoute que le LAN

Re: ssh qui n'écoute que le LAN

Re: ssh qui n'écoute que le LAN