je tente de configurer linux (trixbox 2 bas=E9 sur Centos 4.4) comme
client VPN de Windows 2003.
Je passe bien l'autentification et j'obtien une adresse IP:
> ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:1.0.0.17 P-t-P:1.0.0.1 Mask:255.255.255.255
Voici la table de routage:
> ip route show
1=2E0.0.1 dev ppp0 proto kernel scope link src 1.0.0.17
10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98
169.254.0.0/16 dev eth0 scope link
default via 1.0.0.1 dev ppp0
Le probleme est que je n'arrive pas =E0 pinguer la passerele 1.0.0.1
[root@asterisk1 ~]# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96
bytes
09:04:22.566841 IP 1.0.0.11 > 1.0.0.1: icmp 64: echo request seq 88
09:04:23.566675 IP 1.0.0.11 > 1.0.0.1: icmp 64: echo request seq 89
09:04:24.566509 IP 1.0.0.11 > 1.0.0.1: icmp 64: echo request seq 90
Alors que si je prend un client Windows =E0 cot=E9 avec la meme config -
ca ping sans probleme et Internet marche.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Shamil
juste remarque:
dans ifconfig on vois l'IP 1.0.0.17, alors que dans tcpdum c'est 1.0.0.17 - c'est juste que se sont des sessions differentes. Mais le résultat est le meme
juste remarque:
dans ifconfig on vois l'IP 1.0.0.17, alors que dans tcpdum c'est
1.0.0.17 - c'est juste que se sont des sessions differentes. Mais le
résultat est le meme
dans ifconfig on vois l'IP 1.0.0.17, alors que dans tcpdum c'est 1.0.0.17 - c'est juste que se sont des sessions differentes. Mais le résultat est le meme
Pascal Hambourg
Salut
je tente de configurer linux (trixbox 2 basé sur Centos 4.4) comme client VPN de Windows 2003. [...]
ppp0 Link encap:Point-to-Point Protocol inet addr:1.0.0.17 P-t-P:1.0.0.1 Mask:255.255.255.255
Drôles d'adresses qui font partie d'une plage réservée par l'IANA.
Voici la table de routage:
1.0.0.1 dev ppp0 proto kernel scope link src 1.0.0.17 10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98 169.254.0.0/16 dev eth0 scope link default via 1.0.0.1 dev ppp0
Et avant l'établissement du VPN ?
Le probleme est que je n'arrive pas à pinguer la passerele 1.0.0.1
Le serveur VPN est-il dans le même sous-réseau 10.1.13.0/24 que le client ?
Salut
je tente de configurer linux (trixbox 2 basé sur Centos 4.4) comme
client VPN de Windows 2003.
[...]
ppp0 Link encap:Point-to-Point Protocol
inet addr:1.0.0.17 P-t-P:1.0.0.1 Mask:255.255.255.255
Drôles d'adresses qui font partie d'une plage réservée par l'IANA.
Voici la table de routage:
1.0.0.1 dev ppp0 proto kernel scope link src 1.0.0.17
10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98
169.254.0.0/16 dev eth0 scope link
default via 1.0.0.1 dev ppp0
Et avant l'établissement du VPN ?
Le probleme est que je n'arrive pas à pinguer la passerele 1.0.0.1
Le serveur VPN est-il dans le même sous-réseau 10.1.13.0/24 que le client ?
je tente de configurer linux (trixbox 2 basé sur Centos 4.4) comme client VPN de Windows 2003. [...]
ppp0 Link encap:Point-to-Point Protocol inet addr:1.0.0.17 P-t-P:1.0.0.1 Mask:255.255.255.255
Drôles d'adresses qui font partie d'une plage réservée par l'IANA.
Voici la table de routage:
1.0.0.1 dev ppp0 proto kernel scope link src 1.0.0.17 10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98 169.254.0.0/16 dev eth0 scope link default via 1.0.0.1 dev ppp0
Et avant l'établissement du VPN ?
Le probleme est que je n'arrive pas à pinguer la passerele 1.0.0.1
Le serveur VPN est-il dans le même sous-réseau 10.1.13.0/24 que le client ?
Shamil
Salut,
Le serveur VPN est-il dans le même sous-réseau 10.1.13.0/24 que le cl ient ?
Oui, le serveur vpn a deux adresses: 10.1.13.1 et 1.0.0.1.L'adresse de client est 10.1.13.98.
avant l'etablissement de ppp0 la table de routage de client contient des regles suivantes:
10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98 169.254.0.0/16 dev eth0 scope link default via 10.1.13.1 dev eth0
Salut,
Le serveur VPN est-il dans le même sous-réseau 10.1.13.0/24 que le cl ient ?
Oui, le serveur vpn a deux adresses: 10.1.13.1 et 1.0.0.1.L'adresse de
client est 10.1.13.98.
avant l'etablissement de ppp0 la table de routage de client contient
des regles suivantes:
10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98
169.254.0.0/16 dev eth0 scope link
default via 10.1.13.1 dev eth0
Le serveur VPN est-il dans le même sous-réseau 10.1.13.0/24 que le cl ient ?
Oui, le serveur vpn a deux adresses: 10.1.13.1 et 1.0.0.1.L'adresse de client est 10.1.13.98.
avant l'etablissement de ppp0 la table de routage de client contient des regles suivantes:
10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98 169.254.0.0/16 dev eth0 scope link default via 10.1.13.1 dev eth0
Pascal Hambourg
Le serveur VPN est-il dans le même sous-réseau 10.1.13.0/24 que le client ?
Oui, le serveur vpn a deux adresses: 10.1.13.1 et 1.0.0.1.L'adresse de client est 10.1.13.98.
D'accord. Si ça n'avait pas été le cas, et si le serveur VPN avait été joignable via la route par défaut initiale, il aurait fallu penser à préserver la route vers le serveur pour que celui-ci reste joignable après que la route par défaut a été modifiée par pppd. Il me semble que c'est ce que font d'autres VPN comme OpenVPN (et le client VPN PPTP de Windows aussi).
avant l'etablissement de ppp0 la table de routage de client contient des regles suivantes:
10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98 169.254.0.0/16 dev eth0 scope link default via 10.1.13.1 dev eth0
Je ne vois rien d'anormal du côté des routes. N'y aurait-il pas du filtrage IP qui pourrait bloquer le trafic sur ppp0 ? Lors de la tentative de ping vois-tu du trafic GRE (protocole IP 47) entre le client 10.1.13.98 et le serveur 10.1.13.1 sur l'interface eth0 ?
Le serveur VPN est-il dans le même sous-réseau 10.1.13.0/24 que le client ?
Oui, le serveur vpn a deux adresses: 10.1.13.1 et 1.0.0.1.L'adresse de
client est 10.1.13.98.
D'accord. Si ça n'avait pas été le cas, et si le serveur VPN avait été
joignable via la route par défaut initiale, il aurait fallu penser à
préserver la route vers le serveur pour que celui-ci reste joignable
après que la route par défaut a été modifiée par pppd. Il me semble que
c'est ce que font d'autres VPN comme OpenVPN (et le client VPN PPTP de
Windows aussi).
avant l'etablissement de ppp0 la table de routage de client contient
des regles suivantes:
10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98
169.254.0.0/16 dev eth0 scope link
default via 10.1.13.1 dev eth0
Je ne vois rien d'anormal du côté des routes. N'y aurait-il pas du
filtrage IP qui pourrait bloquer le trafic sur ppp0 ? Lors de la
tentative de ping vois-tu du trafic GRE (protocole IP 47) entre le
client 10.1.13.98 et le serveur 10.1.13.1 sur l'interface eth0 ?
Le serveur VPN est-il dans le même sous-réseau 10.1.13.0/24 que le client ?
Oui, le serveur vpn a deux adresses: 10.1.13.1 et 1.0.0.1.L'adresse de client est 10.1.13.98.
D'accord. Si ça n'avait pas été le cas, et si le serveur VPN avait été joignable via la route par défaut initiale, il aurait fallu penser à préserver la route vers le serveur pour que celui-ci reste joignable après que la route par défaut a été modifiée par pppd. Il me semble que c'est ce que font d'autres VPN comme OpenVPN (et le client VPN PPTP de Windows aussi).
avant l'etablissement de ppp0 la table de routage de client contient des regles suivantes:
10.1.13.0/24 dev eth0 proto kernel scope link src 10.1.13.98 169.254.0.0/16 dev eth0 scope link default via 10.1.13.1 dev eth0
Je ne vois rien d'anormal du côté des routes. N'y aurait-il pas du filtrage IP qui pourrait bloquer le trafic sur ppp0 ? Lors de la tentative de ping vois-tu du trafic GRE (protocole IP 47) entre le client 10.1.13.98 et le serveur 10.1.13.1 sur l'interface eth0 ?
