Apache v2.0 tourne sur ma machine avec un embryon de page.
Ma connexion internet se fait via une Club-Internet Box en modem
routeur.
L'ip de ma machine sur le LAN est 192.168.1.42
Mon ip fixe coté WAN est 87.89.33.193
Dans l'interface de configuration du modem-routeur (un Hitachi Tecom
AH4222 en fait) j'ai "naté" le port 80 vers l'ip de ma machine.
J'ai cliqué sur "Advanced Setup" puis sur NAT et je suis arrivé sur une
page qui dit:
8<-----------8<---------8<----------8<----------8<----------8<----------8<
NAT -- Virtual Servers Setup
Virtual Server allows you to direct incoming traffic from WAN side
(identified by Protocol and External port) to the Internal server with
private IP address on the LAN side. The Internal port is required only
if the external port needs to be converted to a different port number
used by the server on the LAN side. A maximum 32 entries can be
configured.
8<-----------8<---------8<----------8<----------8<----------8<----------8<
J'ai donc cliqué le bouton "Add" et choisi "Web server", vérifié que le
port associé était bien le 80, puis saisi l'adresse 192.168.1.42 à la
rubrique "Server IP address"
Pour avoir ceinture et bretelles, j'ai créé une deuxième entrée en
choisissant custom, j'ai alors manuellement saisi le port 80, le
protocole "TCP/UDP" et dirigé ça à nouveau vers 192.168.1.42.
Problème: si je saisi "http://87.89.33.193" dans la barre d'adresse de
firefox, j'ai le message:
8<-----------8<---------8<----------8<----------8<----------8<----------8<
La connexion avec le serveur a été réinitialisée pendant le chargement
de la page.
8<-----------8<---------8<----------8<----------8<----------8<----------8<
Comment résoudre ce problème ?
Merci de votre aide
--
Windows: Microsoft's tax on computer illiterates.
Hugo (né il y a 1 339 865 795 secondes)
Chain OUTPUT (policy ACCEPT) target prot opt source destination DROP all -- anywhere 239.255.255.250
Ça fout la trouille... les trois chaînes de filtrage ont pour politique par défaut ACCEPT et la seule règle DROP est dans la chaîne OUTPUT !
Maintenant, que raconte "iptables -nvL -t nat" ?
Hugolino
Le Fri, 13 Oct 2006 10:45:12 +0200, Pascal Hambourg a écrit:
iptables -L
Chain INPUT (policy ACCEPT) [...]
Chain FORWARD (policy ACCEPT) [...]
Chain OUTPUT (policy ACCEPT) target prot opt source destination DROP all -- anywhere 239.255.255.250
Ça fout la trouille... les trois chaînes de filtrage ont pour politique par défaut ACCEPT et la seule règle DROP est dans la chaîne OUTPUT !
Je suis *nul* en iptable, je cherche encore une doc qui présente ça sans aucun pré-requis, un truc pour neuneu. En fait ma seule doc c'est d'essayer de comprendre les règles que je vois passer dans les forums comme par exemple celles que vous avez rédigées dans le fil " IPtable, vos conseils?", il y a 10 jours de ça.
Maintenant, que raconte "iptables -nvL -t nat" ?
Comme les lignes sont up peu longues, je mets ça ici: http://www.roulaize.fr/Need-Help/sortie-iptable.txt
-- <JX> je vais boire une adelscott <CleeK> jx : pareil pour moi <JX> et comme il ne faut JAMAIS boire le ventre vide <JX> je vais manger une Guinness avec
Le Fri, 13 Oct 2006 10:45:12 +0200, Pascal Hambourg a écrit:
iptables -L
Chain INPUT (policy ACCEPT)
[...]
Chain FORWARD (policy ACCEPT)
[...]
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere 239.255.255.250
Ça fout la trouille... les trois chaînes de filtrage ont pour politique
par défaut ACCEPT et la seule règle DROP est dans la chaîne OUTPUT !
Je suis *nul* en iptable, je cherche encore une doc qui présente ça sans
aucun pré-requis, un truc pour neuneu.
En fait ma seule doc c'est d'essayer de comprendre les règles que je vois
passer dans les forums comme par exemple celles que vous avez rédigées
dans le fil " IPtable, vos conseils?", il y a 10 jours de ça.
Maintenant, que raconte "iptables -nvL -t nat" ?
Comme les lignes sont up peu longues, je mets ça ici:
http://www.roulaize.fr/Need-Help/sortie-iptable.txt
--
<JX> je vais boire une adelscott
<CleeK> jx : pareil pour moi
<JX> et comme il ne faut JAMAIS boire le ventre vide
<JX> je vais manger une Guinness avec
Le Fri, 13 Oct 2006 10:45:12 +0200, Pascal Hambourg a écrit:
iptables -L
Chain INPUT (policy ACCEPT) [...]
Chain FORWARD (policy ACCEPT) [...]
Chain OUTPUT (policy ACCEPT) target prot opt source destination DROP all -- anywhere 239.255.255.250
Ça fout la trouille... les trois chaînes de filtrage ont pour politique par défaut ACCEPT et la seule règle DROP est dans la chaîne OUTPUT !
Je suis *nul* en iptable, je cherche encore une doc qui présente ça sans aucun pré-requis, un truc pour neuneu. En fait ma seule doc c'est d'essayer de comprendre les règles que je vois passer dans les forums comme par exemple celles que vous avez rédigées dans le fil " IPtable, vos conseils?", il y a 10 jours de ça.
Maintenant, que raconte "iptables -nvL -t nat" ?
Comme les lignes sont up peu longues, je mets ça ici: http://www.roulaize.fr/Need-Help/sortie-iptable.txt
-- <JX> je vais boire une adelscott <CleeK> jx : pareil pour moi <JX> et comme il ne faut JAMAIS boire le ventre vide <JX> je vais manger une Guinness avec
Pascal Hambourg
Je suis *nul* en iptable, je cherche encore une doc qui présente ça sans aucun pré-requis, un truc pour neuneu.
Comme j'ai les prérequis, je ne suis pas forcément le mieux placé pour te conseiller. J'ai commencé par les documentations présentées dans la section Documentation du site www.netfilter.org, en particulier les HOWTO filtrage et NAT, et le tutorial d'Oskar Andreasson. Tous existent en VF, mais pas forcément aussi à jour que les VO.
Maintenant, que raconte "iptables -nvL -t nat" ?
Comme les lignes sont up peu longues, je mets ça ici: http://www.roulaize.fr/Need-Help/sortie-iptable.txt
Bonne idée, ça évite de casser les lignes longues. Je constate aussi avec plaisir que la configuration du domaine a été corrigée.
J'écrivais récemment dans un liste de diffusion : === Le problème de la redirection NAT du LAN vers le LAN est un grand classique. Pour que ça marche, il faut que le dispositif qui fait le NAT remplisse plusieurs conditions supplémentaires par rapport au NAT classique entre WAN et LAN : 1) le NAT destination (redirection de port) doit être opérationnel sur les paquets qui entrent par l'interface LAN ; 2) le routage des paquets entrant et ressortant par l'interface LAN doit être opérationnel ; 3) le NAT source (masquerading) doit être actif sur les paquets qui entrent et ressortent par l'interface LAN (j'avais écrit WAN par erreur).
Les deux premières conditions sont évidentes. La troisième sert à faire en sorte que les paquets de réponse du serveur reviennent vers le routeur qui peut remettre l'adresse publique originale. Autrement le serveur enverrait la réponse avec son adresse privée directement au client qui attend une réponse de l'adresse publique. === La condition 1) n'est pas remplie puisque dans la chaîne PREROUTING les règles de redirection vers le LAN ne s'appliquent qu'à l'interface d'entrée côté WAN, qui semble être nommée "ppp_8_35_1". On va donc créer une règle qui s'applique à l'interface côté LAN qui semble être "br0" :
La condition 2) est remplie puisqu'il n'y a aucun filtrage dans FORWARD.
La condition 3) n'est pas remplie puisque dans la chaîne POSTROUTING la règle MASQUERADE ne s'applique qu'à l'interface côté WAN. On va donc en créer une qui s'applique à l'interface côté LAN :
L'option -s sert à ne pas masquer l'adresse source des paquets qui viennent de l'extérieur. On pourrait raffiner en utilisant SNAT au lieu de MASQUERADE puisque l'adresse côté LAN est fixe et connue, et en créant juste avant une règle sans NAT quand la source est l'adresse LAN de la box elle-même :
mais le résultat sera globalement identique dans les deux cas.
Ensuite, tu peux essayer d'accéder à http://87.89.33.193 depuis le LAN pour vérifier si ça marche.
Par contre, ces règles iptables additionnelles ne sont pas sauvegardées et ne seront pas restaurées automatiquement en cas de redémarrage de la box. Il se pourrait même qu'elles soient effacées à la déconnexion ou à la reconnexion PPP (entre la box et le FAI) suivante.
Je suis *nul* en iptable, je cherche encore une doc qui présente ça sans
aucun pré-requis, un truc pour neuneu.
Comme j'ai les prérequis, je ne suis pas forcément le mieux placé pour
te conseiller. J'ai commencé par les documentations présentées dans la
section Documentation du site www.netfilter.org, en particulier les
HOWTO filtrage et NAT, et le tutorial d'Oskar Andreasson. Tous existent
en VF, mais pas forcément aussi à jour que les VO.
Maintenant, que raconte "iptables -nvL -t nat" ?
Comme les lignes sont up peu longues, je mets ça ici:
http://www.roulaize.fr/Need-Help/sortie-iptable.txt
Bonne idée, ça évite de casser les lignes longues. Je constate aussi
avec plaisir que la configuration du domaine a été corrigée.
J'écrivais récemment dans un liste de diffusion :
=== Le problème de la redirection NAT du LAN vers le LAN est un grand
classique. Pour que ça marche, il faut que le dispositif qui fait le NAT
remplisse plusieurs conditions supplémentaires par rapport au NAT
classique entre WAN et LAN :
1) le NAT destination (redirection de port) doit être opérationnel sur
les paquets qui entrent par l'interface LAN ;
2) le routage des paquets entrant et ressortant par l'interface LAN doit
être opérationnel ;
3) le NAT source (masquerading) doit être actif sur les paquets qui
entrent et ressortent par l'interface LAN (j'avais écrit WAN par erreur).
Les deux premières conditions sont évidentes. La troisième sert à faire
en sorte que les paquets de réponse du serveur reviennent vers le
routeur qui peut remettre l'adresse publique originale. Autrement le
serveur enverrait la réponse avec son adresse privée directement au
client qui attend une réponse de l'adresse publique.
===
La condition 1) n'est pas remplie puisque dans la chaîne PREROUTING les
règles de redirection vers le LAN ne s'appliquent qu'à l'interface
d'entrée côté WAN, qui semble être nommée "ppp_8_35_1". On va donc créer
une règle qui s'applique à l'interface côté LAN qui semble être "br0" :
La condition 2) est remplie puisqu'il n'y a aucun filtrage dans FORWARD.
La condition 3) n'est pas remplie puisque dans la chaîne POSTROUTING la
règle MASQUERADE ne s'applique qu'à l'interface côté WAN. On va donc en
créer une qui s'applique à l'interface côté LAN :
L'option -s sert à ne pas masquer l'adresse source des paquets qui
viennent de l'extérieur. On pourrait raffiner en utilisant SNAT au lieu
de MASQUERADE puisque l'adresse côté LAN est fixe et connue, et en
créant juste avant une règle sans NAT quand la source est l'adresse LAN
de la box elle-même :
mais le résultat sera globalement identique dans les deux cas.
Ensuite, tu peux essayer d'accéder à http://87.89.33.193 depuis le LAN
pour vérifier si ça marche.
Par contre, ces règles iptables additionnelles ne sont pas sauvegardées
et ne seront pas restaurées automatiquement en cas de redémarrage de la
box. Il se pourrait même qu'elles soient effacées à la déconnexion ou à
la reconnexion PPP (entre la box et le FAI) suivante.
Je suis *nul* en iptable, je cherche encore une doc qui présente ça sans aucun pré-requis, un truc pour neuneu.
Comme j'ai les prérequis, je ne suis pas forcément le mieux placé pour te conseiller. J'ai commencé par les documentations présentées dans la section Documentation du site www.netfilter.org, en particulier les HOWTO filtrage et NAT, et le tutorial d'Oskar Andreasson. Tous existent en VF, mais pas forcément aussi à jour que les VO.
Maintenant, que raconte "iptables -nvL -t nat" ?
Comme les lignes sont up peu longues, je mets ça ici: http://www.roulaize.fr/Need-Help/sortie-iptable.txt
Bonne idée, ça évite de casser les lignes longues. Je constate aussi avec plaisir que la configuration du domaine a été corrigée.
J'écrivais récemment dans un liste de diffusion : === Le problème de la redirection NAT du LAN vers le LAN est un grand classique. Pour que ça marche, il faut que le dispositif qui fait le NAT remplisse plusieurs conditions supplémentaires par rapport au NAT classique entre WAN et LAN : 1) le NAT destination (redirection de port) doit être opérationnel sur les paquets qui entrent par l'interface LAN ; 2) le routage des paquets entrant et ressortant par l'interface LAN doit être opérationnel ; 3) le NAT source (masquerading) doit être actif sur les paquets qui entrent et ressortent par l'interface LAN (j'avais écrit WAN par erreur).
Les deux premières conditions sont évidentes. La troisième sert à faire en sorte que les paquets de réponse du serveur reviennent vers le routeur qui peut remettre l'adresse publique originale. Autrement le serveur enverrait la réponse avec son adresse privée directement au client qui attend une réponse de l'adresse publique. === La condition 1) n'est pas remplie puisque dans la chaîne PREROUTING les règles de redirection vers le LAN ne s'appliquent qu'à l'interface d'entrée côté WAN, qui semble être nommée "ppp_8_35_1". On va donc créer une règle qui s'applique à l'interface côté LAN qui semble être "br0" :
La condition 2) est remplie puisqu'il n'y a aucun filtrage dans FORWARD.
La condition 3) n'est pas remplie puisque dans la chaîne POSTROUTING la règle MASQUERADE ne s'applique qu'à l'interface côté WAN. On va donc en créer une qui s'applique à l'interface côté LAN :
L'option -s sert à ne pas masquer l'adresse source des paquets qui viennent de l'extérieur. On pourrait raffiner en utilisant SNAT au lieu de MASQUERADE puisque l'adresse côté LAN est fixe et connue, et en créant juste avant une règle sans NAT quand la source est l'adresse LAN de la box elle-même :
mais le résultat sera globalement identique dans les deux cas.
Ensuite, tu peux essayer d'accéder à http://87.89.33.193 depuis le LAN pour vérifier si ça marche.
Par contre, ces règles iptables additionnelles ne sont pas sauvegardées et ne seront pas restaurées automatiquement en cas de redémarrage de la box. Il se pourrait même qu'elles soient effacées à la déconnexion ou à la reconnexion PPP (entre la box et le FAI) suivante.
