(Courriels de diversion: <demarchent@classifions-vanteriez.com> <frola@cloner-parques.com> <subventionnerait@butins-cheques-restaurant.com> <murs@goberai-constituant.com> <caracterisee@embrouillements-compatirais.com> <neurologue@epinglee-faillit.com> <quadrillerai@commentions-carminee.com> <accuser@devaluerais-cambres.com> <edifierons@inexistence-assistais.com> <florins@embourgeoisement-hivernants.com> )
Netkiller a écrit :
| C'est une limitation classique des routeurs NAT domestiques et autres | box ADSL. c'est aussi le cas pour tout les firewall pro que je connaisse et on m'a toujours appris qu'aucun matériel digne de ce nom ne le fait (à vérifier).
C'est aussi ce que j'avais compris. La "tradition" ou la "normalité" avec IP est de ne pas permettre ce genre de routage. C'est comme demander un accès externe à son propre système : celui-ci va router vers l'extérieur et le premier routeur externe, qui voit arriver une demande de retour, ne va pas re-expédier la trame en sens inverse, mais va carrément la "dropper" car il détectera une erreur à ce niveau là. La trame n'aurait jamais du sortir du système emetteur.
Ce le fait sur les routeurs externes (chers) mais aussi par les routeurs internes (pas chers, les boxes adsl par exemple). Tout routeur se doit de bloquer tout retour à l'envoyeur quel qu'il soit. C'est en somme une "erreur système" à traiter en priorité.
| | Quelle idée aussi d'utiliser l'adresse IP, alors qu'avec un nom de | domaine il suffirait d'une ligne dans le fichier hosts des postes du LAN | associant l'adresse privée du serveur à ce nom de domaine. | |> Ma première question est... es-ce que, ce que j'essaie de faire porte un |> mon ? (à savoir un Port Forwarding d'une machine cliente de mon lan, ver |> une machine serveur de mon lan, en passant par l'ip publique de ma box) | | Certains appellent ça du "loopback" à cause du rebouclage de la | connexion du LAN vers le LAN. Pour ma part j'évite cette appellation à | cause du risque de confusion avec l'interface de loopback qui n'a rien à | voir. On peut aussi appeler ça une boucle (ça évite les risques de confusion)
aussi : retournement de ligne/route.
| |> (c'est un Port Forwarding classique, sans une option bloquante, semble |> t-il!) | | Non, ce n'est pas pas du port forwarding classique. L'interface d'entrée | est différente. Et pour que cela puisse fonctionner, il faut faire du | NAT source en plus du NAT destination. as tu déja testé ? comme ça de prime abord je ne vois pas comment ça peut marcher, tu sort sur l'interface web de ta machine avec iptables (on va l'appeler machine A) donc tu nat la source, du coup tu te retrouve avec l'ip public de la machine A et comme tu nat la destination tu lui dit d'aller sur la même ip source pour rentrer, pour moi tu fait encore une boucle. (j'ai perdu beaucoup de lecteurs ??? :) )
Attention aux déclarations firewallistiques forçant des configurations de boucles. Au moindre problème : ça peut rapidement provoquer unr augmentation du trafic exponentielle... et faire plantouiller une box mal configurée.
Prévoir une caisse complete de Paracetamol générique, et une palette de lotion apaisante spécifique aux cas de capilotraction...
| |> Ma deuxième question est... pour que cela fonctionne... quel paramètre |> est susceptible de faire fonctionner ? | | Ça dépend des paramètres à disposition. La box fait tourner un | mini-système basé sur Linux dont on peut manipuler les règles iptables ? Pour moi, soit tu utilise un nom dns, tu le crée sur internet avec ton ip public, et sur ton pc local tu renseigne ton fichier /etc/hosts en précisant l'ip local du serveur et le même nom dns, soit tu te connect avec l'ip local.
L'usage veut souvent que le DNS local règle ce genre de conflit/requis. On masque ses propres FDQNs vers des IPs internes. a+ ----------------------------------------------------------------- Les listes de diffusion du CULTe - Pour une informatique libre http://www.CULTe.org/listes/ Pour se desabonner: mailto:linux-31-unsubscribe@CULTe.org?subject=Cliquez_sur_ENVOYER