Salut,
à mon bureau, j'ai deux lignes ADSL, donc deux IP différentes (l'une sur
Free, l'autre sur Alice), avec deux routeurs dédiés différents (l'un en
192.168.0.1, l'autre en ..254, c'est la Freebox).
Donc, pour choisir depuis l'intérieur quelle ligne j'utilise, il suffit
que je définisse la route par défaut qui va bien. Jusqu'ici, c'est facile.
Cependant, je voudrais pouvoir répondre simultanément sur les deux
lignes, c'est-à-dire pourvoir diriger les paquets qui viennent de la
Freebox vers la Freebox et ceux qui viennent de l'Alicebox vers l'Alicebox.
Possible ? Si oui, comment ?
Salut,
à mon bureau, j'ai deux lignes ADSL, donc deux IP différentes (l'une sur
Free, l'autre sur Alice), avec deux routeurs dédiés différents (l'un en
192.168.0.1, l'autre en ..254, c'est la Freebox).
Donc, pour choisir depuis l'intérieur quelle ligne j'utilise, il suffit
que je définisse la route par défaut qui va bien. Jusqu'ici, c'est facile.
Cependant, je voudrais pouvoir répondre simultanément sur les deux
lignes, c'est-à-dire pourvoir diriger les paquets qui viennent de la
Freebox vers la Freebox et ceux qui viennent de l'Alicebox vers l'Alicebox.
Possible ? Si oui, comment ?
Salut,
à mon bureau, j'ai deux lignes ADSL, donc deux IP différentes (l'une sur
Free, l'autre sur Alice), avec deux routeurs dédiés différents (l'un en
192.168.0.1, l'autre en ..254, c'est la Freebox).
Donc, pour choisir depuis l'intérieur quelle ligne j'utilise, il suffit
que je définisse la route par défaut qui va bien. Jusqu'ici, c'est facile.
Cependant, je voudrais pouvoir répondre simultanément sur les deux
lignes, c'est-à-dire pourvoir diriger les paquets qui viennent de la
Freebox vers la Freebox et ceux qui viennent de l'Alicebox vers l'Alicebox.
Possible ? Si oui, comment ?
la bonne IP source. Tout ca serait plus simple avec 2 reseaux IP
differents (par exemple free sur 192.168.0.1/24, alice sur
192.168.1.1/24).
la bonne IP source. Tout ca serait plus simple avec 2 reseaux IP
differents (par exemple free sur 192.168.0.1/24, alice sur
192.168.1.1/24).
la bonne IP source. Tout ca serait plus simple avec 2 reseaux IP
differents (par exemple free sur 192.168.0.1/24, alice sur
192.168.1.1/24).
Je pense qu'il faut que la machine ai 2 IP differentes, une qui
reponde a la freebox et l'autre a l'alicebox (ca peut etre sur la
meme interface, avec un alias). Sinon on va avoir du mal a determier
quel paquet doit aller ou.
Apres on doit pouvoir utiliser une regle ipf du genre:
pass out to wm0:192.168.0.1 from <IP utilisee pour l'alicebox> to any
(remplacer wm0 par le nom de l'interface ethernet bien sur)
avec la route par defaut vers la freebox.
Je pense qu'il faut que la machine ai 2 IP differentes, une qui
reponde a la freebox et l'autre a l'alicebox (ca peut etre sur la
meme interface, avec un alias). Sinon on va avoir du mal a determier
quel paquet doit aller ou.
Apres on doit pouvoir utiliser une regle ipf du genre:
pass out to wm0:192.168.0.1 from <IP utilisee pour l'alicebox> to any
(remplacer wm0 par le nom de l'interface ethernet bien sur)
avec la route par defaut vers la freebox.
Je pense qu'il faut que la machine ai 2 IP differentes, une qui
reponde a la freebox et l'autre a l'alicebox (ca peut etre sur la
meme interface, avec un alias). Sinon on va avoir du mal a determier
quel paquet doit aller ou.
Apres on doit pouvoir utiliser une regle ipf du genre:
pass out to wm0:192.168.0.1 from <IP utilisee pour l'alicebox> to any
(remplacer wm0 par le nom de l'interface ethernet bien sur)
avec la route par defaut vers la freebox.
Il y a un truc qui m'échappe là, comment le filtre IP peut-il savoir
qu'il s'agit de l'adresse IP utilisée pour l'alicebox ?
Si la table de routage est regardée avant le passage par le filtre IP,
l'adresse IP sera celle correspondant à l'interface par défaut (sauf
règle explicite contraire dans la table de routage), non ? Et à
l'inverse si le filtre IP est appelé avant la table de routage,
l'adresse IP sera celle de l'interface du routeur qui donne sur le LAN,
non ?
Au passage, quid de la pile IP ? Il n'y a pas, tout simplement, la
possibilité de lui ajouter une table d'état même minimaliste ? A la
sortie du paquet, il suffit de regarder l'adresse IP destination et de
regarder par quelle interface le paquet associé était entré, non ?
Il y a un truc qui m'échappe là, comment le filtre IP peut-il savoir
qu'il s'agit de l'adresse IP utilisée pour l'alicebox ?
Si la table de routage est regardée avant le passage par le filtre IP,
l'adresse IP sera celle correspondant à l'interface par défaut (sauf
règle explicite contraire dans la table de routage), non ? Et à
l'inverse si le filtre IP est appelé avant la table de routage,
l'adresse IP sera celle de l'interface du routeur qui donne sur le LAN,
non ?
Au passage, quid de la pile IP ? Il n'y a pas, tout simplement, la
possibilité de lui ajouter une table d'état même minimaliste ? A la
sortie du paquet, il suffit de regarder l'adresse IP destination et de
regarder par quelle interface le paquet associé était entré, non ?
Il y a un truc qui m'échappe là, comment le filtre IP peut-il savoir
qu'il s'agit de l'adresse IP utilisée pour l'alicebox ?
Si la table de routage est regardée avant le passage par le filtre IP,
l'adresse IP sera celle correspondant à l'interface par défaut (sauf
règle explicite contraire dans la table de routage), non ? Et à
l'inverse si le filtre IP est appelé avant la table de routage,
l'adresse IP sera celle de l'interface du routeur qui donne sur le LAN,
non ?
Au passage, quid de la pile IP ? Il n'y a pas, tout simplement, la
possibilité de lui ajouter une table d'état même minimaliste ? A la
sortie du paquet, il suffit de regarder l'adresse IP destination et de
regarder par quelle interface le paquet associé était entré, non ?
"Vincent (ex Elendir)" wrote:Salut,
à mon bureau, j'ai deux lignes ADSL, donc deux IP différentes (l'une sur
Free, l'autre sur Alice), avec deux routeurs dédiés différents (l'un en
192.168.0.1, l'autre en ..254, c'est la Freebox).
Donc, pour choisir depuis l'intérieur quelle ligne j'utilise, il suffit
que je définisse la route par défaut qui va bien. Jusqu'ici, c'est facile.
Cependant, je voudrais pouvoir répondre simultanément sur les deux
lignes, c'est-à-dire pourvoir diriger les paquets qui viennent de la
Freebox vers la Freebox et ceux qui viennent de l'Alicebox vers l'Alicebox.
Possible ? Si oui, comment ?
Je pense qu'il faut que la machine ai 2 IP differentes, une qui
reponde a la freebox et l'autre a l'alicebox (ca peut etre sur la
meme interface, avec un alias). Sinon on va avoir du mal a determier
quel paquet doit aller ou.
Apres on doit pouvoir utiliser une regle ipf du genre:
pass out to wm0:192.168.0.1 from <IP utilisee pour l'alicebox> to any
(remplacer wm0 par le nom de l'interface ethernet bien sur)
avec la route par defaut vers la freebox.
Ca veux dire que sur tes règles IN t'a pas fait de keep state sinon la
Du coup ca peut peut-etre poser un probleme pour les connections sortantes,
qui risque d'etre aussi redirige par la regle ipf s'ils n'ont pas
la bonne IP source. Tout ca serait plus simple avec 2 reseaux IP
differents (par exemple free sur 192.168.0.1/24, alice sur
192.168.1.1/24).
Oui même avec 2 cartes réseaux différentes cà rend les règles plus lisibles.
"Vincent (ex Elendir)" <10.50@free.fr> wrote:
Salut,
à mon bureau, j'ai deux lignes ADSL, donc deux IP différentes (l'une sur
Free, l'autre sur Alice), avec deux routeurs dédiés différents (l'un en
192.168.0.1, l'autre en ..254, c'est la Freebox).
Donc, pour choisir depuis l'intérieur quelle ligne j'utilise, il suffit
que je définisse la route par défaut qui va bien. Jusqu'ici, c'est facile.
Cependant, je voudrais pouvoir répondre simultanément sur les deux
lignes, c'est-à-dire pourvoir diriger les paquets qui viennent de la
Freebox vers la Freebox et ceux qui viennent de l'Alicebox vers l'Alicebox.
Possible ? Si oui, comment ?
Je pense qu'il faut que la machine ai 2 IP differentes, une qui
reponde a la freebox et l'autre a l'alicebox (ca peut etre sur la
meme interface, avec un alias). Sinon on va avoir du mal a determier
quel paquet doit aller ou.
Apres on doit pouvoir utiliser une regle ipf du genre:
pass out to wm0:192.168.0.1 from <IP utilisee pour l'alicebox> to any
(remplacer wm0 par le nom de l'interface ethernet bien sur)
avec la route par defaut vers la freebox.
Ca veux dire que sur tes règles IN t'a pas fait de keep state sinon la
Du coup ca peut peut-etre poser un probleme pour les connections sortantes,
qui risque d'etre aussi redirige par la regle ipf s'ils n'ont pas
la bonne IP source. Tout ca serait plus simple avec 2 reseaux IP
differents (par exemple free sur 192.168.0.1/24, alice sur
192.168.1.1/24).
Oui même avec 2 cartes réseaux différentes cà rend les règles plus lisibles.
"Vincent (ex Elendir)" wrote:Salut,
à mon bureau, j'ai deux lignes ADSL, donc deux IP différentes (l'une sur
Free, l'autre sur Alice), avec deux routeurs dédiés différents (l'un en
192.168.0.1, l'autre en ..254, c'est la Freebox).
Donc, pour choisir depuis l'intérieur quelle ligne j'utilise, il suffit
que je définisse la route par défaut qui va bien. Jusqu'ici, c'est facile.
Cependant, je voudrais pouvoir répondre simultanément sur les deux
lignes, c'est-à-dire pourvoir diriger les paquets qui viennent de la
Freebox vers la Freebox et ceux qui viennent de l'Alicebox vers l'Alicebox.
Possible ? Si oui, comment ?
Je pense qu'il faut que la machine ai 2 IP differentes, une qui
reponde a la freebox et l'autre a l'alicebox (ca peut etre sur la
meme interface, avec un alias). Sinon on va avoir du mal a determier
quel paquet doit aller ou.
Apres on doit pouvoir utiliser une regle ipf du genre:
pass out to wm0:192.168.0.1 from <IP utilisee pour l'alicebox> to any
(remplacer wm0 par le nom de l'interface ethernet bien sur)
avec la route par defaut vers la freebox.
Ca veux dire que sur tes règles IN t'a pas fait de keep state sinon la
Du coup ca peut peut-etre poser un probleme pour les connections sortantes,
qui risque d'etre aussi redirige par la regle ipf s'ils n'ont pas
la bonne IP source. Tout ca serait plus simple avec 2 reseaux IP
differents (par exemple free sur 192.168.0.1/24, alice sur
192.168.1.1/24).
Oui même avec 2 cartes réseaux différentes cà rend les règles plus lisibles.
C'est pour ca qu'il faut 2 adresses IP sur la machine. Quand ca vient
de free le routeur free redirige sur IP1, quand ca vient de alice le
routeur d'alice redirige sur IP2. La reponse viendra forcement de
l'IP qui a recu le paquet.
Au passage, quid de la pile IP ? Il n'y a pas, tout simplement, la
possibilité de lui ajouter une table d'état même minimaliste ? A la
sortie du paquet, il suffit de regarder l'adresse IP destination et de
regarder par quelle interface le paquet associé était entré, non ?
Pour les protocoles non-connectes ca va etre chaud ...
C'est pour ca qu'il faut 2 adresses IP sur la machine. Quand ca vient
de free le routeur free redirige sur IP1, quand ca vient de alice le
routeur d'alice redirige sur IP2. La reponse viendra forcement de
l'IP qui a recu le paquet.
Au passage, quid de la pile IP ? Il n'y a pas, tout simplement, la
possibilité de lui ajouter une table d'état même minimaliste ? A la
sortie du paquet, il suffit de regarder l'adresse IP destination et de
regarder par quelle interface le paquet associé était entré, non ?
Pour les protocoles non-connectes ca va etre chaud ...
C'est pour ca qu'il faut 2 adresses IP sur la machine. Quand ca vient
de free le routeur free redirige sur IP1, quand ca vient de alice le
routeur d'alice redirige sur IP2. La reponse viendra forcement de
l'IP qui a recu le paquet.
Au passage, quid de la pile IP ? Il n'y a pas, tout simplement, la
possibilité de lui ajouter une table d'état même minimaliste ? A la
sortie du paquet, il suffit de regarder l'adresse IP destination et de
regarder par quelle interface le paquet associé était entré, non ?
Pour les protocoles non-connectes ca va etre chaud ...
Ca veux dire que sur tes règles IN t'a pas fait de keep state sinon la
sortie se fera sans repasser par les règles pf.
De plus, tu vas avoir un souci pour les connections dynamiques genre FTP
où le serveur sera à l'initiative du flux de data et va le faire avec la
première adresse de l'interface.
Ca demande à être testé mais je pense qu'il va y avoir plein de cas
"limites" qui en vont pas marcher.
Du coup ca peut peut-etre poser un probleme pour les connections sortantes,
qui risque d'etre aussi redirige par la regle ipf s'ils n'ont pas
la bonne IP source. Tout ca serait plus simple avec 2 reseaux IP
differents (par exemple free sur 192.168.0.1/24, alice sur
192.168.1.1/24).
Oui même avec 2 cartes réseaux différentes cà rend les règles plus lisibles.
Ca veux dire que sur tes règles IN t'a pas fait de keep state sinon la
sortie se fera sans repasser par les règles pf.
De plus, tu vas avoir un souci pour les connections dynamiques genre FTP
où le serveur sera à l'initiative du flux de data et va le faire avec la
première adresse de l'interface.
Ca demande à être testé mais je pense qu'il va y avoir plein de cas
"limites" qui en vont pas marcher.
Du coup ca peut peut-etre poser un probleme pour les connections sortantes,
qui risque d'etre aussi redirige par la regle ipf s'ils n'ont pas
la bonne IP source. Tout ca serait plus simple avec 2 reseaux IP
differents (par exemple free sur 192.168.0.1/24, alice sur
192.168.1.1/24).
Oui même avec 2 cartes réseaux différentes cà rend les règles plus lisibles.
Ca veux dire que sur tes règles IN t'a pas fait de keep state sinon la
sortie se fera sans repasser par les règles pf.
De plus, tu vas avoir un souci pour les connections dynamiques genre FTP
où le serveur sera à l'initiative du flux de data et va le faire avec la
première adresse de l'interface.
Ca demande à être testé mais je pense qu'il va y avoir plein de cas
"limites" qui en vont pas marcher.
Du coup ca peut peut-etre poser un probleme pour les connections sortantes,
qui risque d'etre aussi redirige par la regle ipf s'ils n'ont pas
la bonne IP source. Tout ca serait plus simple avec 2 reseaux IP
differents (par exemple free sur 192.168.0.1/24, alice sur
192.168.1.1/24).
Oui même avec 2 cartes réseaux différentes cà rend les règles plus lisibles.
Je ne vois guère que le protocole FTP qui puisse poser problème, et
encore uniquement s'il a un serveur, parce que dans le cas d'une
connexion de sa part passera sans problèmes.
Même les protocoles batard
de messagerie instantanée devraient passer, le client à l'autre bout
étant suposé ne pas s'intéresser à l'adresse IP qui initie l'autre
canal et identifier l'utilisateur grâce aux données d'identification
(ou assimilées).
D'ailleurs, je me demande si le cas du FTP est aussi impossible que
cela. Il me semble bien qu'il y a quelque chose dans la norme qui
permet de faire des connexions à trois, avec un canal de commande
direct entre le client et le serveur, et un canal de données qui passe
par un serveur tiers utilisé comme proxy, ou un truc comme ça.
Je ne vois guère que le protocole FTP qui puisse poser problème, et
encore uniquement s'il a un serveur, parce que dans le cas d'une
connexion de sa part passera sans problèmes.
Même les protocoles batard
de messagerie instantanée devraient passer, le client à l'autre bout
étant suposé ne pas s'intéresser à l'adresse IP qui initie l'autre
canal et identifier l'utilisateur grâce aux données d'identification
(ou assimilées).
D'ailleurs, je me demande si le cas du FTP est aussi impossible que
cela. Il me semble bien qu'il y a quelque chose dans la norme qui
permet de faire des connexions à trois, avec un canal de commande
direct entre le client et le serveur, et un canal de données qui passe
par un serveur tiers utilisé comme proxy, ou un truc comme ça.
Je ne vois guère que le protocole FTP qui puisse poser problème, et
encore uniquement s'il a un serveur, parce que dans le cas d'une
connexion de sa part passera sans problèmes.
Même les protocoles batard
de messagerie instantanée devraient passer, le client à l'autre bout
étant suposé ne pas s'intéresser à l'adresse IP qui initie l'autre
canal et identifier l'utilisateur grâce aux données d'identification
(ou assimilées).
D'ailleurs, je me demande si le cas du FTP est aussi impossible que
cela. Il me semble bien qu'il y a quelque chose dans la norme qui
permet de faire des connexions à trois, avec un canal de commande
direct entre le client et le serveur, et un canal de données qui passe
par un serveur tiers utilisé comme proxy, ou un truc comme ça.
Je ne vois guère que le protocole FTP qui puisse poser problème, et
encore uniquement s'il a un serveur, parce que dans le cas d'une
connexion de sa part passera sans problèmes.
Pourquoi uniquement avec un serveur ? Entre les modes passif et actif,
les rôles du client et du serveur dans l'établissement des connexions de
données sont symétriques.
Même les protocoles batard
de messagerie instantanée devraient passer, le client à l'autre bout
étant suposé ne pas s'intéresser à l'adresse IP qui initie l'autre
canal et identifier l'utilisateur grâce aux données d'identification
(ou assimilées).
Vrai pour toute la partie du protocole qui fonctionne en client-serveur
par l'intermédiaire d'un serveur central (typiquement la partie texte),
mais pas pour la partie qui fonctionne en pair à pair pour limiter la
charge du serveur central et/ou la latence (typiquement l'audio/visio et
le transfert de fichiers).
D'ailleurs, je me demande si le cas du FTP est aussi impossible que
cela. Il me semble bien qu'il y a quelque chose dans la norme qui
permet de faire des connexions à trois, avec un canal de commande
direct entre le client et le serveur, et un canal de données qui passe
par un serveur tiers utilisé comme proxy, ou un truc comme ça.
Tu ne confondrais pas avec le transfert direct entre deux serveurs sous
le contrôle d'un client, appelé parfois FXP ? Deux connexions de
commande, une entre le client et chaque serveur, et une connexion de
données entre les deux serveurs.
Je ne vois guère que le protocole FTP qui puisse poser problème, et
encore uniquement s'il a un serveur, parce que dans le cas d'une
connexion de sa part passera sans problèmes.
Pourquoi uniquement avec un serveur ? Entre les modes passif et actif,
les rôles du client et du serveur dans l'établissement des connexions de
données sont symétriques.
Même les protocoles batard
de messagerie instantanée devraient passer, le client à l'autre bout
étant suposé ne pas s'intéresser à l'adresse IP qui initie l'autre
canal et identifier l'utilisateur grâce aux données d'identification
(ou assimilées).
Vrai pour toute la partie du protocole qui fonctionne en client-serveur
par l'intermédiaire d'un serveur central (typiquement la partie texte),
mais pas pour la partie qui fonctionne en pair à pair pour limiter la
charge du serveur central et/ou la latence (typiquement l'audio/visio et
le transfert de fichiers).
D'ailleurs, je me demande si le cas du FTP est aussi impossible que
cela. Il me semble bien qu'il y a quelque chose dans la norme qui
permet de faire des connexions à trois, avec un canal de commande
direct entre le client et le serveur, et un canal de données qui passe
par un serveur tiers utilisé comme proxy, ou un truc comme ça.
Tu ne confondrais pas avec le transfert direct entre deux serveurs sous
le contrôle d'un client, appelé parfois FXP ? Deux connexions de
commande, une entre le client et chaque serveur, et une connexion de
données entre les deux serveurs.
Je ne vois guère que le protocole FTP qui puisse poser problème, et
encore uniquement s'il a un serveur, parce que dans le cas d'une
connexion de sa part passera sans problèmes.
Pourquoi uniquement avec un serveur ? Entre les modes passif et actif,
les rôles du client et du serveur dans l'établissement des connexions de
données sont symétriques.
Même les protocoles batard
de messagerie instantanée devraient passer, le client à l'autre bout
étant suposé ne pas s'intéresser à l'adresse IP qui initie l'autre
canal et identifier l'utilisateur grâce aux données d'identification
(ou assimilées).
Vrai pour toute la partie du protocole qui fonctionne en client-serveur
par l'intermédiaire d'un serveur central (typiquement la partie texte),
mais pas pour la partie qui fonctionne en pair à pair pour limiter la
charge du serveur central et/ou la latence (typiquement l'audio/visio et
le transfert de fichiers).
D'ailleurs, je me demande si le cas du FTP est aussi impossible que
cela. Il me semble bien qu'il y a quelque chose dans la norme qui
permet de faire des connexions à trois, avec un canal de commande
direct entre le client et le serveur, et un canal de données qui passe
par un serveur tiers utilisé comme proxy, ou un truc comme ça.
Tu ne confondrais pas avec le transfert direct entre deux serveurs sous
le contrôle d'un client, appelé parfois FXP ? Deux connexions de
commande, une entre le client et chaque serveur, et une connexion de
données entre les deux serveurs.