J'aimerai créer de "fausses" interfaces réseau sur ma machine avec
chacune une adresse IP et qui fonctionnerait localement comme fontionne lo0.
Typiquement, j'en ai 3 actuellement :
- ma carte vers le Net eth1 avec une IP publique
- ma carte vers mon réseau interne eth0 avec une IP privée
- le loopback lo0 127.0.0.1
J'aimerai en ajouter 2 ou 3 nouvelles : eth2, eth3, eth4, ou lo1, lo2,
lo3 et leur affecter une IP de manière à pouvoir localement les utiliser.
Je n'ai pas trouvé comment faire partout où j'ai cherché.
Merci
Laurent
PS : pour info, mon problème est que j'héberge plusieurs sites web sous
différents noms de domaine mais que apache, qui sait gérer les
virtualnamedhosts ne sait pas gérer un certificat SSL dans ce cas, il
lui faut une IP différente. Donc si j'arrive à rediriger ce qui entre
vers l'une ou l'autre de ces cartes, je devrais résoudre mon pb
Je ne voudrais pas te décevoir, mais tout ce qui est envoyé à destination d'une adresse locale passe par l'interface de loopback (lo), pas par l'interface qui a cette adresse (sauf si c'est déjà l'interface de loopback bien sûr). Regarde les compteurs TX/RX pour t'en convaincre. De plus, si je ne m'abuse, l'interface dummy est un trou noir à la /dev/null, donc aucune réponse au ping ne saurait en sortir.
Ben non, les interfaces dummy sont presque de vraies interfaces,
Ce sont de vraies interfaces, la question n'est pas là. Simplement, on peut y envoyer tout ce qu'on veut (dans ton cas, à destination de 10.0.0.0/8 sauf 10.0.0.42) mais on n'en recevra jamais rien. C'est un peu comme une interface ethernet sans rien à l'autre bout (mais sans ARP).
j'en suis presque sur: Essai de démonstration:
:~ $ ssh 10.0.0.42 [...]
Ça ne prouve rien de plus que le ping, tu causes toujours à l'interface de loopback.
Par contre, les compteurs semblent inputés à lo.
Et pour cause. Si tu veux faire une vraie vérification, désactive l'interface lo (éviter de faire ça sur une machine de prod)
# ifconfig lo down
ou bloque le trafic IP en entrée ou en sortie de lo avec iptables.
# iptables -t filter -I INPUT -i lo -j DROP # iptables -t filter -I OUTPUT -o lo -j DROP
Tu verras que ping ou ssh sur l'adresse de dummy0 ne passeront plus. Par contre, bloquer le trafic IP sur dummy0 avec iptables
# iptables -t filter -I INPUT -i dummy0 -j DROP # iptables -t filter -I OUTPUT -o dummy0 -j DROP
ne les empêche pas de passer.
On 2005-04-05, Pascal@plouf <pascal@plouf.invalid> wrote:
Je ne voudrais pas te décevoir, mais tout ce qui est envoyé à destination
d'une adresse locale passe par l'interface de loopback (lo), pas par
l'interface qui a cette adresse (sauf si c'est déjà l'interface de
loopback bien sûr). Regarde les compteurs TX/RX pour t'en convaincre. De
plus, si je ne m'abuse, l'interface dummy est un trou noir à la
/dev/null, donc aucune réponse au ping ne saurait en sortir.
Ben non, les interfaces dummy sont presque de vraies interfaces,
Ce sont de vraies interfaces, la question n'est pas là. Simplement, on
peut y envoyer tout ce qu'on veut (dans ton cas, à destination de
10.0.0.0/8 sauf 10.0.0.42) mais on n'en recevra jamais rien. C'est un
peu comme une interface ethernet sans rien à l'autre bout (mais sans ARP).
j'en suis presque sur: Essai de démonstration:
tboudet@mackerel:~ $ ssh 10.0.0.42
[...]
Ça ne prouve rien de plus que le ping, tu causes toujours à l'interface
de loopback.
Par contre, les compteurs semblent inputés à lo.
Et pour cause.
Si tu veux faire une vraie vérification, désactive l'interface lo
(éviter de faire ça sur une machine de prod)
# ifconfig lo down
ou bloque le trafic IP en entrée ou en sortie de lo avec iptables.
# iptables -t filter -I INPUT -i lo -j DROP
# iptables -t filter -I OUTPUT -o lo -j DROP
Tu verras que ping ou ssh sur l'adresse de dummy0 ne passeront plus. Par
contre, bloquer le trafic IP sur dummy0 avec iptables
# iptables -t filter -I INPUT -i dummy0 -j DROP
# iptables -t filter -I OUTPUT -o dummy0 -j DROP
Je ne voudrais pas te décevoir, mais tout ce qui est envoyé à destination d'une adresse locale passe par l'interface de loopback (lo), pas par l'interface qui a cette adresse (sauf si c'est déjà l'interface de loopback bien sûr). Regarde les compteurs TX/RX pour t'en convaincre. De plus, si je ne m'abuse, l'interface dummy est un trou noir à la /dev/null, donc aucune réponse au ping ne saurait en sortir.
Ben non, les interfaces dummy sont presque de vraies interfaces,
Ce sont de vraies interfaces, la question n'est pas là. Simplement, on peut y envoyer tout ce qu'on veut (dans ton cas, à destination de 10.0.0.0/8 sauf 10.0.0.42) mais on n'en recevra jamais rien. C'est un peu comme une interface ethernet sans rien à l'autre bout (mais sans ARP).
j'en suis presque sur: Essai de démonstration:
:~ $ ssh 10.0.0.42 [...]
Ça ne prouve rien de plus que le ping, tu causes toujours à l'interface de loopback.
Par contre, les compteurs semblent inputés à lo.
Et pour cause. Si tu veux faire une vraie vérification, désactive l'interface lo (éviter de faire ça sur une machine de prod)
# ifconfig lo down
ou bloque le trafic IP en entrée ou en sortie de lo avec iptables.
# iptables -t filter -I INPUT -i lo -j DROP # iptables -t filter -I OUTPUT -o lo -j DROP
Tu verras que ping ou ssh sur l'adresse de dummy0 ne passeront plus. Par contre, bloquer le trafic IP sur dummy0 avec iptables
# iptables -t filter -I INPUT -i dummy0 -j DROP # iptables -t filter -I OUTPUT -o dummy0 -j DROP
ne les empêche pas de passer.
Kevin Denis
On 2005-04-06, Thierry Boudet wrote:
J'aimerai créer de "fausses" interfaces réseau sur ma machine avec chacune une adresse IP et qui fonctionnerait localement comme fontionne lo0.
D'après de confus souvenirs, peut-être le comportement entre
lo et dummy est différent: genre sur lo, certains bits de l'@ip ne sont pas pris en compte.
Ah?
L'adresse lo est 127.0.0.1, mais de maniere theorique, toutes les adresses 127.a.b.c sont le loopback. (127: classe A, donc masque en /8)
PING 127.42.42.42 (127.42.42.42) 56(84) bytes of data. 64 bytes from 127.42.42.42: icmp_seq=1 ttld time=0.272 ms --- 127.42.42.42 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.272/0.272/0.272/0.000 ms
-- Kevin
On 2005-04-06, Thierry Boudet <tth@zouh.org> wrote:
J'aimerai créer de "fausses" interfaces réseau sur ma machine avec
chacune une adresse IP et qui fonctionnerait localement comme fontionne lo0.
D'après de confus souvenirs, peut-être le comportement entre
lo et dummy est différent: genre sur lo, certains bits de l'@ip
ne sont pas pris en compte.
Ah?
L'adresse lo est 127.0.0.1, mais de maniere theorique, toutes les
adresses 127.a.b.c sont le loopback. (127: classe A, donc masque en /8)
PING 127.42.42.42 (127.42.42.42) 56(84) bytes of data.
64 bytes from 127.42.42.42: icmp_seq=1 ttld time=0.272 ms
--- 127.42.42.42 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.272/0.272/0.272/0.000 ms
J'aimerai créer de "fausses" interfaces réseau sur ma machine avec chacune une adresse IP et qui fonctionnerait localement comme fontionne lo0.
D'après de confus souvenirs, peut-être le comportement entre
lo et dummy est différent: genre sur lo, certains bits de l'@ip ne sont pas pris en compte.
Ah?
L'adresse lo est 127.0.0.1, mais de maniere theorique, toutes les adresses 127.a.b.c sont le loopback. (127: classe A, donc masque en /8)
PING 127.42.42.42 (127.42.42.42) 56(84) bytes of data. 64 bytes from 127.42.42.42: icmp_seq=1 ttld time=0.272 ms --- 127.42.42.42 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.272/0.272/0.272/0.000 ms
-- Kevin
Laurent DECHER
Salut,
Je me disais qu'en envoyant avec squid tout ce qui rentre par mon IP sur le Net vers les ports 80 et 443 pour domaine1 sur une IP1 et tout ce qui rentre pour domaine2 vers une IP2, je pourrai ensuite écouter ces 2 interfaces avec apache avec des vhosts mais basés sur l'IP.
Non ? Où est-ce que je me gourre ?
Si je ne m'abuse, la négociation SSL a lieu avant l'envoi de la requête HTTP qui contient le nom du site, donc avant que le reverse proxy puisse savoir vers quelle adresse rediriger.
Je m'explique :
1. j'ai une IP x.x.x.x sur le Net d'où arrivent les requêtes HTTP/HTTPS jai 2 IP dumy, une y.y.y.y et une z.z.z.z 2. apache écoute sur y.y.y.y le domaine1 et le domaine2 sur z.z.z.z, rien sur 127.0.0.1 ni sur x.x.x.x donc là je peux gérer 3 certificats SSL autosignés. 3. avec Netfilter, je fais un proxy transparent sur les ports 443 et 80 de x.x.x.x vers le lo0 4. Et avec squid (je crois que c'est possible mais peut-être ai-je mal compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes respectivement pour domaine1 ou domaine2.
Je suis donc en amont de la négo SSL/TLS.
Maintenant je sais faire toutes les étapes sauf la 4 pour l'instant. Il y a 2 solutions : soit elle est possible et mon problème est résolu, soit pas et je vais pleurer.
Valà
Laurent
Salut,
Je me disais qu'en envoyant avec squid tout ce qui rentre par mon IP
sur le Net vers les ports 80 et 443 pour domaine1 sur une IP1 et tout
ce qui rentre pour domaine2 vers une IP2, je pourrai ensuite écouter
ces 2 interfaces avec apache avec des vhosts mais basés sur l'IP.
Non ? Où est-ce que je me gourre ?
Si je ne m'abuse, la négociation SSL a lieu avant l'envoi de la
requête HTTP qui contient le nom du site, donc avant que le reverse
proxy puisse savoir vers quelle adresse rediriger.
Je m'explique :
1.
j'ai une IP x.x.x.x sur le Net d'où arrivent les requêtes HTTP/HTTPS
jai 2 IP dumy, une y.y.y.y et une z.z.z.z
2.
apache écoute sur y.y.y.y le domaine1 et le domaine2 sur z.z.z.z, rien
sur 127.0.0.1 ni sur x.x.x.x
donc là je peux gérer 3 certificats SSL autosignés.
3.
avec Netfilter, je fais un proxy transparent sur les ports 443 et 80 de
x.x.x.x vers le lo0
4.
Et avec squid (je crois que c'est possible mais peut-être ai-je mal
compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes
respectivement pour domaine1 ou domaine2.
Je suis donc en amont de la négo SSL/TLS.
Maintenant je sais faire toutes les étapes sauf la 4 pour l'instant.
Il y a 2 solutions : soit elle est possible et mon problème est résolu,
soit pas et je vais pleurer.
Je me disais qu'en envoyant avec squid tout ce qui rentre par mon IP sur le Net vers les ports 80 et 443 pour domaine1 sur une IP1 et tout ce qui rentre pour domaine2 vers une IP2, je pourrai ensuite écouter ces 2 interfaces avec apache avec des vhosts mais basés sur l'IP.
Non ? Où est-ce que je me gourre ?
Si je ne m'abuse, la négociation SSL a lieu avant l'envoi de la requête HTTP qui contient le nom du site, donc avant que le reverse proxy puisse savoir vers quelle adresse rediriger.
Je m'explique :
1. j'ai une IP x.x.x.x sur le Net d'où arrivent les requêtes HTTP/HTTPS jai 2 IP dumy, une y.y.y.y et une z.z.z.z 2. apache écoute sur y.y.y.y le domaine1 et le domaine2 sur z.z.z.z, rien sur 127.0.0.1 ni sur x.x.x.x donc là je peux gérer 3 certificats SSL autosignés. 3. avec Netfilter, je fais un proxy transparent sur les ports 443 et 80 de x.x.x.x vers le lo0 4. Et avec squid (je crois que c'est possible mais peut-être ai-je mal compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes respectivement pour domaine1 ou domaine2.
Je suis donc en amont de la négo SSL/TLS.
Maintenant je sais faire toutes les étapes sauf la 4 pour l'instant. Il y a 2 solutions : soit elle est possible et mon problème est résolu, soit pas et je vais pleurer.
Valà
Laurent
Nicolas George
Laurent DECHER wrote in message <425414a0$0$13811$:
4. Et avec squid (je crois que c'est possible mais peut-être ai-je mal compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes respectivement pour domaine1 ou domaine2.
Je suis donc en amont de la négo SSL/TLS.
Sauf que ça ne marche pas. De deux choses l'une : soit squid est lui-même l'extrémité du tuyau TLS, et dans ce cas c'est son certificat qui est vu, et ce n'est pas ce qu'on veut ; soit squid n'est pas l'extrémité du tuyau TLS, et dans ce cas il n'a pas l'information pour savoir à quel serveur faire suivre la requête.
Il faut t'y faire : le name-based virtual hosting est fondamentalement impossible en présence de TLS de base.
Laurent DECHER wrote in message
<425414a0$0$13811$626a14ce@news.free.fr>:
4.
Et avec squid (je crois que c'est possible mais peut-être ai-je mal
compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes
respectivement pour domaine1 ou domaine2.
Je suis donc en amont de la négo SSL/TLS.
Sauf que ça ne marche pas. De deux choses l'une : soit squid est lui-même
l'extrémité du tuyau TLS, et dans ce cas c'est son certificat qui est vu, et
ce n'est pas ce qu'on veut ; soit squid n'est pas l'extrémité du tuyau TLS,
et dans ce cas il n'a pas l'information pour savoir à quel serveur faire
suivre la requête.
Il faut t'y faire : le name-based virtual hosting est fondamentalement
impossible en présence de TLS de base.
Laurent DECHER wrote in message <425414a0$0$13811$:
4. Et avec squid (je crois que c'est possible mais peut-être ai-je mal compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes respectivement pour domaine1 ou domaine2.
Je suis donc en amont de la négo SSL/TLS.
Sauf que ça ne marche pas. De deux choses l'une : soit squid est lui-même l'extrémité du tuyau TLS, et dans ce cas c'est son certificat qui est vu, et ce n'est pas ce qu'on veut ; soit squid n'est pas l'extrémité du tuyau TLS, et dans ce cas il n'a pas l'information pour savoir à quel serveur faire suivre la requête.
Il faut t'y faire : le name-based virtual hosting est fondamentalement impossible en présence de TLS de base.
Laurent DECHER
Laurent DECHER wrote in message <425414a0$0$13811$:
4. Et avec squid (je crois que c'est possible mais peut-être ai-je mal compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes respectivement pour domaine1 ou domaine2.
Je suis donc en amont de la négo SSL/TLS.
Sauf que ça ne marche pas. De deux choses l'une : soit squid est lui-même l'extrémité du tuyau TLS, et dans ce cas c'est son certificat qui est vu, et ce n'est pas ce qu'on veut ; soit squid n'est pas l'extrémité du tuyau TLS, et dans ce cas il n'a pas l'information pour savoir à quel serveur faire suivre la requête.
Il faut t'y faire : le name-based virtual hosting est fondamentalement impossible en présence de TLS de base.
OK, j'me rends et je vais pleurer
Laurent DECHER wrote in message
<425414a0$0$13811$626a14ce@news.free.fr>:
4.
Et avec squid (je crois que c'est possible mais peut-être ai-je mal
compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes
respectivement pour domaine1 ou domaine2.
Je suis donc en amont de la négo SSL/TLS.
Sauf que ça ne marche pas. De deux choses l'une : soit squid est lui-même
l'extrémité du tuyau TLS, et dans ce cas c'est son certificat qui est vu, et
ce n'est pas ce qu'on veut ; soit squid n'est pas l'extrémité du tuyau TLS,
et dans ce cas il n'a pas l'information pour savoir à quel serveur faire
suivre la requête.
Il faut t'y faire : le name-based virtual hosting est fondamentalement
impossible en présence de TLS de base.
Laurent DECHER wrote in message <425414a0$0$13811$:
4. Et avec squid (je crois que c'est possible mais peut-être ai-je mal compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes respectivement pour domaine1 ou domaine2.
Je suis donc en amont de la négo SSL/TLS.
Sauf que ça ne marche pas. De deux choses l'une : soit squid est lui-même l'extrémité du tuyau TLS, et dans ce cas c'est son certificat qui est vu, et ce n'est pas ce qu'on veut ; soit squid n'est pas l'extrémité du tuyau TLS, et dans ce cas il n'a pas l'information pour savoir à quel serveur faire suivre la requête.
Il faut t'y faire : le name-based virtual hosting est fondamentalement impossible en présence de TLS de base.
OK, j'me rends et je vais pleurer
Thierry Boudet
On 2005-04-06, Laurent DECHER wrote:
4. Et avec squid (je crois que c'est possible mais peut-être ai-je mal compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes respectivement pour domaine1 ou domaine2.
le tag Host: de la requête http qui permettra éventuellement
à squid de trier arrive _après_ la négociation ssl.
Je suis donc en amont de la négo SSL/TLS.
Je ne pense pas... Foutou là-bas.
-- _/°< coin
On 2005-04-06, Laurent DECHER <laurent@familledecher.com> wrote:
4.
Et avec squid (je crois que c'est possible mais peut-être ai-je mal
compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes
respectivement pour domaine1 ou domaine2.
le tag Host: de la requête http qui permettra éventuellement
à squid de trier arrive _après_ la négociation ssl.
4. Et avec squid (je crois que c'est possible mais peut-être ai-je mal compris la doc), je redirige vers y.y.y.y ou z.z.z.z les requêtes respectivement pour domaine1 ou domaine2.
le tag Host: de la requête http qui permettra éventuellement
à squid de trier arrive _après_ la négociation ssl.
