Problème ddclient derriere firewall
Résolu
otipaugle
-
kmf -
kmf -
Bonjour,
je suis inscrit chez dyndns car j'ai une ip dynamique.
j'ai donc installé ddclient afin de recharger mon ip sur les dns.
Le problème c'est que le rafraichissement ne se fait pas.
Il semble que ce soit du à mon firewall qui bloque ddclient.
Or, quand j'ouvre ddclient.conf, il est ecrit :
protocol : dyndns2
Alors, j'ai cherché si il y avait un port associé, mais je n'arrive pas à trouver.
Quelqu'un aurait-il une piste pour moi ?
Merci d'avance pour votre aide.
Otip
je suis inscrit chez dyndns car j'ai une ip dynamique.
j'ai donc installé ddclient afin de recharger mon ip sur les dns.
Le problème c'est que le rafraichissement ne se fait pas.
Il semble que ce soit du à mon firewall qui bloque ddclient.
Or, quand j'ouvre ddclient.conf, il est ecrit :
protocol : dyndns2
Alors, j'ai cherché si il y avait un port associé, mais je n'arrive pas à trouver.
Quelqu'un aurait-il une piste pour moi ?
Merci d'avance pour votre aide.
Otip
A voir également:
- Problème ddclient derriere firewall
- Comodo firewall - Télécharger - Pare-feu
- Poisson derriere la voiture - Accueil - Maison
- Avs firewall. - Télécharger - Contrôle parental
- Zonealarm free antivirus + firewall - Télécharger - Pare-feu
- Comment savoir qui se cache derriere un compte snap - Forum Snapchat
1 réponse
En principe ce sont les ports 67 et 68 udp qui sont utilises par DHCP.
Regardes sur le lien pour "README" section 5.1 (1er lien dans la partie documentation) a: http://www.isc.org/index.pl?/sw/dhcp/
Ca dit:
If you are running the DHCP server or client on a computer that's also acting as a firewall, you must be sure to allow DHCP packets through the firewall. In particular, your firewall rules _must_ allow packets from IP address 0.0.0.0 to IP address 255.255.255.255 from UDP port 68 to UDP port 67 through. They must also allow packets from your local firewall's IP address and UDP port 67 through to any address your DHCP server might serve on UDP port 68. Finally, packets from relay agents on port 67 to the DHCP server on port 67, and vice versa, must be permitted.
We have noticed that on some systems where we are using a packet filter, if you set up a firewall that blocks UDP port 67 and 68 entirely, packets sent through the packet filter will not be blocked. However, unicast packets will be blocked. This can result in strange behaviour, particularly on DHCP clients, where the initial packet exchange is broadcast, but renewals are unicast - the client will appear to be unable to renew until it starts broadcasting its renewals, and then suddenly it'll work. The fix is to fix the firewall rules as described above.
Cependant j'utilise le client "dhcpcd" et il marche tres bien avec un firewall qui bloque tous les ports. Il faut seulement la regle standard qui laisse passer les paquets venant de l'exterieur s'ils sont relies comme reponse aux paquets que tu as envoye toi meme auparavant, quelque chose comme ca:
et il faut que la chaine OUTPUT soit ouverte.
Pour le serveur DHCP c'est autre chose la il faut correctement ouvrir les ports 67/68 udp comme indique ci-dessus.
Regardes sur le lien pour "README" section 5.1 (1er lien dans la partie documentation) a: http://www.isc.org/index.pl?/sw/dhcp/
Ca dit:
If you are running the DHCP server or client on a computer that's also acting as a firewall, you must be sure to allow DHCP packets through the firewall. In particular, your firewall rules _must_ allow packets from IP address 0.0.0.0 to IP address 255.255.255.255 from UDP port 68 to UDP port 67 through. They must also allow packets from your local firewall's IP address and UDP port 67 through to any address your DHCP server might serve on UDP port 68. Finally, packets from relay agents on port 67 to the DHCP server on port 67, and vice versa, must be permitted.
We have noticed that on some systems where we are using a packet filter, if you set up a firewall that blocks UDP port 67 and 68 entirely, packets sent through the packet filter will not be blocked. However, unicast packets will be blocked. This can result in strange behaviour, particularly on DHCP clients, where the initial packet exchange is broadcast, but renewals are unicast - the client will appear to be unable to renew until it starts broadcasting its renewals, and then suddenly it'll work. The fix is to fix the firewall rules as described above.
Cependant j'utilise le client "dhcpcd" et il marche tres bien avec un firewall qui bloque tous les ports. Il faut seulement la regle standard qui laisse passer les paquets venant de l'exterieur s'ils sont relies comme reponse aux paquets que tu as envoye toi meme auparavant, quelque chose comme ca:
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
et il faut que la chaine OUTPUT soit ouverte.
Pour le serveur DHCP c'est autre chose la il faut correctement ouvrir les ports 67/68 udp comme indique ci-dessus.