Voici le dump cote serveur:
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:31:40.291456 IP teucidide.york.ac.uk.41259 > 192.168.0.101.ssh: S
2629512366:2629512366(0) win 5840 <mss 1460,sackOK,timestamp 142355515
0,nop,wscale 6>
18:32:01.293330 IP teucidide.york.ac.uk.41259 > 192.168.0.101.ssh: S
2629512366:2629512366(0) win 5840 <mss 1460,sackOK,timestamp 142376515
0,nop,wscale 6>
Cote client:
18:23:46.181166 IP teucidide.york.ac.uk > 192.168.0.101: ICMP host
teucidide.york.ac.uk unreachable - admin prohibited, length 68
18:23:57.065783 IP 192.168.0.101.ssh > teucidide.york.ac.uk.39655: S
2016757580:2016757580(0) ack 3766166664 win 5776 <mss
1456,sackOK,timestamp 31326282 141880302,nop,wscale 6>
18:23:57.065803 IP teucidide.york.ac.uk > 192.168.0.101: ICMP host
teucidide.york.ac.uk unreachable - admin prohibited, length 68
18:23:58.191114 IP 192.168.0.101.ssh > teucidide.york.ac.uk.39655: S
2016757580:2016757580(0) ack 3766166664 win 5776 <mss
1456,sackOK,timestamp 31327407 141880302,nop,wscale 6>
J'ai essaye la route, mais cela ne change rien.
Autre chose, si la machine qui fait le vpn, n'est pas celle qui
recoit le ssh local (cad si je change le port 22 du router vers une
autre machine), le vpn ne peut pas etre etabli.
Je pourrais detruire le vpn et le retablir a la demande, le probleme
est que cela casse les connections ssh, donc pas vraiment pratique.
Voila,
Je veux essayer d'en parler au computer support demain.
Merci pour les suggestion et l'aide.
> Le dimanche 10 février, Dr P Dupre a écrit :
>> Si on accepte le schema que tu proposes, peut-on essaye une manip sur le
>> prouver ?
>
> Lance tcpdump sur les deux machines aux extrémités et essaye de pinguer
> 82.3.201.160 depuis le client. Tu devrais voir :
>
> - sur le serveur : des echo request 144.32.52.29 -> 192.168.0.xx où
> 192.168.0.xx est l'adresse de l'inteface eth0 de ton serveur ;
>
> - sur le client : des echo reply 144.32.196.175 -> 144.32.52.29, donc
> en provenance de NAT2.
>
> Mais tu peux aussi ne rien voir en fonction des règles de filtrage sur
> les différents routeurs en chemin !
>
>> Eventuellement une solution !
>
> Si jamais le réseau du client forwarde les paquets vers le vlan, tu peux
> essayer
>
> route add -net 172.0.0.0 netmask 255.0.0.0 gw 144.32.52.142
>
> sur le client, et ensuite tu contactes le serveur sur son adresse vlan
> (celle en 172.xx.xx.xx).
>
> Sinon, je ne vois pas. Peut-être avec le « policy based routing » tu
> peux demander au serveur de router via 192.168.0.1 tous les paquets dont
> l'adresse *source* est 192.168.0.xx (l'adresse eth0 du serveur).
> Normalement la décision de routage se fait en fonction de l'adresse
> destination et c'est pour ça que ça passe par l'interface ppp0.
>
> Ou alors tu débranches et rebranches ppp0 en fonction des besoins...
>
> Ciao,
>
> Edgar.
>
>
>
--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Patrick Dupré pd520@???
University of York Department of Chemistry
Heslington, York YO10 5DD United Kingdom
Phone: +44-(0)-1904-434384 Fax: +44-(0)-1904-432516
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
