qu'es-ce qu'une erreur PID_ERR replay-window backtrack occurred [4] [SSL-0] | (openvpn) ??

Tachyon · 01 janv. 2018, 20:38

bonsoir ,

pourriez-vous éclairer mes synapses , depuis quelques jours j'ai ceci dans openvpn quelques secondes après connexion

PID_ERR replay-window backtrack occurred [4] [SSL-0] [0____00000000000000000000000000000000000000000000000000000000000]

02 janv. 2018, 06:25

Salut,
Côté client ou serveur ?
Debian stable de chaque côté du vpn ?

franb · 02 janv. 2018, 12:10

De ce que je comprends ce serait un souci de saturation dans la réception. Est ce que basculer en TCP plutôt que UDP change quelque chose?

Tachyon · 02 janv. 2018, 15:39

franb a écrit : Est ce que basculer en TCP plutôt que UDP change quelque chose?

je viens de prendre le fichier serveur en TCP sur le site de mon fournisseur Vpn et ça fonctionne plutôt bien , plus d'erreur PID_ERR replay-window

mais ceci a la place :

RTNETLINK answers: File exists
Tue Jan 2 15:28:43 2018 us=189208 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Jan 2 15:28:43 2018 us=189284 Initialization Sequence Completed

je viens de vérifier et je suis bien dans le tunnel vpn , cet erreur est elle importante ?

franb · 03 janv. 2018, 11:49

Hum, un souci dans la tabe de routage, où tu rajoutes une passerelle déjà existante... Ça semble être un averstissement, ça fonctionne qd même? Quelle est ta table de routage?

Tachyon · 03 janv. 2018, 15:30

franb a écrit : Hum, un souci dans la tabe de routage, où tu rajoutes une passerelle déjà existante... Ça semble être un averstissement, ça fonctionne qd même? Quelle est ta table de routage?

cela fonctionne effectivement , lorsque je vais voir sur un site pour connaître mon ip actuelle , il m'affiche bien le serveur du pays distant ainsi que l'ip associé

franb a écrit :Quelle est ta table de routage?

es-ce avec un ip route pour connaître la table de routage ?

Code : Tout sélectionner

$ ip route
0.0.0.0/1 via 10.10.41.193 dev tun0 
default via 192.168.1.1 dev eth0 
10.10.41.192/26 dev tun0 proto kernel scope link src 10.10.41.194 
46.246.16.2 via 192.168.1.1 dev eth0 
128.0.0.0/1 via 10.10.41.193 dev tun0 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.52

franb · 03 janv. 2018, 16:10

Tachyon a écrit : ↑03 janv. 2018, 15:30 es-ce avec un ip route pour connaître la table de routage ?
Code : Tout sélectionner
$ ip route
0.0.0.0/1 via 10.10.41.193 dev tun0 
default via 192.168.1.1 dev eth0 
10.10.41.192/26 dev tun0 proto kernel scope link src 10.10.41.194 
46.246.16.2 via 192.168.1.1 dev eth0 
128.0.0.0/1 via 10.10.41.193 dev tun0 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.52

Tes IPS seraient 192.168.1.52 (eth0), 10.10.41.194 (tun0)
De ce que je lis, tu as une passerelle par défaut qui est 192.168.1.1 (ta box je présue).
Tu as une route vers 46.246.16.2 qui doit être ton serveur VPN via la passerelle standard
la route 10.10.41.192/26 dev tun0 proto kernel scope link src 10.10.41.194 qui est ton VPN,
et tu as deux routes qui couvrent l'ensemble des adresses qui sont 0.0.0.0/1 via 10.10.41.193 dev tun0 et 128.0.0.0/1 via 10.10.41.193 dev tun0
comme ces deux plages couvrent toues les adresses, la passerelle par defaut n'est pas utilisée, c'est astucieux car ça évite de la sauvegarder et il est facile de remettre la machine en l'état une fois le VPN supprimé.

Peut être que le VPN essaye de mettre une passerelle par défaut et se rabat sur cette solution (bizarre tout de même), il faudrait voir la configuration.