j'ai installé Slackware 12.0 sur mon portable inspiron 9300 et j'ai un
problème avec ssh.
Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien.
Mais ssh (ou scp) ne marche pas dans la direction
Autres ordis---->portable, alors que ça marche bien dans l'autre sens.
j'utilise le script suivant pour faire marcher le wifi :
iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX
route add 192.168.1.1 dev eth1
route add default gw 192.168.1.1
ifconfig eth0 down
quelqu'un a-t'il une idée pour résoudre ce problème ?
Mais ssh (ou scp) ne marche pas dans la direction Autres ordis---->portable, alors que ça marche bien dans l'autre sens.
Question idiote : est-ce que sshd fonctionne bien sur le portable ? Que donne un "ssh localhost" ?
Oui ça marche....
Luc.Habert.00__arjf
Tu essayes de te connecter depuis où, et vers quelle adresse IP? Là, tu es sur un réseau privé probablement derrière du masquerading, donc sans réglage spécial sur le routeur, si tu essayes depuis l'extérieur, c'est normal que ça ne passe pas.
Tu essayes de te connecter depuis où, et vers quelle adresse IP? Là, tu es
sur un réseau privé probablement derrière du masquerading, donc sans réglage
spécial sur le routeur, si tu essayes depuis l'extérieur, c'est normal que
ça ne passe pas.
Tu essayes de te connecter depuis où, et vers quelle adresse IP? Là, tu es sur un réseau privé probablement derrière du masquerading, donc sans réglage spécial sur le routeur, si tu essayes depuis l'extérieur, c'est normal que ça ne passe pas.
jmdr
Luc Habert wrote:
Tu essayes de te connecter depuis où, et vers quelle adresse IP? Là, tu es sur un réseau privé probablement derrière du masquerading, donc sans réglage spécial sur le routeur, si tu essayes depuis l'extérieur, c'est normal que ça ne passe pas.
tout se passe bien dans le sens ordis---> extérieur , à partir de n'importe laquelle des machines installées de mon réseau
ça marche aussi dans le sens portable-->Autres
le seul sens qui ne marche pas c'est d'un autre ordinateur de mon réseau privé vers le portable.
Luc Habert wrote:
Tu essayes de te connecter depuis où, et vers quelle adresse IP? Là, tu es
sur un réseau privé probablement derrière du masquerading, donc sans réglage
spécial sur le routeur, si tu essayes depuis l'extérieur, c'est normal que
ça ne passe pas.
tout se passe bien dans le sens ordis---> extérieur , à partir de
n'importe laquelle des machines installées de mon réseau
ça marche aussi dans le sens portable-->Autres
le seul sens qui ne marche pas c'est d'un autre ordinateur de mon réseau
privé vers le portable.
Tu essayes de te connecter depuis où, et vers quelle adresse IP? Là, tu es sur un réseau privé probablement derrière du masquerading, donc sans réglage spécial sur le routeur, si tu essayes depuis l'extérieur, c'est normal que ça ne passe pas.
tout se passe bien dans le sens ordis---> extérieur , à partir de n'importe laquelle des machines installées de mon réseau
ça marche aussi dans le sens portable-->Autres
le seul sens qui ne marche pas c'est d'un autre ordinateur de mon réseau privé vers le portable.
Fabien LE LEZ
Que donne un "ssh localhost" ?
Et accessoirement, essaie aussi ssh 192.168.x.y (où "192.168.x.y" est l'adresse IP de l'interface wifi du portable)
Que donne un "ssh localhost" ?
Et accessoirement, essaie aussi
ssh 192.168.x.y
(où "192.168.x.y" est l'adresse IP de l'interface wifi du portable)
Et accessoirement, essaie aussi ssh 192.168.x.y (où "192.168.x.y" est l'adresse IP de l'interface wifi du portable)
Pascal Hambourg
Salut,
Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien. Mais ssh (ou scp) ne marche pas dans la direction Autres ordis---->portable, alors que ça marche bien dans l'autre sens.
j'utilise le script suivant pour faire marcher le wifi : iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX route add 192.168.1.1 dev eth1 route add default gw 192.168.1.1 ifconfig eth0 down
Un peu foireuse cette configuration réseau. C'est déjà bien beau que ça cause dans un sens. Et pourquoi cette route d'hôte vers 192.168.1.1 (qui est le routeur, je suppose) plutôt que vers le réseau 192.168.1.0/24 tout entier ? Je serais intéressé par la sortie d'ifconfig -a et route -n (ou ip addr et ip route).
quelqu'un a-t'il une idée pour résoudre ce problème ?
A supposer que sshd ne soit pas en cause, soit un problème de config réseau, soit le firewall local trop restrictif.
Salut,
Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien.
Mais ssh (ou scp) ne marche pas dans la direction
Autres ordis---->portable, alors que ça marche bien dans l'autre sens.
j'utilise le script suivant pour faire marcher le wifi :
iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX
route add 192.168.1.1 dev eth1
route add default gw 192.168.1.1
ifconfig eth0 down
Un peu foireuse cette configuration réseau. C'est déjà bien beau que ça
cause dans un sens. Et pourquoi cette route d'hôte vers 192.168.1.1 (qui
est le routeur, je suppose) plutôt que vers le réseau 192.168.1.0/24
tout entier ? Je serais intéressé par la sortie d'ifconfig -a et route
-n (ou ip addr et ip route).
quelqu'un a-t'il une idée pour résoudre ce problème ?
A supposer que sshd ne soit pas en cause, soit un problème de config
réseau, soit le firewall local trop restrictif.
Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien. Mais ssh (ou scp) ne marche pas dans la direction Autres ordis---->portable, alors que ça marche bien dans l'autre sens.
j'utilise le script suivant pour faire marcher le wifi : iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX route add 192.168.1.1 dev eth1 route add default gw 192.168.1.1 ifconfig eth0 down
Un peu foireuse cette configuration réseau. C'est déjà bien beau que ça cause dans un sens. Et pourquoi cette route d'hôte vers 192.168.1.1 (qui est le routeur, je suppose) plutôt que vers le réseau 192.168.1.0/24 tout entier ? Je serais intéressé par la sortie d'ifconfig -a et route -n (ou ip addr et ip route).
quelqu'un a-t'il une idée pour résoudre ce problème ?
A supposer que sshd ne soit pas en cause, soit un problème de config réseau, soit le firewall local trop restrictif.
Droopy191
j'ai installé Slackware 12.0 sur mon portable inspiron 9300 et j'ai un problème avec ssh.
Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien. Mais ssh (ou scp) ne marche pas dans la direction Autres ordis---->portable, alors que ça marche bien dans l'autre sens.
j'utilise le script suivant pour faire marcher le wifi : iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX route add 192.168.1.1 dev eth1 route add default gw 192.168.1.1 ifconfig eth0 down
quelqu'un a-t'il une idée pour résoudre ce problème ?
Merci d'avance
Salut,
Regarde dans /var/log/authauth.log ( ou variante, connait pas Slackware ) keskidi ?
Ca te permettra de voir si c'est sshd qui refuse la connexion ou que tu n'atteint meme pas ssh.
-- DR
j'ai installé Slackware 12.0 sur mon portable inspiron 9300 et j'ai un
problème avec ssh.
Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien.
Mais ssh (ou scp) ne marche pas dans la direction
Autres ordis---->portable, alors que ça marche bien dans l'autre sens.
j'utilise le script suivant pour faire marcher le wifi :
iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX
route add 192.168.1.1 dev eth1
route add default gw 192.168.1.1
ifconfig eth0 down
quelqu'un a-t'il une idée pour résoudre ce problème ?
Merci d'avance
Salut,
Regarde dans /var/log/authauth.log ( ou variante, connait pas Slackware )
keskidi ?
Ca te permettra de voir si c'est sshd qui refuse la connexion ou que tu
n'atteint meme pas ssh.
j'ai installé Slackware 12.0 sur mon portable inspiron 9300 et j'ai un problème avec ssh.
Je me connecte en wifi (ipw2200), via un routeur. Internet marche bien. Mais ssh (ou scp) ne marche pas dans la direction Autres ordis---->portable, alors que ça marche bien dans l'autre sens.
j'utilise le script suivant pour faire marcher le wifi : iwconfig eth1 essid "linksys" mode Managed key XXXXXXXXXX route add 192.168.1.1 dev eth1 route add default gw 192.168.1.1 ifconfig eth0 down
quelqu'un a-t'il une idée pour résoudre ce problème ?
Merci d'avance
Salut,
Regarde dans /var/log/authauth.log ( ou variante, connait pas Slackware ) keskidi ?
Ca te permettra de voir si c'est sshd qui refuse la connexion ou que tu n'atteint meme pas ssh.
-- DR
jmdr
problème résolu avec :
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
Merci pour toutes les réponses
problème résolu avec :
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
Merci pour toutes les réponses
Pascal Hambourg
problème résolu avec :
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
Je m'en doutais. Explication possible : La machine n'ayant qu'une route directe vers le routeur et pas vers le sous-réseau local, elle envoie le trafic destiné aux autres machines du réseau local via le routeur. Celui-ci NATe l'adresse source avant de faire suivre le paquet vers sa destination finale, comme lors d'une communication vers internet (cela permet aux redirections NAT de fonctionner même depuis le réseau local). La destination reçoit le paquet avec l'adresse source du routeur et y répond. Le routeur reçoit le paquet, le reconnaît comme une réponse au paquet précédent, remet l'adresse destination originale et renvoie le paquet à notre machine. Tout va bien dans ce sens.
Dans l'autre sens, maintenant. Une machine du réseau local veut communiquer avec notre machine. Elle a normalement une route directe vers le sous-réseau local, donc elle envoie directement le paquet à la cible (notre machine). Celle-ci y répond, mais fait transiter le paquet de réponse par le routeur, comme précédemment, puisqu'elle n'a pas de route directe vers la destination. Le routeur reçoit le paquet de réponse *sans avoir vu le paquet initial* et a deux possibilités : - soit il le considère comme invalide et le rejette ; - soit il le considère comme une nouvelle connexion, le NATe et le transfère à sa destination. Problème : le paquet étant NATé, l'adresse source ne correspond pas à l'adresse de destination du paquet initial, et la machine ayant émis ce dernier ne le reconnaît pas comme une réponse. Bref, dans les deux cas ça ne marche pas. Le grand méchant NAT a encore frappé !
L'ajout d'une route directe vers le sous-réseau local entier résoud le problème en évitant que les paquets destinés au réseau local transitent par le routeur et soient NATés.
Il reste néanmoins un mystère : dans ton script je ne vois pas d'attribution d'une adresse IP à l'interface wifi eth1. La seule idée qui me vient est que la machine continue à utiliser l'adresse IP de l'interface ethernet eth0, bien que cette dernière soit désactivée. Si une adresse IP avec le masque qui va bien avaient été configurés sur l'interface wifi, la création de la route directe vers le sous-réseau aurait été implicite et il n'aurait pas été nécessaire de le faire manuellement.
problème résolu avec :
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
Je m'en doutais. Explication possible :
La machine n'ayant qu'une route directe vers le routeur et pas vers le
sous-réseau local, elle envoie le trafic destiné aux autres machines du
réseau local via le routeur. Celui-ci NATe l'adresse source avant de
faire suivre le paquet vers sa destination finale, comme lors d'une
communication vers internet (cela permet aux redirections NAT de
fonctionner même depuis le réseau local). La destination reçoit le
paquet avec l'adresse source du routeur et y répond. Le routeur reçoit
le paquet, le reconnaît comme une réponse au paquet précédent, remet
l'adresse destination originale et renvoie le paquet à notre machine.
Tout va bien dans ce sens.
Dans l'autre sens, maintenant. Une machine du réseau local veut
communiquer avec notre machine. Elle a normalement une route directe
vers le sous-réseau local, donc elle envoie directement le paquet à la
cible (notre machine). Celle-ci y répond, mais fait transiter le paquet
de réponse par le routeur, comme précédemment, puisqu'elle n'a pas de
route directe vers la destination. Le routeur reçoit le paquet de
réponse *sans avoir vu le paquet initial* et a deux possibilités :
- soit il le considère comme invalide et le rejette ;
- soit il le considère comme une nouvelle connexion, le NATe et le
transfère à sa destination. Problème : le paquet étant NATé, l'adresse
source ne correspond pas à l'adresse de destination du paquet initial,
et la machine ayant émis ce dernier ne le reconnaît pas comme une
réponse.
Bref, dans les deux cas ça ne marche pas. Le grand méchant NAT a encore
frappé !
L'ajout d'une route directe vers le sous-réseau local entier résoud le
problème en évitant que les paquets destinés au réseau local transitent
par le routeur et soient NATés.
Il reste néanmoins un mystère : dans ton script je ne vois pas
d'attribution d'une adresse IP à l'interface wifi eth1. La seule idée
qui me vient est que la machine continue à utiliser l'adresse IP de
l'interface ethernet eth0, bien que cette dernière soit désactivée.
Si une adresse IP avec le masque qui va bien avaient été configurés sur
l'interface wifi, la création de la route directe vers le sous-réseau
aurait été implicite et il n'aurait pas été nécessaire de le faire
manuellement.
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
Je m'en doutais. Explication possible : La machine n'ayant qu'une route directe vers le routeur et pas vers le sous-réseau local, elle envoie le trafic destiné aux autres machines du réseau local via le routeur. Celui-ci NATe l'adresse source avant de faire suivre le paquet vers sa destination finale, comme lors d'une communication vers internet (cela permet aux redirections NAT de fonctionner même depuis le réseau local). La destination reçoit le paquet avec l'adresse source du routeur et y répond. Le routeur reçoit le paquet, le reconnaît comme une réponse au paquet précédent, remet l'adresse destination originale et renvoie le paquet à notre machine. Tout va bien dans ce sens.
Dans l'autre sens, maintenant. Une machine du réseau local veut communiquer avec notre machine. Elle a normalement une route directe vers le sous-réseau local, donc elle envoie directement le paquet à la cible (notre machine). Celle-ci y répond, mais fait transiter le paquet de réponse par le routeur, comme précédemment, puisqu'elle n'a pas de route directe vers la destination. Le routeur reçoit le paquet de réponse *sans avoir vu le paquet initial* et a deux possibilités : - soit il le considère comme invalide et le rejette ; - soit il le considère comme une nouvelle connexion, le NATe et le transfère à sa destination. Problème : le paquet étant NATé, l'adresse source ne correspond pas à l'adresse de destination du paquet initial, et la machine ayant émis ce dernier ne le reconnaît pas comme une réponse. Bref, dans les deux cas ça ne marche pas. Le grand méchant NAT a encore frappé !
L'ajout d'une route directe vers le sous-réseau local entier résoud le problème en évitant que les paquets destinés au réseau local transitent par le routeur et soient NATés.
Il reste néanmoins un mystère : dans ton script je ne vois pas d'attribution d'une adresse IP à l'interface wifi eth1. La seule idée qui me vient est que la machine continue à utiliser l'adresse IP de l'interface ethernet eth0, bien que cette dernière soit désactivée. Si une adresse IP avec le masque qui va bien avaient été configurés sur l'interface wifi, la création de la route directe vers le sous-réseau aurait été implicite et il n'aurait pas été nécessaire de le faire manuellement.
jmdr
Pascal Hambourg wrote:
problème résolu avec :
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
Je m'en doutais. Explication possible : La machine n'ayant qu'une route directe vers le routeur et pas vers le sous-réseau local, elle envoie le trafic destiné aux autres machines du réseau local via le routeur. Celui-ci NATe l'adresse source avant de faire suivre le paquet vers sa destination finale, comme lors d'une communication vers internet (cela permet aux redirections NAT de fonctionner même depuis le réseau local). La destination reçoit le paquet avec l'adresse source du routeur et y répond. Le routeur reçoit le paquet, le reconnaît comme une réponse au paquet précédent, remet l'adresse destination originale et renvoie le paquet à notre machine. Tout va bien dans ce sens.
Dans l'autre sens, maintenant. Une machine du réseau local veut communiquer avec notre machine. Elle a normalement une route directe vers le sous-réseau local, donc elle envoie directement le paquet à la cible (notre machine). Celle-ci y répond, mais fait transiter le paquet de réponse par le routeur, comme précédemment, puisqu'elle n'a pas de route directe vers la destination. Le routeur reçoit le paquet de réponse *sans avoir vu le paquet initial* et a deux possibilités : - soit il le considère comme invalide et le rejette ; - soit il le considère comme une nouvelle connexion, le NATe et le transfère à sa destination. Problème : le paquet étant NATé, l'adresse source ne correspond pas à l'adresse de destination du paquet initial, et la machine ayant émis ce dernier ne le reconnaît pas comme une réponse. Bref, dans les deux cas ça ne marche pas. Le grand méchant NAT a encore frappé !
L'ajout d'une route directe vers le sous-réseau local entier résoud le problème en évitant que les paquets destinés au réseau local transitent par le routeur et soient NATés.
Il reste néanmoins un mystère : dans ton script je ne vois pas d'attribution d'une adresse IP à l'interface wifi eth1. La seule idée qui me vient est que la machine continue à utiliser l'adresse IP de l'interface ethernet eth0, bien que cette dernière soit désactivée. Si une adresse IP avec le masque qui va bien avaient été configurés sur l'interface wifi, la création de la route directe vers le sous-réseau aurait été implicite et il n'aurait pas été nécessaire de le faire manuellement.
Bravo ! J'ai un fichier d'initialisation '/etc/rc.d/rc.inet1.conf' qui contenait ce qui suit :
# Config information for eth0: IPADDR[0]="192.168.1.105" NETMASK[0]="255.255.255.0" USE_DHCP[0]="" DHCP_HOSTNAME[0]=""
# Config information for eth1: IPADDR[1]="" NETMASK[1]="" USE_DHCP[1]="" DHCP_HOSTNAME[1]=""
Je l'ai modifié pour remplir IPADDR[1] et NETMASK[1], et maintenant ça marche sans utiliser l'instruction route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
Pascal Hambourg wrote:
problème résolu avec :
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
Je m'en doutais. Explication possible :
La machine n'ayant qu'une route directe vers le routeur et pas vers le
sous-réseau local, elle envoie le trafic destiné aux autres machines
du réseau local via le routeur. Celui-ci NATe l'adresse source avant
de faire suivre le paquet vers sa destination finale, comme lors d'une
communication vers internet (cela permet aux redirections NAT de
fonctionner même depuis le réseau local). La destination reçoit le
paquet avec l'adresse source du routeur et y répond. Le routeur reçoit
le paquet, le reconnaît comme une réponse au paquet précédent, remet
l'adresse destination originale et renvoie le paquet à notre machine.
Tout va bien dans ce sens.
Dans l'autre sens, maintenant. Une machine du réseau local veut
communiquer avec notre machine. Elle a normalement une route directe
vers le sous-réseau local, donc elle envoie directement le paquet à la
cible (notre machine). Celle-ci y répond, mais fait transiter le
paquet de réponse par le routeur, comme précédemment, puisqu'elle n'a
pas de route directe vers la destination. Le routeur reçoit le paquet
de réponse *sans avoir vu le paquet initial* et a deux possibilités :
- soit il le considère comme invalide et le rejette ;
- soit il le considère comme une nouvelle connexion, le NATe et le
transfère à sa destination. Problème : le paquet étant NATé, l'adresse
source ne correspond pas à l'adresse de destination du paquet initial,
et la machine ayant émis ce dernier ne le reconnaît pas comme une
réponse.
Bref, dans les deux cas ça ne marche pas. Le grand méchant NAT a
encore frappé !
L'ajout d'une route directe vers le sous-réseau local entier résoud le
problème en évitant que les paquets destinés au réseau local
transitent par le routeur et soient NATés.
Il reste néanmoins un mystère : dans ton script je ne vois pas
d'attribution d'une adresse IP à l'interface wifi eth1. La seule idée
qui me vient est que la machine continue à utiliser l'adresse IP de
l'interface ethernet eth0, bien que cette dernière soit désactivée. Si
une adresse IP avec le masque qui va bien avaient été configurés sur
l'interface wifi, la création de la route directe vers le sous-réseau
aurait été implicite et il n'aurait pas été nécessaire de le faire
manuellement.
Bravo ! J'ai un fichier d'initialisation '/etc/rc.d/rc.inet1.conf' qui
contenait ce qui suit :
# Config information for eth0:
IPADDR[0]="192.168.1.105"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""
# Config information for eth1:
IPADDR[1]=""
NETMASK[1]=""
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""
Je l'ai modifié pour remplir IPADDR[1] et NETMASK[1], et maintenant ça
marche sans utiliser l'instruction
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
Je m'en doutais. Explication possible : La machine n'ayant qu'une route directe vers le routeur et pas vers le sous-réseau local, elle envoie le trafic destiné aux autres machines du réseau local via le routeur. Celui-ci NATe l'adresse source avant de faire suivre le paquet vers sa destination finale, comme lors d'une communication vers internet (cela permet aux redirections NAT de fonctionner même depuis le réseau local). La destination reçoit le paquet avec l'adresse source du routeur et y répond. Le routeur reçoit le paquet, le reconnaît comme une réponse au paquet précédent, remet l'adresse destination originale et renvoie le paquet à notre machine. Tout va bien dans ce sens.
Dans l'autre sens, maintenant. Une machine du réseau local veut communiquer avec notre machine. Elle a normalement une route directe vers le sous-réseau local, donc elle envoie directement le paquet à la cible (notre machine). Celle-ci y répond, mais fait transiter le paquet de réponse par le routeur, comme précédemment, puisqu'elle n'a pas de route directe vers la destination. Le routeur reçoit le paquet de réponse *sans avoir vu le paquet initial* et a deux possibilités : - soit il le considère comme invalide et le rejette ; - soit il le considère comme une nouvelle connexion, le NATe et le transfère à sa destination. Problème : le paquet étant NATé, l'adresse source ne correspond pas à l'adresse de destination du paquet initial, et la machine ayant émis ce dernier ne le reconnaît pas comme une réponse. Bref, dans les deux cas ça ne marche pas. Le grand méchant NAT a encore frappé !
L'ajout d'une route directe vers le sous-réseau local entier résoud le problème en évitant que les paquets destinés au réseau local transitent par le routeur et soient NATés.
Il reste néanmoins un mystère : dans ton script je ne vois pas d'attribution d'une adresse IP à l'interface wifi eth1. La seule idée qui me vient est que la machine continue à utiliser l'adresse IP de l'interface ethernet eth0, bien que cette dernière soit désactivée. Si une adresse IP avec le masque qui va bien avaient été configurés sur l'interface wifi, la création de la route directe vers le sous-réseau aurait été implicite et il n'aurait pas été nécessaire de le faire manuellement.
Bravo ! J'ai un fichier d'initialisation '/etc/rc.d/rc.inet1.conf' qui contenait ce qui suit :
# Config information for eth0: IPADDR[0]="192.168.1.105" NETMASK[0]="255.255.255.0" USE_DHCP[0]="" DHCP_HOSTNAME[0]=""
# Config information for eth1: IPADDR[1]="" NETMASK[1]="" USE_DHCP[1]="" DHCP_HOSTNAME[1]=""
Je l'ai modifié pour remplir IPADDR[1] et NETMASK[1], et maintenant ça marche sans utiliser l'instruction route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
