Je d=E9bute sous freeBSD.
J'aimerai faire de mon serveur Freebsd une passerelle entre deux
r=E9seaux, 192.168.0.0/24 et 192.168.2.0/24.
Pour cela j'assigne =E0 mon serveur deux ips ( sur une m=EAme carte )
192.168.0.1/24 et 192.168.2.1/24 grace aux alias.
Mes PC appartiennent =E0 la classe d'adresse 192.168.2.0/24 et mon
routeur ADSL a l'adresse 192.168.0.254.
Le serveur arrivent bien =E0 joindre le routeur et toutes les machines.
Les machines arrivent =E0 joindre 192.168.0.1 donc le routage se fait
bien.
Mais probl=E8me, mes postes n'arrivent pas =E0 joindre 192.168.0.254 comme
si mon serveur filtre les paquets.
Quelqu'un aurait une id=E9e ?
Pour info je n'ai pas install=E9 de firewall sur le serveur.
Le NAT est utile pour rediriger les flux passant par des ports bien définis vers une adresse unique. Pour moi le NAT n'a pas d'utilité dans le role d'une passerelle.
Ce n'est pas un définition correcte du NAT.
Je redis donc ce dont je suis sûr :
- soit vous êtes capable de configurer votre routeur ADSL pour lui dire qu'il est connecté directement au réseau 192.168.0.0 (ça c'est facile) *et* (c'est là que c'est plus difficile) qu'il peut aussi accéder au réseau 192.168.2.0 via le routeur 192.168.0.1 (qui est votre PC sous FreeBSD).
- soit vous *devez* faire le NAT de votre réseau 192.168.2.0 via votre PC sous FreeBSD pour que votre modem ADSL croit que tout le traffic qu'on lui envoit vient bien du seul réseau qu'il connait (192.168.0.0).
Que vos deux réseaux (192.168.0.0 et 192.168.2.0) soient sur le même brin ethernet ou non importe peu.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Le NAT est utile pour rediriger les flux passant par des ports bien
définis vers une adresse unique. Pour moi le NAT n'a pas d'utilité
dans le role d'une passerelle.
Ce n'est pas un définition correcte du NAT.
Je redis donc ce dont je suis sûr :
- soit vous êtes capable de configurer votre routeur ADSL pour lui
dire qu'il est connecté directement au réseau 192.168.0.0 (ça c'est
facile) *et* (c'est là que c'est plus difficile) qu'il peut aussi
accéder au réseau 192.168.2.0 via le routeur 192.168.0.1 (qui est
votre PC sous FreeBSD).
- soit vous *devez* faire le NAT de votre réseau 192.168.2.0 via votre
PC sous FreeBSD pour que votre modem ADSL croit que tout le traffic
qu'on lui envoit vient bien du seul réseau qu'il connait
(192.168.0.0).
Que vos deux réseaux (192.168.0.0 et 192.168.2.0) soient sur le même
brin ethernet ou non importe peu.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Le NAT est utile pour rediriger les flux passant par des ports bien définis vers une adresse unique. Pour moi le NAT n'a pas d'utilité dans le role d'une passerelle.
Ce n'est pas un définition correcte du NAT.
Je redis donc ce dont je suis sûr :
- soit vous êtes capable de configurer votre routeur ADSL pour lui dire qu'il est connecté directement au réseau 192.168.0.0 (ça c'est facile) *et* (c'est là que c'est plus difficile) qu'il peut aussi accéder au réseau 192.168.2.0 via le routeur 192.168.0.1 (qui est votre PC sous FreeBSD).
- soit vous *devez* faire le NAT de votre réseau 192.168.2.0 via votre PC sous FreeBSD pour que votre modem ADSL croit que tout le traffic qu'on lui envoit vient bien du seul réseau qu'il connait (192.168.0.0).
Que vos deux réseaux (192.168.0.0 et 192.168.2.0) soient sur le même brin ethernet ou non importe peu.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Jean-Rémy Westelynck
Mon routeur ( pc avec Freebsd ) peut dialoguer avec ma freebox ( 192.168.0.254) grâce à son interface 192.168.0.1 Il peut aussi dialoguer avec mes postes informatiques 192.168.2.0/24
Pour ton routeur, le monde est reparti en 2: 192.168.0.0/24 qu'il accede sur son interface ethernet, et "le reste du monde" qu'il accede via sa patte WAN (celle qui te relie a ton FAI).
Pas de problème je suis d'accord.
Donc quand il recoit un paquet d'une de tes machines, deja il risque de trouver ca louche de recevoir un paquet "du reste du monde" sur son interface LAN (mais bon, un routeur simple ne se posera pas trop de questions), mais surtout, quand il va vouloir repondre, il va naturellement envoyer sa reponse .... sur le WAN !
Je suis vraiment un idiot . . . Merci ! Je vais essayer de mettre en place le NAT.
Mon routeur ( pc avec Freebsd ) peut dialoguer avec ma freebox
( 192.168.0.254) grâce à son interface 192.168.0.1
Il peut aussi dialoguer avec mes postes informatiques 192.168.2.0/24
Pour ton routeur, le monde est reparti en 2: 192.168.0.0/24 qu'il
accede sur son interface ethernet, et "le reste du monde" qu'il accede
via sa patte WAN (celle qui te relie a ton FAI).
Pas de problème je suis d'accord.
Donc quand il recoit un paquet d'une de tes machines, deja il risque
de trouver ca louche de recevoir un paquet "du reste du monde" sur son
interface LAN (mais bon, un routeur simple ne se posera pas trop de
questions), mais surtout, quand il va vouloir repondre, il va
naturellement envoyer sa reponse .... sur le WAN !
Je suis vraiment un idiot . . . Merci !
Je vais essayer de mettre en place le NAT.
Mon routeur ( pc avec Freebsd ) peut dialoguer avec ma freebox ( 192.168.0.254) grâce à son interface 192.168.0.1 Il peut aussi dialoguer avec mes postes informatiques 192.168.2.0/24
Pour ton routeur, le monde est reparti en 2: 192.168.0.0/24 qu'il accede sur son interface ethernet, et "le reste du monde" qu'il accede via sa patte WAN (celle qui te relie a ton FAI).
Pas de problème je suis d'accord.
Donc quand il recoit un paquet d'une de tes machines, deja il risque de trouver ca louche de recevoir un paquet "du reste du monde" sur son interface LAN (mais bon, un routeur simple ne se posera pas trop de questions), mais surtout, quand il va vouloir repondre, il va naturellement envoyer sa reponse .... sur le WAN !
Je suis vraiment un idiot . . . Merci ! Je vais essayer de mettre en place le NAT.
Voila ca fonctionne ! Une fois le NAT activé tout s'est mis à fonctionner à merveille ! Merci beaucoup !
Jean-Rémy Westelynck
La raison pour laquelle je ne voulais pas mettre de seconde carte réseau était :
La copine rale parce que le serveur fait pas très propre dans le salon, si je rajouté un cable réseau supplémentaire la pc risqué de passer par la fenêtre =)
Merci encore !
La raison pour laquelle je ne voulais pas mettre de seconde carte
réseau était :
La copine rale parce que le serveur fait pas très propre dans le
salon, si je rajouté un cable réseau supplémentaire la pc risqué de
passer par la fenêtre =)
La raison pour laquelle je ne voulais pas mettre de seconde carte réseau était :
La copine rale parce que le serveur fait pas très propre dans le salon, si je rajouté un cable réseau supplémentaire la pc risqué de passer par la fenêtre =)
Merci encore !
Pascal Hambourg
Salut,
Passe un coup de tcpdump pour voir ce qui se passe. L'initialisation de la connexion passe par la passerelle et la réponse passe directement à l'émetteur parce que la machine qui répond se rend compte d'elle-même qu'elle est sur le même brin ethernet.
La machine qui répond ne se rend compte de rien du tout. Elle envoie la réponse suivant sa table de routage, point. Si elle a la mauvaise route pour la destination, ce qui était le cas ici, ça ne marche pas. Et la couche ethernet n'a rien à voir là-dedans.
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit le paquet et voit qu'elle doit le router par la même interface, et donc que l'émetteur et la destination sont dans le même réseau. Elle estime qu'elle est un saut inutile et le fait savoir à l'émetteur avec un message ICMP Redirect pour qu'il crée une route directe dans sa table de routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets suivants directement à la cible.
J'ai essayé ce genre de manipulation pour isoler des imprimantes par exemple et forcer les utilisateurs à utiliser le spool d'impression sur le serveur, cela ne fonctionne pas.
Tu as essayé de faire quoi exactement ?
Salut,
Passe un coup de tcpdump pour voir ce qui se passe. L'initialisation
de la connexion passe par la passerelle et la réponse passe
directement à l'émetteur parce que la machine qui répond se rend compte
d'elle-même qu'elle est sur le même brin ethernet.
La machine qui répond ne se rend compte de rien du tout. Elle envoie la
réponse suivant sa table de routage, point. Si elle a la mauvaise route
pour la destination, ce qui était le cas ici, ça ne marche pas. Et la
couche ethernet n'a rien à voir là-dedans.
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit
le paquet et voit qu'elle doit le router par la même interface, et donc
que l'émetteur et la destination sont dans le même réseau. Elle estime
qu'elle est un saut inutile et le fait savoir à l'émetteur avec un
message ICMP Redirect pour qu'il crée une route directe dans sa table de
routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets
suivants directement à la cible.
J'ai essayé ce
genre de manipulation pour isoler des imprimantes par exemple et
forcer les utilisateurs à utiliser le spool d'impression sur le
serveur, cela ne fonctionne pas.
Passe un coup de tcpdump pour voir ce qui se passe. L'initialisation de la connexion passe par la passerelle et la réponse passe directement à l'émetteur parce que la machine qui répond se rend compte d'elle-même qu'elle est sur le même brin ethernet.
La machine qui répond ne se rend compte de rien du tout. Elle envoie la réponse suivant sa table de routage, point. Si elle a la mauvaise route pour la destination, ce qui était le cas ici, ça ne marche pas. Et la couche ethernet n'a rien à voir là-dedans.
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit le paquet et voit qu'elle doit le router par la même interface, et donc que l'émetteur et la destination sont dans le même réseau. Elle estime qu'elle est un saut inutile et le fait savoir à l'émetteur avec un message ICMP Redirect pour qu'il crée une route directe dans sa table de routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets suivants directement à la cible.
J'ai essayé ce genre de manipulation pour isoler des imprimantes par exemple et forcer les utilisateurs à utiliser le spool d'impression sur le serveur, cela ne fonctionne pas.
Tu as essayé de faire quoi exactement ?
JKB
Le 24-04-2008, à propos de Re: FreeBSD et Gateway, Pascal Hambourg écrivait dans fr.comp.os.bsd :
Salut,
Passe un coup de tcpdump pour voir ce qui se passe. L'initialisation de la connexion passe par la passerelle et la réponse passe directement à l'émetteur parce que la machine qui répond se rend compte d'elle-même qu'elle est sur le même brin ethernet.
La machine qui répond ne se rend compte de rien du tout. Elle envoie la réponse suivant sa table de routage, point. Si elle a la mauvaise route pour la destination, ce qui était le cas ici, ça ne marche pas. Et la couche ethernet n'a rien à voir là-dedans.
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit le paquet et voit qu'elle doit le router par la même interface, et donc que l'émetteur et la destination sont dans le même réseau. Elle estime qu'elle est un saut inutile et le fait savoir à l'émetteur avec un message ICMP Redirect pour qu'il crée une route directe dans sa table de routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets suivants directement à la cible.
C'est bien à ce gag que je pensais.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 24-04-2008, à propos de
Re: FreeBSD et Gateway,
Pascal Hambourg écrivait dans fr.comp.os.bsd :
Salut,
Passe un coup de tcpdump pour voir ce qui se passe. L'initialisation
de la connexion passe par la passerelle et la réponse passe
directement à l'émetteur parce que la machine qui répond se rend compte
d'elle-même qu'elle est sur le même brin ethernet.
La machine qui répond ne se rend compte de rien du tout. Elle envoie la
réponse suivant sa table de routage, point. Si elle a la mauvaise route
pour la destination, ce qui était le cas ici, ça ne marche pas. Et la
couche ethernet n'a rien à voir là-dedans.
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit
le paquet et voit qu'elle doit le router par la même interface, et donc
que l'émetteur et la destination sont dans le même réseau. Elle estime
qu'elle est un saut inutile et le fait savoir à l'émetteur avec un
message ICMP Redirect pour qu'il crée une route directe dans sa table de
routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets
suivants directement à la cible.
C'est bien à ce gag que je pensais.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 24-04-2008, à propos de Re: FreeBSD et Gateway, Pascal Hambourg écrivait dans fr.comp.os.bsd :
Salut,
Passe un coup de tcpdump pour voir ce qui se passe. L'initialisation de la connexion passe par la passerelle et la réponse passe directement à l'émetteur parce que la machine qui répond se rend compte d'elle-même qu'elle est sur le même brin ethernet.
La machine qui répond ne se rend compte de rien du tout. Elle envoie la réponse suivant sa table de routage, point. Si elle a la mauvaise route pour la destination, ce qui était le cas ici, ça ne marche pas. Et la couche ethernet n'a rien à voir là-dedans.
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit le paquet et voit qu'elle doit le router par la même interface, et donc que l'émetteur et la destination sont dans le même réseau. Elle estime qu'elle est un saut inutile et le fait savoir à l'émetteur avec un message ICMP Redirect pour qu'il crée une route directe dans sa table de routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets suivants directement à la cible.
C'est bien à ce gag que je pensais.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Pascal Hambourg
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit le paquet et voit qu'elle doit le router par la même interface, et donc que l'émetteur et la destination sont dans le même réseau. Elle estime qu'elle est un saut inutile et le fait savoir à l'émetteur avec un message ICMP Redirect pour qu'il crée une route directe dans sa table de routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets suivants directement à la cible.
C'est bien à ce gag que je pensais.
Alors je confirme que la couche ethernet n'a rien à voir dans l'histoire. Si on veut que le traffic passe par la passerelle, il serait souhaitable de désactiver l'envoi d'ICMP redirect par celle-ci. Mais même dans le cas contraire, il n'est pas garanti que la station honore ledit ICMP redirect qui lui dirait en substance : "pour envoyer un paquet à 192.168.0.254, veuillez utiliser la passerelle 192.168.0.254 plutôt que moi 192.168.2.1". L'ennui, c'est que justement la station n'a pas de route directe vers 192.168.0.254, donc il y a de bonnes chance qu'elle ignore le conseil. Certes, elle pourrait se la jouer fine et se dire : "si la passerelle 192.168.2.1, à laquelle je suis directement connectée, me dit d'utiliser la passerelle 192.168.0.254, ça doit vouloir dire que je suis directement connecté à 192.168.0.254 et donc je peux créer une route directe vers cette destination". Mais j'ai un gros doute.
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit
le paquet et voit qu'elle doit le router par la même interface, et donc
que l'émetteur et la destination sont dans le même réseau. Elle estime
qu'elle est un saut inutile et le fait savoir à l'émetteur avec un
message ICMP Redirect pour qu'il crée une route directe dans sa table de
routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets
suivants directement à la cible.
C'est bien à ce gag que je pensais.
Alors je confirme que la couche ethernet n'a rien à voir dans
l'histoire. Si on veut que le traffic passe par la passerelle, il serait
souhaitable de désactiver l'envoi d'ICMP redirect par celle-ci. Mais
même dans le cas contraire, il n'est pas garanti que la station honore
ledit ICMP redirect qui lui dirait en substance : "pour envoyer un
paquet à 192.168.0.254, veuillez utiliser la passerelle 192.168.0.254
plutôt que moi 192.168.2.1". L'ennui, c'est que justement la station n'a
pas de route directe vers 192.168.0.254, donc il y a de bonnes chance
qu'elle ignore le conseil. Certes, elle pourrait se la jouer fine et se
dire : "si la passerelle 192.168.2.1, à laquelle je suis directement
connectée, me dit d'utiliser la passerelle 192.168.0.254, ça doit
vouloir dire que je suis directement connecté à 192.168.0.254 et donc je
peux créer une route directe vers cette destination". Mais j'ai un gros
doute.
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit le paquet et voit qu'elle doit le router par la même interface, et donc que l'émetteur et la destination sont dans le même réseau. Elle estime qu'elle est un saut inutile et le fait savoir à l'émetteur avec un message ICMP Redirect pour qu'il crée une route directe dans sa table de routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets suivants directement à la cible.
C'est bien à ce gag que je pensais.
Alors je confirme que la couche ethernet n'a rien à voir dans l'histoire. Si on veut que le traffic passe par la passerelle, il serait souhaitable de désactiver l'envoi d'ICMP redirect par celle-ci. Mais même dans le cas contraire, il n'est pas garanti que la station honore ledit ICMP redirect qui lui dirait en substance : "pour envoyer un paquet à 192.168.0.254, veuillez utiliser la passerelle 192.168.0.254 plutôt que moi 192.168.2.1". L'ennui, c'est que justement la station n'a pas de route directe vers 192.168.0.254, donc il y a de bonnes chance qu'elle ignore le conseil. Certes, elle pourrait se la jouer fine et se dire : "si la passerelle 192.168.2.1, à laquelle je suis directement connectée, me dit d'utiliser la passerelle 192.168.0.254, ça doit vouloir dire que je suis directement connecté à 192.168.0.254 et donc je peux créer une route directe vers cette destination". Mais j'ai un gros doute.
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit le paquet et voit qu'elle doit le router par la même interface, et donc que l'émetteur et la destination sont dans le même réseau. Elle estime qu'elle est un saut inutile et le fait savoir à l'émetteur avec un message ICMP Redirect pour qu'il crée une route directe dans sa table de routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets suivants directement à la cible.
C'est bien à ce gag que je pensais.
Alors je confirme que la couche ethernet n'a rien à voir dans l'histoire. Si on veut que le traffic passe par la passerelle, il serait souhaitable de désactiver l'envoi d'ICMP redirect par celle-ci.
Sauf que dans le configuration dont on parle, on a bien *deux* interfaces logiques différentes et qui sont sur *deux* réseaux IP différents (bien que sur la même interface physique et donc sur le même brin ethernet). Ce qui explique pourquoi ça marche (sur la passerelle).
Ensuite, il faut que les deux machines qui veulent se parler sachent que la route entre leurs deux réseaux est la passerelle. Autant c'est facile à configurer sur un ordinateur classique (il suffit de configurer les routes correctement). Autant c'est souvent beaucoup moins évident sur un modem/routeur ADSL ou sur une imprimante.
D'où la solution de faire du NAT pour qu'ils n'aient pas à se poser la question de la bonne route.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Il pourrait néanmoins se passer la chose suivante. La passerelle
reçoit le paquet et voit qu'elle doit le router par la même
interface, et donc que l'émetteur et la destination sont dans le
même réseau. Elle estime qu'elle est un saut inutile et le fait
savoir à l'émetteur avec un message ICMP Redirect pour qu'il crée
une route directe dans sa table de routage. Si l'émetteur honore
l'ICMP redirect, il enverra les paquets suivants directement à la
cible.
C'est bien à ce gag que je pensais.
Alors je confirme que la couche ethernet n'a rien à voir dans
l'histoire. Si on veut que le traffic passe par la passerelle, il
serait souhaitable de désactiver l'envoi d'ICMP redirect par celle-ci.
Sauf que dans le configuration dont on parle, on a bien *deux*
interfaces logiques différentes et qui sont sur *deux* réseaux IP
différents (bien que sur la même interface physique et donc sur le
même brin ethernet). Ce qui explique pourquoi ça marche (sur la
passerelle).
Ensuite, il faut que les deux machines qui veulent se parler sachent
que la route entre leurs deux réseaux est la passerelle. Autant c'est
facile à configurer sur un ordinateur classique (il suffit de
configurer les routes correctement). Autant c'est souvent beaucoup
moins évident sur un modem/routeur ADSL ou sur une imprimante.
D'où la solution de faire du NAT pour qu'ils n'aient pas à se poser la
question de la bonne route.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Il pourrait néanmoins se passer la chose suivante. La passerelle reçoit le paquet et voit qu'elle doit le router par la même interface, et donc que l'émetteur et la destination sont dans le même réseau. Elle estime qu'elle est un saut inutile et le fait savoir à l'émetteur avec un message ICMP Redirect pour qu'il crée une route directe dans sa table de routage. Si l'émetteur honore l'ICMP redirect, il enverra les paquets suivants directement à la cible.
C'est bien à ce gag que je pensais.
Alors je confirme que la couche ethernet n'a rien à voir dans l'histoire. Si on veut que le traffic passe par la passerelle, il serait souhaitable de désactiver l'envoi d'ICMP redirect par celle-ci.
Sauf que dans le configuration dont on parle, on a bien *deux* interfaces logiques différentes et qui sont sur *deux* réseaux IP différents (bien que sur la même interface physique et donc sur le même brin ethernet). Ce qui explique pourquoi ça marche (sur la passerelle).
Ensuite, il faut que les deux machines qui veulent se parler sachent que la route entre leurs deux réseaux est la passerelle. Autant c'est facile à configurer sur un ordinateur classique (il suffit de configurer les routes correctement). Autant c'est souvent beaucoup moins évident sur un modem/routeur ADSL ou sur une imprimante.
D'où la solution de faire du NAT pour qu'ils n'aient pas à se poser la question de la bonne route.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
