Un ami c'est inscrit a no-ip pour avoir une redirection de son Ip vers une
adresse..
Il à mis en route une serveur Eqso logiciel de voice ip. Le probléme c'est
que son serveur apparait bien dans la liste des serveurs "Eqso en ligne"
avec le logiciel "monitor", mais dès qu'on veut se connecter dessus le
logiciel "Eqso client" répond connection impossible.
J'ai essayé de monter son serveur chez moi, son serveur apparait bien et il
est accessible de l'extérieur.
On utilise tout les deux XP pro, Ma version est la version un SP1, sur la
sienne il à installé la SP2. Je n'ai pas de routeur, de son côté il à un
routeur Dlink.
La seule différence c'est que la premiére fois où il à mis en route no-ip et
le serveur Eqso, il avait le firewall Xp activé, et il à eu un message
"voulez vous débloquer ce programme ?". il à répondu oui à la question
(débloquer ce programme), par la suite il à désactivé le firewall xP idem
(Serveur apparaissant en ligne mais inaccessible).
J'ai l'impression qu'un port est resté bloqué malgré la désactivation du
firewall.
Comment pouvoir vérifier si le port 10024 qui est utilisé par Eqso n'est
pas bloqué ou même le logiciel lui même ?
Alni a écrit sur fr.comp.reseaux.ip le 01/09/2005 dans :
Bonjour,
Tiens, c'est marrant, j'ai un STH en 510V3 qui fait routeur, et j'ai aussi un
vieux dlink 614+ qui ne me sert que pour sa fonction hub et accès WiFi. il
n'y a rien sur la patte WAN du dlink, je branche le STH sur un port hub.
Donc justement hier, je me dis, tiens je vais essayer le dlink en routeur. Je
ressort un vieux sth en PPPoE, je configure le dlink et j'essaye mes règles
NAT. -J'active le dyndns, mais là problème. J'ai besoin de la fonction "wildcard"
et pas moyen de la faire gerer par le dlink, alors je remet en place un petit
client dns sur le serveur et ça résoud le pb. Mais j'aurais quand même préféré que ce soit le modem/routeur qui gère ça pour cause de délai possible
de 10mn après une reconnection.
Je n'avais pas cette option "wildcard" sur le 604, et elle n'existe pas non plus sur le 804HV que j'ai acheté en remplacement.
-Passons au serveur Web, je me dis que ça va être simple, et ben non de l'extérieur ça ne marche plus.. Pourtant (je viens de vérifier) le firewall à
bien une règle qui autorise WAN* -> IP de mon serveur.
Ca fonctionnait bien sur le 604, et toujours aussi bien sur le 804.
Dans mon cas c'est un serveur https, donc sur le port 443, mais ça ne change rien au problème. Bizarre...
La règle est bien "enable", et "always" (ou dans la bonne plage horaire, avec un routeur à l'heure)?
-- Jean Declercq message rédigé sur un spam 100% recyclé
Bonjour,
J'ai enfin pu comprendre pourquoi avant il n'arrivait pas à rentrer dans la console de configuration de son routeur dlink :
Il rentrait complétait l'adresse wanadoo avec l'ip "192.168.1.1" ie : http://www.wanadoo.fr/192.168.1.1 au lieu de rentrer simplement dans le navigateur http://192.168.1.1
Maintenant, que j'ai pu ouvrir le port 10024 en TCP/UDP, pour que son serveur puisse être connecté de l'extérieur il à fallut modifier la config de Ip Duc (no-ip) pour que celui-ci prenne en compte son adresse publique du type "83.1xx.xx.xxx "au lieu de son adresse Ip locale "192.168.1.1"
De plus un phénoméne étrange quand on désactive le firewall intégré du routeur, il n'y a plus moyen d'accéder à rien sur le net, alors que logiquement çà devrait faciliter les choses.
Merci à tous pour vos conseils
JHJ
"jean declercq" <jde@wanadoo.fr> a écrit dans le message de news:
mn.12697d592df7cb5f.14737@wanadoo.fr...
Alni a écrit sur fr.comp.reseaux.ip le 01/09/2005 dans
<mn.0c9b7d5952d80668.22859@nowhere.com> :
Bonjour,
Tiens, c'est marrant, j'ai un STH en 510V3 qui fait routeur, et j'ai
aussi un
vieux dlink 614+ qui ne me sert que pour sa fonction hub et accès WiFi.
il
n'y a rien sur la patte WAN du dlink, je branche le STH sur un port hub.
Donc justement hier, je me dis, tiens je vais essayer le dlink en
routeur. Je
ressort un vieux sth en PPPoE, je configure le dlink et j'essaye mes
règles
NAT.
-J'active le dyndns, mais là problème. J'ai besoin de la fonction
"wildcard"
et pas moyen de la faire gerer par le dlink, alors je remet en place un
petit
client dns sur le serveur et ça résoud le pb. Mais j'aurais quand même
préféré que ce soit le modem/routeur qui gère ça pour cause de délai
possible
de 10mn après une reconnection.
Je n'avais pas cette option "wildcard" sur le 604, et elle n'existe pas
non plus sur le 804HV que j'ai acheté en remplacement.
-Passons au serveur Web, je me dis que ça va être simple, et ben non de
l'extérieur ça ne marche plus.. Pourtant (je viens de vérifier) le
firewall à
bien une règle qui autorise WAN* -> IP de mon serveur.
Ca fonctionnait bien sur le 604, et toujours aussi bien sur le 804.
Dans mon cas c'est un serveur https, donc sur le port 443, mais ça ne
change rien au problème.
Bizarre...
La règle est bien "enable", et "always" (ou dans la bonne plage
horaire, avec un routeur à l'heure)?
--
Jean Declercq
message rédigé sur un spam 100% recyclé
Bonjour,
J'ai enfin pu comprendre pourquoi avant il n'arrivait pas à rentrer dans la
console de configuration de son routeur dlink :
Il rentrait complétait l'adresse wanadoo avec l'ip "192.168.1.1" ie :
http://www.wanadoo.fr/192.168.1.1 au lieu de rentrer simplement dans le
navigateur http://192.168.1.1
Maintenant, que j'ai pu ouvrir le port 10024 en TCP/UDP, pour que son
serveur puisse être connecté de l'extérieur il à fallut modifier la config
de Ip Duc (no-ip) pour que celui-ci prenne en compte son adresse publique du
type "83.1xx.xx.xxx "au lieu de son adresse Ip locale "192.168.1.1"
De plus un phénoméne étrange quand on désactive le firewall intégré du
routeur, il n'y a plus moyen d'accéder à rien sur le net, alors que
logiquement çà devrait faciliter les choses.
Alni a écrit sur fr.comp.reseaux.ip le 01/09/2005 dans :
Bonjour,
Tiens, c'est marrant, j'ai un STH en 510V3 qui fait routeur, et j'ai aussi un
vieux dlink 614+ qui ne me sert que pour sa fonction hub et accès WiFi. il
n'y a rien sur la patte WAN du dlink, je branche le STH sur un port hub.
Donc justement hier, je me dis, tiens je vais essayer le dlink en routeur. Je
ressort un vieux sth en PPPoE, je configure le dlink et j'essaye mes règles
NAT. -J'active le dyndns, mais là problème. J'ai besoin de la fonction "wildcard"
et pas moyen de la faire gerer par le dlink, alors je remet en place un petit
client dns sur le serveur et ça résoud le pb. Mais j'aurais quand même préféré que ce soit le modem/routeur qui gère ça pour cause de délai possible
de 10mn après une reconnection.
Je n'avais pas cette option "wildcard" sur le 604, et elle n'existe pas non plus sur le 804HV que j'ai acheté en remplacement.
-Passons au serveur Web, je me dis que ça va être simple, et ben non de l'extérieur ça ne marche plus.. Pourtant (je viens de vérifier) le firewall à
bien une règle qui autorise WAN* -> IP de mon serveur.
Ca fonctionnait bien sur le 604, et toujours aussi bien sur le 804.
Dans mon cas c'est un serveur https, donc sur le port 443, mais ça ne change rien au problème. Bizarre...
La règle est bien "enable", et "always" (ou dans la bonne plage horaire, avec un routeur à l'heure)?
-- Jean Declercq message rédigé sur un spam 100% recyclé
Bonjour,
J'ai enfin pu comprendre pourquoi avant il n'arrivait pas à rentrer dans la console de configuration de son routeur dlink :
Il rentrait complétait l'adresse wanadoo avec l'ip "192.168.1.1" ie : http://www.wanadoo.fr/192.168.1.1 au lieu de rentrer simplement dans le navigateur http://192.168.1.1
Maintenant, que j'ai pu ouvrir le port 10024 en TCP/UDP, pour que son serveur puisse être connecté de l'extérieur il à fallut modifier la config de Ip Duc (no-ip) pour que celui-ci prenne en compte son adresse publique du type "83.1xx.xx.xxx "au lieu de son adresse Ip locale "192.168.1.1"
De plus un phénoméne étrange quand on désactive le firewall intégré du routeur, il n'y a plus moyen d'accéder à rien sur le net, alors que logiquement çà devrait faciliter les choses.
Merci à tous pour vos conseils
JHJ
Alni
Bonjour,
Thefox vient de nous annoncer :
De plus un phénoméne étrange quand on désactive le firewall intégré du routeur, il n'y a plus moyen d'accéder à rien sur le net, alors que logiquement çà devrait faciliter les choses.
Non, pas forcement. Le firewall d'un routeur NAT est surtout là pour empecher certains trafics de *sortir* (par exemple si je veux empêcher les utilisateurs de faire du msn ou du emule), puisque par défaut tout le trafic WAN->LAN qui n'est pas renvoyé explicitement par une translation NAT vers une machine particulière est "droppé"
Parmis les règles du firewall il y en a une qui dit : LAN,* -> WAN,* autorisé "J'autorise tout le trafic du LAN vers le WAN" Peut être que sans cette règle, rien ne sort.....
-- Alni
Bonjour,
Thefox vient de nous annoncer :
De plus un phénoméne étrange quand on désactive le firewall intégré du
routeur, il n'y a plus moyen d'accéder à rien sur le net, alors que
logiquement çà devrait faciliter les choses.
Non, pas forcement. Le firewall d'un routeur NAT est surtout là pour
empecher certains trafics de *sortir* (par exemple si je veux empêcher
les utilisateurs de faire du msn ou du emule), puisque par défaut tout
le trafic WAN->LAN qui n'est pas renvoyé explicitement par une
translation NAT vers une machine particulière est "droppé"
Parmis les règles du firewall il y en a une qui dit :
LAN,* -> WAN,* autorisé
"J'autorise tout le trafic du LAN vers le WAN"
Peut être que sans cette règle, rien ne sort.....
De plus un phénoméne étrange quand on désactive le firewall intégré du routeur, il n'y a plus moyen d'accéder à rien sur le net, alors que logiquement çà devrait faciliter les choses.
Non, pas forcement. Le firewall d'un routeur NAT est surtout là pour empecher certains trafics de *sortir* (par exemple si je veux empêcher les utilisateurs de faire du msn ou du emule), puisque par défaut tout le trafic WAN->LAN qui n'est pas renvoyé explicitement par une translation NAT vers une machine particulière est "droppé"
Parmis les règles du firewall il y en a une qui dit : LAN,* -> WAN,* autorisé "J'autorise tout le trafic du LAN vers le WAN" Peut être que sans cette règle, rien ne sort.....
