SMPFR

alors pour le moment je lui ai foutu une ip fixe (101/102) au moins je suis sur qu'il y ai pas une merde a la con côté openvpn qui fait pas un truc car c'était pas en fixe

dans le server.conf
[cpp] client-config-dir ccd
client-to-client
server 192.168.10.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.10.0 255.255.255.0"[/cpp]
du coup sur le client j'ai bien
[cpp]route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 129.X 0.0.0.0 UG 0 0 0 eth0
129.X 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 192.168.10.102 255.255.255.0 UG 0 0 0 tun0
192.168.10.0 192.168.10.102 255.255.255.0 UG 0 0 0 tun0
192.168.10.102 0.0.0.0 255.255.255.255 UH 0 0 0 tun0


[/cpp]
Depuis le serveur je ping bien la 101 (le client) et j'arrive à avoir la page web http://192.168.10.101 (donc ca papote bien)

Depuis le Client je ping bien la 10.1 (openvpn server)
je ping bien et j'accède au LAN côté serveur en 192.168.1.0 (pareil je peux ouvrir les pages web de mes serveurs web donc ca papote)

par contre si j'ouvre mon http://ip_public:89 que je déclare un NAT 89 -> 192.168.20.101:80 impossible
je vois passer ce genre de paquets via tcpdump sur mon client vpn
[cpp]
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
13:44:20.982527 IP (nom_dns_proxy_pc).38321 > 192.168.10.101.http: Flags [S], seq 2964946674, win 16384, options [mss 1350,unknown-34 0x01000ac5fe8c], length 0
13:44:23.652238 IP (nom_dns_proxy_pc).38321 > 192.168.10.101.http: Flags [S], seq 2964946674, win 16384, options [mss 1350], length 0
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel[/cpp]
je vois même nom_dns_prox_pc qui est le proxy de mon pc fixe qui fait la demande du site web donc ca a l'air de marcher

si j'initie depuis chez moi j'ai bien

[cpp]13:48:57.386042 IP X.fbx.proxad.net.51562 > 192.168.20.101.http: Flags [S], seq 1223433549, win 8192, options [mss 1350,nop,wscale 8,nop,nop,sackOK], length 0
13:48:57.636727 IP X.fbx.proxad.net.51563 > 192.168.20.101.http: Flags [S], seq 2435691650, win 8192, options [mss 1350,nop,wscale 8,nop,nop,sackOK], length 0

[/cpp]
donc pourquoi ce putain de truc veut pas repartir


TheM j'ai regardé tes options mais c'est propre à windows en fait ces soucis d'application
la si je modifie mes routes sur le server.conf je vois bien arriver la route sur le client

----
Z j'ai ajouté la route que tu m'a indiquée

route -n
 Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.102  0.0.0.0         UG    0      0        0 tun0
0.0.0.0         129.X           0.0.0.0         UG    0      0        0 eth0
129.X           0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     192.168.10.102  255.255.255.0   UG    0      0        0 tun0
192.168.10.0    192.168.10.102  255.255.255.0   UG    0      0        0 tun0
192.168.10.102  0.0.0.0         255.255.255.255 UH    0      0        0 tun0

et donc à partir de la
je ping plus l'ip openvpn server ni rien en fait ...
et même pire openvpn se déconnecte vu qu'il passe par le net

comme je le disais avant, vu que destination est 0.0.0.0, c'est normal que ça coupe puisque ça deviens ta route par defaut.
(METRIC 0 et en premier dans la liste)

le Iface, ça dit juste par quelle interface faut envoyer les paquets, pas d'où ils viennent.

oui ca me semble logique aussi maintenant je comprends toujours pas
est-ce que c'est le fait que le packet dans le tcpdump soit initialisé depuis le client distant ( et donc ip pub) que du coup il essai de répondre dessus et le fait passer par la route defaut au lieu de la renvoyer par la openvpn ?

est-ce que le principe de fonctionnement est celui la ?
auquel cas il faut que je re-regarde les options de masquerade pour un paquet qui arrive du net et pars vers le VPN non ?

iptables -t nat -A POSTROUTING -d 192.168.10.0/24 -o tun0 -j MASQUERADE

\o/
après avoir routé les packets, on remplace l'ip source pour les packets à destination du vpn sur l'interface vpn ...
Z m'avait soufflée le truc dans un mp au début mais les paramètres (source au lieu de destination) n'était pas bon du coup je pigeai pas
la ca a l'air de marcher !

et effectivement dans le tcpdump

[cpp]root@ubuntu:/var/log/nginx# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
14:55:49.800332 IP 192.168.10.1.42092 > 192.168.10.101.http: Flags [S], seq 1948396861, win 16384, options [mss 1350,unknown-34 0x01000ac5fe8c], length 0
14:55:49.800383 IP 192.168.10.101.http > 192.168.10.1.42092: Flags [S.], seq 3724641815, ack 1948396862, win 29200, options [mss 1460], length 0
14:55:49.861823 IP 192.168.10.1.42092 > 192.168.10.101.http: Flags [.], ack 1, win 17550, length 0
14:55:49.877763 IP 192.168.10.1.42092 > 192.168.10.101.http: Flags [P.], seq 1:480, ack 1, win 17550, length 479
14:55:49.877804 IP 192.168.10.101.http > 192.168.10.1.42092: Flags [.], ack 480, win 30016, length 0
14:55:49.878003 IP 192.168.10.101.http > 192.168.10.1.42092: Flags [P.], seq 1:189, ack 480, win 30016, length 188
14:55:49.911047 IP 192.168.10.1.42092 > 192.168.10.101.http: Flags [.], ack 189, win 17362, length 0

[/cpp]

c'était vraiment con ein .... Z tu as le droit de me fouetter !

Non je suis gentille
Je suis contente que t'ais pu trouver