Bonjour,
Mon probleme est quelque-peu particulier : je suis actuellement en train
de developper une solution de routeur pour de l'internet par satellite
dans des avions.
Sur le routeur tourne un linux.
Ce linux gere les canaux a internet (2 canaux de 64k avec possibilite
d'aggregation pour disposer de 128k).
Sur ce routeur, j'ai fait une interface web permettant notamment
d'activer ou de desactiver l'acces a internet (car a 10$ la minute par
canal ouvert, on veut pouvoir facilement controler l'etat de la connexion).
Mon but maintenant est de faire en sorte que, si l'acces a internet est
desactive, alors toute requete web sortante aboutira sur la page de
gestion des canaux.
En gros, pour faire simple, je suis en train de developper un HotSpot
tel qu'on en trouve deja tout faits tel que ChilliSpot ou NoCat.
Le seul probleme c'est que ces logiciels sont plutot concus pour
fonctionner sur une connexion haut debit type ADSL, et donc permanente,
ce qui ne peut pas etre mon cas.
J'ai donc bien pu faire en sorte de redirriger toutes les requetes
sortant sur le port 80 vers mon serveur web interne, donc toute requete
vers une adresse IP externe aboutit systematiquement sur la page de
gestion des canaux.
Mon probleme se situe au niveau des DNS. En effet, lorsque sur un PC qui
accede a la connexion, on met une adresse DNS alors que la connexion est
desactivee, ce PC va tout d'abord tenter de resoudre le nom. Cette
requete va echouer et donc on aura une jolie erreur.
Je cherche donc un moyen de faire en sorte que quand on bloque l'acces a
internet via la page, on puisse du meme coup mettre en place un systeme
qui fasse systematiquement tout resoudre sur l'IP du routeur. J'ai bien
trouve quelques petits trucs, notamment dnshijacker qui permet de faire
cela mais cela pose de gros problemes de cache apres et ca ne me
convient pas vraiment.
Si vous voyez une solution pour faire un hotspot sachant faire cela
correctement, je suis tres interesse par votre idee ;-)
N.B. : Le routeur dispose d'un Bind configure en serveur DNS cache.
Oui, j'ai deja developpe une solution comme cela, cependant ca n'est pas satisfaisant car il faut que le pc ait le proxy configure, or, on veut que le splashscreen apparaisse sur nimporte quel PC sans imposer que le PC ait une quelconque config specifique. La solution de rendre le proxy transparent ne fonctionne pas non plus etant donne que dans ce cas, le navigateur considere qu'il n'y a pas de proxy et la resolution va se faire directement avec le resolveur de la machine au lieu que cela soit le proxy qui la fasse. Je pense deja avoir tourne la solution avec un proxy dans tous les sens, je ne trouve pas de solution qui me convienne...
je suppose que tu a aussi déployé un serveur DHCP pour que ton homme
d'affaire n'ai _rien_ à configurer quand il veut se connecter... Dans ce cas, ton serveur DHCP doit configurer sur le poste client : - la passerelle par défaut, - le serveur DNS, - le domaine de recherche par défaut
Ton serveur DNS, quant à lui doit renseigner le FQDN wpad.[mon_domain_par_défaut]
Tu dois aussi avoir un serveur ouaibe avec un VirtualDomain wpad. [mon_domain_par_défaut] De façon à configurer le proxy.
amha, pour ce que tu veux faire, point de salut sans proxy !
-- Rico
Francois Goudal <francois_nospam_@goudal.net> wrote in
news:44f6da9d$0$18627$626a54ce@news.free.fr:
Oui, j'ai deja developpe une solution comme cela, cependant ca n'est
pas satisfaisant car il faut que le pc ait le proxy configure, or, on
veut que le splashscreen apparaisse sur nimporte quel PC sans imposer
que le PC ait une quelconque config specifique.
La solution de rendre le proxy transparent ne fonctionne pas non plus
etant donne que dans ce cas, le navigateur considere qu'il n'y a pas
de proxy et la resolution va se faire directement avec le resolveur de
la machine au lieu que cela soit le proxy qui la fasse.
Je pense deja avoir tourne la solution avec un proxy dans tous les
sens, je ne trouve pas de solution qui me convienne...
je suppose que tu a aussi déployé un serveur DHCP pour que ton homme
d'affaire n'ai _rien_ à configurer quand il veut se connecter... Dans ce
cas, ton serveur DHCP doit configurer sur le poste client :
- la passerelle par défaut,
- le serveur DNS,
- le domaine de recherche par défaut
Ton serveur DNS, quant à lui doit renseigner le FQDN
wpad.[mon_domain_par_défaut]
Tu dois aussi avoir un serveur ouaibe avec un VirtualDomain wpad.
[mon_domain_par_défaut]
De façon à configurer le proxy.
amha, pour ce que tu veux faire, point de salut sans proxy !
Oui, j'ai deja developpe une solution comme cela, cependant ca n'est pas satisfaisant car il faut que le pc ait le proxy configure, or, on veut que le splashscreen apparaisse sur nimporte quel PC sans imposer que le PC ait une quelconque config specifique. La solution de rendre le proxy transparent ne fonctionne pas non plus etant donne que dans ce cas, le navigateur considere qu'il n'y a pas de proxy et la resolution va se faire directement avec le resolveur de la machine au lieu que cela soit le proxy qui la fasse. Je pense deja avoir tourne la solution avec un proxy dans tous les sens, je ne trouve pas de solution qui me convienne...
je suppose que tu a aussi déployé un serveur DHCP pour que ton homme
d'affaire n'ai _rien_ à configurer quand il veut se connecter... Dans ce cas, ton serveur DHCP doit configurer sur le poste client : - la passerelle par défaut, - le serveur DNS, - le domaine de recherche par défaut
Ton serveur DNS, quant à lui doit renseigner le FQDN wpad.[mon_domain_par_défaut]
Tu dois aussi avoir un serveur ouaibe avec un VirtualDomain wpad. [mon_domain_par_défaut] De façon à configurer le proxy.
amha, pour ce que tu veux faire, point de salut sans proxy !
-- Rico
Eric Belhomme
=?iso-8859-15?Q?Sébastien_Monbrun_aka_TiChou?= wrote in news::
Une idée comme ça : au niveau IP rediriger toutes les requetes DNS vers une autre adresse IP locale et sur laquelle BIND écouterait aussi. Ensuite, utiliser les « views » de BIND et l'option match-destinations. Sur la view par défaut, une zone hint normale. Sur la view secondaire, une zone hint avec un wildcard qui résoudra tout sur l'adresse IP de votre Splashscreen, comme par exemple :
le probleme etant pour bind de savoir _quand_ une requete devrait être
réellement résolue...
-- Rico
=?iso-8859-15?Q?Sébastien_Monbrun_aka_TiChou?= <gro.uohcit@uohcit>
wrote in news:bzium.20060831144643@florizarre.tichou.org:
Une idée comme ça : au niveau IP rediriger toutes les requetes DNS
vers une autre adresse IP locale et sur laquelle BIND écouterait
aussi. Ensuite, utiliser les « views » de BIND et l'option
match-destinations. Sur la view par défaut, une zone hint normale. Sur
la view secondaire, une zone hint avec un wildcard qui résoudra tout
sur l'adresse IP de votre Splashscreen, comme par exemple :
le probleme etant pour bind de savoir _quand_ une requete devrait être
=?iso-8859-15?Q?Sébastien_Monbrun_aka_TiChou?= wrote in news::
Une idée comme ça : au niveau IP rediriger toutes les requetes DNS vers une autre adresse IP locale et sur laquelle BIND écouterait aussi. Ensuite, utiliser les « views » de BIND et l'option match-destinations. Sur la view par défaut, une zone hint normale. Sur la view secondaire, une zone hint avec un wildcard qui résoudra tout sur l'adresse IP de votre Splashscreen, comme par exemple :
le probleme etant pour bind de savoir _quand_ une requete devrait être
réellement résolue...
-- Rico
Sébastien Monbrun aka TiChou
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
amha, pour ce que tu veux faire, point de salut sans proxy !
Ses besoins sont que :
1) toutes les requêtes Web doivent aboutir à une page de son serveur Web local ; 2) toutes les requêtes DNS doivent résoudre sur l'adresse de son serveur Web.
Pour le 1), une règle DNAT sur la passerelle pour rediriger le trafic IP à destination du port 80 vers l'adresse locale de la machine et un serveur Web avec une page par défaut (pas besoin de VirtualHost).
Pour le 2), une règle DNAT sur la passerelle pour rediriger les requêtes DNS vers un serveur DNS local qui les résoudra systématiquement sur la même adresse (voir la solution que j'ai proposé).
Pour cela, nullement besoin d'un proxy.
-- Sébastien Monbrun aka TiChou
Dans le message <news:Xns9830AE9AADD80ericbelhommefreefr@212.27.42.202>,
*Eric Belhomme* tapota sur f.c.o.l.configuration :
amha, pour ce que tu veux faire, point de salut sans proxy !
Ses besoins sont que :
1) toutes les requêtes Web doivent aboutir à une page de son serveur Web
local ;
2) toutes les requêtes DNS doivent résoudre sur l'adresse de son serveur
Web.
Pour le 1), une règle DNAT sur la passerelle pour rediriger le trafic IP à
destination du port 80 vers l'adresse locale de la machine et un serveur Web
avec une page par défaut (pas besoin de VirtualHost).
Pour le 2), une règle DNAT sur la passerelle pour rediriger les requêtes DNS
vers un serveur DNS local qui les résoudra systématiquement sur la même
adresse (voir la solution que j'ai proposé).
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
amha, pour ce que tu veux faire, point de salut sans proxy !
Ses besoins sont que :
1) toutes les requêtes Web doivent aboutir à une page de son serveur Web local ; 2) toutes les requêtes DNS doivent résoudre sur l'adresse de son serveur Web.
Pour le 1), une règle DNAT sur la passerelle pour rediriger le trafic IP à destination du port 80 vers l'adresse locale de la machine et un serveur Web avec une page par défaut (pas besoin de VirtualHost).
Pour le 2), une règle DNAT sur la passerelle pour rediriger les requêtes DNS vers un serveur DNS local qui les résoudra systématiquement sur la même adresse (voir la solution que j'ai proposé).
Pour cela, nullement besoin d'un proxy.
-- Sébastien Monbrun aka TiChou
Sébastien Monbrun aka TiChou
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
le probleme etant pour bind de savoir _quand_ une requete devrait être réellement résolue...
Ce n'est pas à BIND de se soucier de ça. C'est exactement le même problème pour la redirection Web vers le serveur Web local. Si l'accès Internet est désactivé, deux règles DNAT à placer, une pour le trafic Web, l'autre pour le trafic DNS. Si l'accès Internet est (ré)activé, suppression des deux règles DNAT.
-- Sébastien Monbrun aka TiChou
Dans le message <news:Xns9830AFA534FCEericbelhommefreefr@212.27.42.202>,
*Eric Belhomme* tapota sur f.c.o.l.configuration :
le probleme etant pour bind de savoir _quand_ une requete devrait être
réellement résolue...
Ce n'est pas à BIND de se soucier de ça. C'est exactement le même problème
pour la redirection Web vers le serveur Web local. Si l'accès Internet est
désactivé, deux règles DNAT à placer, une pour le trafic Web, l'autre pour
le trafic DNS. Si l'accès Internet est (ré)activé, suppression des deux
règles DNAT.
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
le probleme etant pour bind de savoir _quand_ une requete devrait être réellement résolue...
Ce n'est pas à BIND de se soucier de ça. C'est exactement le même problème pour la redirection Web vers le serveur Web local. Si l'accès Internet est désactivé, deux règles DNAT à placer, une pour le trafic Web, l'autre pour le trafic DNS. Si l'accès Internet est (ré)activé, suppression des deux règles DNAT.
-- Sébastien Monbrun aka TiChou
Francois Goudal
Sébastien Monbrun aka TiChou wrote:
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
le probleme etant pour bind de savoir _quand_ une requete devrait être réellement résolue...
Ce n'est pas à BIND de se soucier de ça. C'est exactement le même
Tout a fait
problème pour la redirection Web vers le serveur Web local. Si l'accès Internet est désactivé, deux règles DNAT à placer, une pour le trafic Web, l'autre pour le trafic DNS. Si l'accès Internet est (ré)activé, suppression des deux règles DNAT.
A vrai dire, j'ai deja essaye cette solution aussi mais comme je l'ai dit, une adresse resolue est mise en cache et donc ca ne marche pas vraiment : si je met le TTL de mon DNS fake au minimum, effectivement, quand on va sur google, par exemple, on tombe sur le splashscreen, on active internet, immediatement apres, on peut a priori retaper google et on y arrive bien, mais a ce moment la, la vraie IP de google est mise en cache. Par consequent, si un utilisateur rebloque l'acces a internet, on va continuer pendant beaucoup trop longtemps a resoudre sur l'IP reelle et non pas l'IP "fakee" via notre DNS.
En fait, ce qu'il faudrait au niveau de mon Bind, lorsqu'il fonctionne simplement comme un relais DNS, c'est qu'il "reecrive" les reponses que lui fournissent les serveurs DNS du FAI pour changer leur TTL et le reduire au maximum, le tout en ne gardant bien evidemment rien en cache... C'est possible ?
Dans le message <news:Xns9830AFA534FCEericbelhommefreefr@212.27.42.202>,
*Eric Belhomme* tapota sur f.c.o.l.configuration :
le probleme etant pour bind de savoir _quand_ une requete devrait être
réellement résolue...
Ce n'est pas à BIND de se soucier de ça. C'est exactement le même
Tout a fait
problème pour la redirection Web vers le serveur Web local. Si l'accès
Internet est désactivé, deux règles DNAT à placer, une pour le trafic
Web, l'autre pour le trafic DNS. Si l'accès Internet est (ré)activé,
suppression des deux règles DNAT.
A vrai dire, j'ai deja essaye cette solution aussi mais comme je l'ai
dit, une adresse resolue est mise en cache et donc ca ne marche pas
vraiment : si je met le TTL de mon DNS fake au minimum, effectivement,
quand on va sur google, par exemple, on tombe sur le splashscreen, on
active internet, immediatement apres, on peut a priori retaper google et
on y arrive bien, mais a ce moment la, la vraie IP de google est mise en
cache. Par consequent, si un utilisateur rebloque l'acces a internet, on
va continuer pendant beaucoup trop longtemps a resoudre sur l'IP reelle
et non pas l'IP "fakee" via notre DNS.
En fait, ce qu'il faudrait au niveau de mon Bind, lorsqu'il fonctionne
simplement comme un relais DNS, c'est qu'il "reecrive" les reponses que
lui fournissent les serveurs DNS du FAI pour changer leur TTL et le
reduire au maximum, le tout en ne gardant bien evidemment rien en cache...
C'est possible ?
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
le probleme etant pour bind de savoir _quand_ une requete devrait être réellement résolue...
Ce n'est pas à BIND de se soucier de ça. C'est exactement le même
Tout a fait
problème pour la redirection Web vers le serveur Web local. Si l'accès Internet est désactivé, deux règles DNAT à placer, une pour le trafic Web, l'autre pour le trafic DNS. Si l'accès Internet est (ré)activé, suppression des deux règles DNAT.
A vrai dire, j'ai deja essaye cette solution aussi mais comme je l'ai dit, une adresse resolue est mise en cache et donc ca ne marche pas vraiment : si je met le TTL de mon DNS fake au minimum, effectivement, quand on va sur google, par exemple, on tombe sur le splashscreen, on active internet, immediatement apres, on peut a priori retaper google et on y arrive bien, mais a ce moment la, la vraie IP de google est mise en cache. Par consequent, si un utilisateur rebloque l'acces a internet, on va continuer pendant beaucoup trop longtemps a resoudre sur l'IP reelle et non pas l'IP "fakee" via notre DNS.
En fait, ce qu'il faudrait au niveau de mon Bind, lorsqu'il fonctionne simplement comme un relais DNS, c'est qu'il "reecrive" les reponses que lui fournissent les serveurs DNS du FAI pour changer leur TTL et le reduire au maximum, le tout en ne gardant bien evidemment rien en cache... C'est possible ?
On Thu, 31 Aug 2006 14:59:29 +0200, Francois Goudal :
Les PC clients sont souvent sous windows, et peuvent eventuellement avoir des logiciels qui pourraient tenter regulierement des connexions (windows le fait lui meme deja, pour se mettre a jour...)
Déjà, "null-router" (i.e. adresse IP = 127.0.0.1) tous les serveurs de Windows update, de mise à jour de logiciels (anti-virus par exemple), etc., devrait éviter des connexions inutiles, tout en réduisant la charge sur le serveur.
Windows update est deja resolu en 127.0.0.1 bien evidemment Mais ceci est loin d'etre suffisant, les PC clients pourraient eventuellement etre infectes par des virus ou autres pourritures pouvant generer des connexions sortantes, et on ne peut par consequent pas considerer que les pc clients ne generent pas de traffic a repetition, il me faut vraiment une solution de blocage direct au niveau du routeur. Ensuite le splashscreen serait vraiment bien si on trouve une solution qui marche. Actuellement, il y a deja une solution fonctionnelle avec un proxy, mais etant donne que dans les avions, on est susceptible d'avoir des "invites", on ne peut absolument pas compter sur une configuration de proxy dans les pc clients.
On Thu, 31 Aug 2006 14:59:29 +0200, Francois Goudal
<francois_nospam_@goudal.net>:
Les PC clients sont souvent sous windows, et peuvent
eventuellement avoir des logiciels qui pourraient tenter regulierement
des connexions (windows le fait lui meme deja, pour se mettre a jour...)
Déjà, "null-router" (i.e. adresse IP = 127.0.0.1) tous les serveurs de
Windows update, de mise à jour de logiciels (anti-virus par exemple),
etc., devrait éviter des connexions inutiles, tout en réduisant la
charge sur le serveur.
Windows update est deja resolu en 127.0.0.1 bien evidemment
Mais ceci est loin d'etre suffisant, les PC clients pourraient
eventuellement etre infectes par des virus ou autres pourritures pouvant
generer des connexions sortantes, et on ne peut par consequent pas
considerer que les pc clients ne generent pas de traffic a repetition,
il me faut vraiment une solution de blocage direct au niveau du routeur.
Ensuite le splashscreen serait vraiment bien si on trouve une solution
qui marche.
Actuellement, il y a deja une solution fonctionnelle avec un proxy, mais
etant donne que dans les avions, on est susceptible d'avoir des
"invites", on ne peut absolument pas compter sur une configuration de
proxy dans les pc clients.
On Thu, 31 Aug 2006 14:59:29 +0200, Francois Goudal :
Les PC clients sont souvent sous windows, et peuvent eventuellement avoir des logiciels qui pourraient tenter regulierement des connexions (windows le fait lui meme deja, pour se mettre a jour...)
Déjà, "null-router" (i.e. adresse IP = 127.0.0.1) tous les serveurs de Windows update, de mise à jour de logiciels (anti-virus par exemple), etc., devrait éviter des connexions inutiles, tout en réduisant la charge sur le serveur.
Windows update est deja resolu en 127.0.0.1 bien evidemment Mais ceci est loin d'etre suffisant, les PC clients pourraient eventuellement etre infectes par des virus ou autres pourritures pouvant generer des connexions sortantes, et on ne peut par consequent pas considerer que les pc clients ne generent pas de traffic a repetition, il me faut vraiment une solution de blocage direct au niveau du routeur. Ensuite le splashscreen serait vraiment bien si on trouve une solution qui marche. Actuellement, il y a deja une solution fonctionnelle avec un proxy, mais etant donne que dans les avions, on est susceptible d'avoir des "invites", on ne peut absolument pas compter sur une configuration de proxy dans les pc clients.
Il commence par une requête DNS ; le serveur lui donne une adresse qui n'a pas encore été utilisée, comme 10.42.54.1
Bien entendu, la durée de vie est calculée pour que l'adresse expire à l'atterrissage.
C'est une solution que je n'avais pas envisagee, certes peut etre un peu bourrin et pas tout simple a mettre en place, mais ca aurait le merite de fonctionner. J'essaierai d'y reflechir si je ne trouve pas de meilleure solution d'ici la.
Il commence par une requête DNS ; le serveur lui donne une adresse qui
n'a pas encore été utilisée, comme 10.42.54.1
Bien entendu, la durée de vie est calculée pour que l'adresse expire à
l'atterrissage.
C'est une solution que je n'avais pas envisagee, certes peut etre un peu
bourrin et pas tout simple a mettre en place, mais ca aurait le merite
de fonctionner.
J'essaierai d'y reflechir si je ne trouve pas de meilleure solution
d'ici la.
Il commence par une requête DNS ; le serveur lui donne une adresse qui n'a pas encore été utilisée, comme 10.42.54.1
Bien entendu, la durée de vie est calculée pour que l'adresse expire à l'atterrissage.
C'est une solution que je n'avais pas envisagee, certes peut etre un peu bourrin et pas tout simple a mettre en place, mais ca aurait le merite de fonctionner. J'essaierai d'y reflechir si je ne trouve pas de meilleure solution d'ici la.
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
amha, pour ce que tu veux faire, point de salut sans proxy !
Ses besoins sont que :
1) toutes les requêtes Web doivent aboutir à une page de son serveur Web local ; 2) toutes les requêtes DNS doivent résoudre sur l'adresse de son serveur Web.
Pour le 1), une règle DNAT sur la passerelle pour rediriger le trafic IP à destination du port 80 vers l'adresse locale de la machine et un serveur Web avec une page par défaut (pas besoin de VirtualHost).
Pour le 2), une règle DNAT sur la passerelle pour rediriger les requêtes DNS vers un serveur DNS local qui les résoudra systématiquement sur la même adresse (voir la solution que j'ai proposé).
Pour cela, nullement besoin d'un proxy.
Oui mais problemes de TTL, cf mon post precedent. Sinon dans l'idee, oui c'est plutot vers cela que je me suis oriente aussi, mais toujours ce probleme avec le TTL... Si quelqu'un sait comment faire un "proxy DNS" qui puisse changer a la volee les TTL dans les reponses qu'il retransmet, ca pourrait marcher tres bien.
Dans le message <news:Xns9830AE9AADD80ericbelhommefreefr@212.27.42.202>,
*Eric Belhomme* tapota sur f.c.o.l.configuration :
amha, pour ce que tu veux faire, point de salut sans proxy !
Ses besoins sont que :
1) toutes les requêtes Web doivent aboutir à une page de son serveur
Web local ;
2) toutes les requêtes DNS doivent résoudre sur l'adresse de son
serveur Web.
Pour le 1), une règle DNAT sur la passerelle pour rediriger le trafic IP
à destination du port 80 vers l'adresse locale de la machine et un
serveur Web avec une page par défaut (pas besoin de VirtualHost).
Pour le 2), une règle DNAT sur la passerelle pour rediriger les requêtes
DNS vers un serveur DNS local qui les résoudra systématiquement sur la
même adresse (voir la solution que j'ai proposé).
Pour cela, nullement besoin d'un proxy.
Oui mais problemes de TTL, cf mon post precedent.
Sinon dans l'idee, oui c'est plutot vers cela que je me suis oriente
aussi, mais toujours ce probleme avec le TTL...
Si quelqu'un sait comment faire un "proxy DNS" qui puisse changer a la
volee les TTL dans les reponses qu'il retransmet, ca pourrait marcher
tres bien.
Dans le message <news:, *Eric Belhomme* tapota sur f.c.o.l.configuration :
amha, pour ce que tu veux faire, point de salut sans proxy !
Ses besoins sont que :
1) toutes les requêtes Web doivent aboutir à une page de son serveur Web local ; 2) toutes les requêtes DNS doivent résoudre sur l'adresse de son serveur Web.
Pour le 1), une règle DNAT sur la passerelle pour rediriger le trafic IP à destination du port 80 vers l'adresse locale de la machine et un serveur Web avec une page par défaut (pas besoin de VirtualHost).
Pour le 2), une règle DNAT sur la passerelle pour rediriger les requêtes DNS vers un serveur DNS local qui les résoudra systématiquement sur la même adresse (voir la solution que j'ai proposé).
Pour cela, nullement besoin d'un proxy.
Oui mais problemes de TTL, cf mon post precedent. Sinon dans l'idee, oui c'est plutot vers cela que je me suis oriente aussi, mais toujours ce probleme avec le TTL... Si quelqu'un sait comment faire un "proxy DNS" qui puisse changer a la volee les TTL dans les reponses qu'il retransmet, ca pourrait marcher tres bien.
On Thu, 31 Aug 2006 14:48:25 +0200, Francois Goudal :
Oui lol, [...] Ah non lol, [...]
Attention, tu es atteint de lolisme. C'est une maladie assez grave,
Je ne trouve pas que cela soit si grave que cela, je n'en suis pas non plus aux kikooooo lol mdrrr asv bisooo++ j t kif que l'on peut trouver sur pas mal de chats et forums peuples de jeunes ados tout excites.
dont l'origine n'est pas bien connue. Elle disparaît généralement quelques années après la puberté ; si tu as plus de 17 ans et que tu ponctues encore tes phrases par "lol", il faut vraiment que tu te poses des questions.
Pour moi, c'est juste une facon d'exprimer le fait que je sois en train de rire en lisant ce a quoi je reponds, c'est un peu comme un smiley sauf que je ne connais pas de bon smiley pour decrire "Laughing Out Loud" donc lol me parait tres explicite donc pourquoi ne pas l'utiliser, moderement bien sur.
On Thu, 31 Aug 2006 14:48:25 +0200, Francois Goudal
<francois_nospam_@goudal.net>:
Oui lol, [...]
Ah non lol, [...]
Attention, tu es atteint de lolisme. C'est une maladie assez grave,
Je ne trouve pas que cela soit si grave que cela, je n'en suis pas non
plus aux kikooooo lol mdrrr asv bisooo++ j t kif que l'on peut trouver
sur pas mal de chats et forums peuples de jeunes ados tout excites.
dont l'origine n'est pas bien connue. Elle disparaît généralement
quelques années après la puberté ; si tu as plus de 17 ans et que tu
ponctues encore tes phrases par "lol", il faut vraiment que tu te
poses des questions.
Pour moi, c'est juste une facon d'exprimer le fait que je sois en train
de rire en lisant ce a quoi je reponds, c'est un peu comme un smiley
sauf que je ne connais pas de bon smiley pour decrire "Laughing Out
Loud" donc lol me parait tres explicite donc pourquoi ne pas l'utiliser,
moderement bien sur.
On Thu, 31 Aug 2006 14:48:25 +0200, Francois Goudal :
Oui lol, [...] Ah non lol, [...]
Attention, tu es atteint de lolisme. C'est une maladie assez grave,
Je ne trouve pas que cela soit si grave que cela, je n'en suis pas non plus aux kikooooo lol mdrrr asv bisooo++ j t kif que l'on peut trouver sur pas mal de chats et forums peuples de jeunes ados tout excites.
dont l'origine n'est pas bien connue. Elle disparaît généralement quelques années après la puberté ; si tu as plus de 17 ans et que tu ponctues encore tes phrases par "lol", il faut vraiment que tu te poses des questions.
Pour moi, c'est juste une facon d'exprimer le fait que je sois en train de rire en lisant ce a quoi je reponds, c'est un peu comme un smiley sauf que je ne connais pas de bon smiley pour decrire "Laughing Out Loud" donc lol me parait tres explicite donc pourquoi ne pas l'utiliser, moderement bien sur.
Dans le message <news:44f71cb2$0$31634$, *Francois Goudal* tapota sur f.c.o.l.configuration :
A vrai dire, j'ai deja essaye cette solution aussi mais comme je l'ai dit, une adresse resolue est mise en cache
Mise en cache où ? Côté machine cliente ou côté serveur DNS local ?
et donc ca ne marche pas vraiment : si je met le TTL de mon DNS fake au minimum, effectivement, quand on va sur google, par exemple, on tombe sur le splashscreen, on active internet, immediatement apres, on peut a priori retaper google et on y arrive bien, mais a ce moment la, la vraie IP de google est mise en cache.
Si je comprends bien, vous parlez du cache DNS côté machine cliente.
Par consequent, si un utilisateur rebloque l'acces a internet, on va continuer pendant beaucoup trop longtemps a resoudre sur l'IP reelle et non pas l'IP "fakee" via notre DNS.
Et en quoi cela est un problème puisque qu'en principe la passerelle est censée à ce moment là, via la première règle DNAT, de rediriger tout le trafic Web vers votre serveur Web local, quelque soit l'adresse de destination, qu'elle soit réelle ou locale ?
-- Sébastien Monbrun aka TiChou
Dans le message <news:44f71cb2$0$31634$626a54ce@news.free.fr>,
*Francois Goudal* tapota sur f.c.o.l.configuration :
A vrai dire, j'ai deja essaye cette solution aussi mais comme je l'ai dit,
une adresse resolue est mise en cache
Mise en cache où ? Côté machine cliente ou côté serveur DNS local ?
et donc ca ne marche pas vraiment : si je met le TTL de mon DNS fake au
minimum, effectivement, quand on va sur google, par exemple, on tombe sur
le splashscreen, on active internet, immediatement apres, on peut a
priori retaper google et on y arrive bien, mais a ce moment la, la vraie
IP de google est mise en cache.
Si je comprends bien, vous parlez du cache DNS côté machine cliente.
Par consequent, si un utilisateur rebloque l'acces a internet, on va
continuer pendant beaucoup trop longtemps a resoudre sur l'IP reelle et
non pas l'IP "fakee" via notre DNS.
Et en quoi cela est un problème puisque qu'en principe la passerelle est
censée à ce moment là, via la première règle DNAT, de rediriger tout le
trafic Web vers votre serveur Web local, quelque soit l'adresse de
destination, qu'elle soit réelle ou locale ?
Dans le message <news:44f71cb2$0$31634$, *Francois Goudal* tapota sur f.c.o.l.configuration :
A vrai dire, j'ai deja essaye cette solution aussi mais comme je l'ai dit, une adresse resolue est mise en cache
Mise en cache où ? Côté machine cliente ou côté serveur DNS local ?
et donc ca ne marche pas vraiment : si je met le TTL de mon DNS fake au minimum, effectivement, quand on va sur google, par exemple, on tombe sur le splashscreen, on active internet, immediatement apres, on peut a priori retaper google et on y arrive bien, mais a ce moment la, la vraie IP de google est mise en cache.
Si je comprends bien, vous parlez du cache DNS côté machine cliente.
Par consequent, si un utilisateur rebloque l'acces a internet, on va continuer pendant beaucoup trop longtemps a resoudre sur l'IP reelle et non pas l'IP "fakee" via notre DNS.
Et en quoi cela est un problème puisque qu'en principe la passerelle est censée à ce moment là, via la première règle DNAT, de rediriger tout le trafic Web vers votre serveur Web local, quelque soit l'adresse de destination, qu'elle soit réelle ou locale ?
