[toutBSD] Petit pb de routage

Le
Vincent (ex Elendir)
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 ?

Merci !
Vincent
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Manuel Bouyer
Le #1581868
"Vincent (ex Elendir)"
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.
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).

--
Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference
--

Vincent
Le #1581867
Salut Manu,

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).


Bon, c'est ce que je vais faire je pense. Je vais ouvrir un autre
segment en 192.168.1.0/24 pour les deux machines (le serveur et la mienne).

Merci du coup de pouce toujours bien agréable.

Vincent

Stephane Catteau
Le #1581866
Manuel Bouyer n'était pas loin de dire :


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 ?

Manuel Bouyer
Le #1599824
Stephane Catteau
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 ?


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 ...

--
Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference
--

Fabrice
Le #1723032
"Vincent (ex Elendir)"
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

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.


FAbrice


Stephane Catteau
Le #1723031
Manuel Bouyer n'était pas loin de dire :

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.


Mon erreur venait du fait que j'appliquais le problème à mon cas
particulier. Comme il y a une passerelle entre les deux FAI et le LAN,
je n'arrivais pas à comprendre comment la machine pouvait faire la
différence simplement grâce à l'adresse IP qui a reçu le paquet. Je
regardais le problème vue de la DMZ, et du coup je n'arrivais pas à
voir l'adresse IP autrement qu'en 10.0.0.0/8


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 ...


Pas plus que lorsque c'est le filtre IP qui le fait. Et ce petit rien
m'a ammené vers la réponse à mon problème à moi que j'avais. Un petit
coup de /reply-to/ dans la conf' de pf et le tour est joué.
Ca m'apprendra à ne pas avoir pris le temps de lire toute la doc y
compris ce qui était initialement superflu.


Stephane Catteau
Le #1723589
Fabrice n'était pas loin de dire :

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.


Pas si tu associes /reply-to/ à la règle.


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.


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.


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.


Elles sont même obligatoires dans le cas du /reply-to/ il me semble.


Pascal Hambourg
Le #1724829
Salut,


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.

Stephane Catteau
Le #1789559
Pascal Hambourg n'était pas loin de dire :

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.


Oui, mais lorsque tu te connectes à un serveur distant, celui-ci ne
connait qu'une adresse IP, et c'est donc celle-ci qu'il utilisera pour
ouvrir le canal des données. Le canal de commande sortira par une
interface au choix de la table de routage, et le canal de données
initié par le serveur entrera par la même interface, puisque c'est
celle dont il connait l'adresse IP.
Alors que lorsque c'est le client qui est distant, tu as le canal de
commande qui rentre par l'interface correspondant à l'adresse IP
déclarée dans l'enregistrement DNS, et le canal de données qui sortira
par l'interface que lui indiquera la table de routage. Tu te retrouves
donc avec une chance sur deux (ou sur trois, quatre, plus, ça dépend de
la politique de routage) de sortir par la mauvaise interface et de te
faire jeter par le client qui ne peut pas comprendre que la connexion
en provenance de l'adresse IP 192.0.5.1 correspond à la connexion qu'il
a initié avec le serveur situé en 12.13.14.15


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).


Vrai pour toute la partie du protocole qui travail sur la couche
application, donc là où elle devrait travailler. Dès lors qu'il y a un
champ "from machin-chose" dans les données transmises, le logiciel
n'aura pas besoin de l'adresse IP pour associer les connexions par
paire, et donc aucune raison de s'en occuper.


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.


C'est possible, ça fait un bail que je n'ai pas regardé les RFC liées
au FTP, et la dernière fois j'ai usé un tube d'aspirine après.


Publicité
Poster une réponse
Anonyme