J'ai un domaine Dyndns
J'ai un DVR sur le port 5000 et je me connecte en extérieur par /mon domaine.net:5000 et tout est ok
De la même manière j'ai un serveur domotique sur le port 5001
Mais là de l'extérieur çà pase pas . Tout ok en local avec ip:5001
merci de votre aide
Hors ligne
Essai de mettre ton serveur en dmz pour voir si c'est un pas un problème de pat.
Hors ligne
Merci mais non , tj rien
Hors ligne
Bonjour
Y a t il des ports spécifiques réservés aux serveurs ?
Sinon je ne sais pas quoi faire ...
Merci
Hors ligne
Merci de cette aide .
Je suis pas sur place
Pare feu au minimum
J'ai fait une règle Nat pour chacune des trois machines que je veux voir de l'exterieur
1/ Le DVR : 192:168:1:200 - Port 5000 en me connectant avec mon dyndns tout OK
2/ Mon serveur domotique Legrand : 192:168:1:201 - Port 5001 parfait en interne par cable ou WiFi mais pas de l'extérieur
3/ Ma Time Capsule Apple : 192:168:1:202 - port 5001 à voir après
Hors ligne
Excuses ..Erreur de frappe : La time capsule est sur le port 5002 ..
Hors ligne
De mémoire j'ai laissé les 2 sur la règle nat .
Hors ligne
OK donc mercredi
J'en profiterai pour valider le pilotage de la box à distance .
Merci beaucoup .
Hors ligne
Bonsoir
Je cherche encore.
J'ai le contact de ma box à distance et tj rien en TCP comme UDP ...
A votre bon coeur ...
Hors ligne
Bonjour
Pour conclure et peut être faire gagner du temps à certain . Mon serveur domotique a une configuration demandant un pont (gateway) . Il faut donc rentrer l'adresse ip de la box en interne . Et cà marche . Je peux tout contrôler à distance . Lumière , volets roulants , portail etc ... et voir tout çà sur les caméras .... Bref comme les enfants ...
Hors ligne
Bonsoir,
A priori, il suffirait de renseigner la règle PAT avec :
Application / Service -> ce-que-tu-veux
Port externe -> 5001
Port interne -> 5001
Protocole -> à-essayer-mais-il-y a-de-grandes-chances-que-ce-soit-TCP
Équipement -> ton-serveur-domotique-tel-que-tu-l'as-nommé
Activer -> coché
Il ne devrait pas y avoir besoin de régler le pare-feu sur "faible", ça devrait fonctionner sur "moyen".
Si ça ne fonctionne toujours pas :
- vois-tu ton serveur domotique dans la liste des équipements affichée par la LiveBox ?
- quel(s) protocole(s) utilise ledit serveur domotique ? http ? (En local, te connectes-tu via un navigateur web en faisant précéder l'adresse de http:// ?)
- il y aurait-il une malchance que le port TCP et/ou UDP 5001 soit bloqué à l'émission, depuis l'endroit où tu essayes de prendre le contrôle du serveur domotique ?
a+
Hors ligne
'Soir darthrider,
Lire le topic en entier avant d'y poster une réponse t'aurais évité cette situation cocasse où l'auteur du topic a posté un peu moins de 12 h avant et dans le message précédent immédiatement le tiens qu'il avait trouvé l'origine de son problème (défaut de config du serveur en question).
Hors ligne
Bonjour
Merci à vous
Par souci de comprendre je cherche la logique de la LB pour détecter les éléments connectés . Sur mon réseau interne tout est accessible et j'ai quasiment jamais les mêmes éléments connectés selon la Box ...
Hors ligne
Salut,
Le pire est que j'avais bien (non, justement, pas bien) lu jusqu'au dernier message mais que je n'avais pas capté que, en définitive, ça fonctionnait
Au fait, dans ce contexte, la bonne traduction de "gateway" est "routeur" et non "pont" qui est normalement réservé à autre chose 
Pour ce qui est de la logique de la LiveBox, je constate aussi que certains équipements physiquement connectés et actifs ne sont quelquefois pas marqués comme actifs (en gris) dans la liste.
Je ne sais pas ce qu'utilise la LiveBox pour détecter les équipements, mais il y a des chances qu'elle repère les requêtes ARP (systématiquement émises au démarrage puis, ensuite, au gré des besoins) pour introduire les nouveaux éléments dans la liste. Ensuite, je suppose que l'occurence de ces même requêtes permet d'indiquer qu'un élément est actif ou, au contraire, inactif, en cas d'absence prolongée de requête. M'enfin, ce n'est qu'une supposition qui me semble plausible mais absolument pas une certitude.
a+
Hors ligne
Bonjour,
Il n'y a pas de raison a priori pour qu'un ARP REQUEST soit émis vers un terminal qui se trouve soudainement connecté au réseau local. D'autre part la notion actif ou inactif ne veut rien dire sur une connexion Ethernet. La seule chose certaine est qu'il est obligatoire que l’élément physiquement connecté soit conforme au protocole Ethernet (ou (IEEE802.3) .
Le seul moyen pour faire apparaitre le nouveau terminal dans la table d'ARP de la livebox est de lui faire générer une requête vers le net (pas vers le réseau local) de façon à ce que le gateway (la livebox) éprouve le besoin d'envoyer des data vers l'IP locale qui a émis la demande vers le net ..
A ce moment en effet , pour une période fugitive le terminal est inscrit dans la table d'ARP et peut certainement être mémorisé (inactif quand l’entrée arp retombe ou actif )
Cette mémorisation en sert pas a grand chose et le fait de marquer le terminal actif ou inactif non plus.et aussi a partir de combien de temps faut il effacer le périphérique ? (ou pas ! )
Si pour des besoins évident on a besoin "d'inscrire " un terminal dans le répertoire (mémoire) de la livebox alors il faudra compter sur une entrée manuelle de la mac adresse et de l'IP local si cette fonction n'a pas été oubliée comme dans la livebox 2 ... (je crois que c'est bon dit-on pour la livebox play).
bref cette histoire de découverte automatique des périphérique est complétement bancale et a été conçue par des gens qui confondent les connecteurs usb avec les protocole tcp/ip .. et ça marche pas bien sur.
Il faudrait écrire une application spécifique pour autant que cela soit utile tout est faisable.
A plus
Hors ligne