VPN Njalla récalcitrant

[Grincheux41]

Hello tout le monde,

 

bon je vous préviens, je ne suis pas expert réseau donc je vais surement dire des bêtises mais ce n'est pas grave.

 

Je suis client ipredator et ils ont migré sur Njalla.

J'ai donc supprimé ma connexion VPN et j'en ai créé une nouvelle via l'assistant.

C'est une configuration de type OpenVPN, j'ai importé le fichier .ovpn et... la connexion semble OK : elle affiche "connecté". Et sur l'interface de Njalla, donc côté serveur, cela affiche "client connected".

Sauf que... au bout de quelques instants, côté serveur, j'apparais comme "Offline"... mais par contre, dans le syno, j'apparais toujours en "connecté"!

A priori le problème ne vient pas du fichier opvn, je l'ai importé dans un client sous windows, et le VPN s'est bien monté. J'ai fait un tracert pour vérifier que le flux passe bien par le VPN et c'est le cas!

Revenons donc sur le Syno.

je vide le contenu de iptables pour être sûr de ne pas avoir de souci.

iptables -F
iptables -t nat -F

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Serveur DNS primaire : l'IP locale de ma box

ping www.google.fr : ça marche !

Mais je rappelle que sur l'IHM côté serveur, j'apparais en offline.

 

Autre test : serveur DNS primaire : cloudflare 1.1.1.1 (et DNS secondaire aussi).

ping www.google.fr : ping: www.google.fr: Temporary failure in name resolution

 

Donc le seul serveur DNS qu'il arrive à atteindre est en local.

Si je ping l'adresse IP de google, alors j'ai : 

root@NAS:/volume2/divers# ping 172.217.22.131
PING 172.217.22.131 (172.217.22.131) 56(84) bytes of data.
^C
--- 172.217.22.131 ping statistics ---
127 packets transmitted, 0 received, 100% packet loss, time 126023ms

 

iptables est vide donc ça ne peut pas venir de là, right?

 

donc ma création de VPN est mal faite... ou alors ça vient de Njalla? je ne comprends pas, cela fait 3 jours que je suis dessus, je n'en peux plus!

 

Quelqu'un pourrait-il m'aider?

 

[Grincheux41]

Bon j'avance tout doucement.

 

J'ai mis "log openvpn.log" dans mon fichier de conf client_oXXXXXX (dans : /usr/syno/etc/synovpnclient/openvpn)

J'avais un WARNING sur des droits de fichier de clé. Bon un chmod 700 sur le fichier en question a réglé le souci du WARNING.

 

Ensuite j'avais : 

SIOCADDRT: File exists
Mon Nov  9 10:03:25 2020 ERROR: Linux route add command failed: external program exited with error status: 7

grâce à https://www.cyberciti.biz/faq/siocaddrt-file-exists-ubuntu-linux-error-solution/

J'ai coupé mon VPN, j'ai vérifié mes route avec un : ip route list

puis j'ai supprimé 2 lignes qui correspondaient à mon VPN ( sudo ip route delete XXX.XXX.XXX.XXX dev eth0)

 

et maintenant : plus d'erreur dans la log 🙂 à part

 

Mon Nov  9 10:32:35 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
tail: openvpn.log: file truncated
Mon Nov  9 10:39:51 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon Nov  9 10:39:55 2020 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:7 is ignored by previous <connection> blocks

 

Désormais, côté server VPN, je reste bien connecté! il semble donc que le tuyau est ouvert et reste bien ouvert ! 🙂 

Mais je ne peux toujours rien pinguer, ni URL, ni IP... ha si, j'arrive à pinguer l'IP du serveur VPN, c'est déjà bien ... (mais je n'avais pas testé avant de faire cette manip).

Donc le tuyau est ouvert, mais il n'y a rien qui passe dedans ... pour l'instant 🙂

 

[Grincheux41]

bon je pense sincèrement que mon problème vient donc des routes. Le FW n'est pas en cause, le DNS non plus, et la config VPN non plus... enfin je pense!

 

root@NAS:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         198.167.208.1   128.0.0.0       UG    0      0        0 tun0
0.0.0.0         198.167.208.1   0.0.0.0         UG    0      0        0 tun0
128.0.0.0       198.167.208.1   128.0.0.0       UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
198.167.192.31  192.168.0.254   255.255.255.255 UGH   0      0        0 eth0
198.167.208.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0

Bon j'essaie maintenant de comprendre tout ça... et les 2 dernières lignes me posent question...

bon la suite plus tard, j'suis fatigué, merci de votre attention 😂

[.Shad.]

Pour ma part depuis quelques temps, le DNS Cloudflare 1.1.1.1 n'est plus accessible.
Est-ce que tu as essayé avec 1.0.0.1 ?

[Grincheux41]

il y a une heure, .Shad. a dit :

Pour ma part depuis quelques temps, le DNS Cloudflare 1.1.1.1 n'est plus accessible.
Est-ce que tu as essayé avec 1.0.0.1 ?

je l'avais déjà mis en secondaire donc en théorie, si timeout, il doit switcher tout seul, non?

 

Mais de toutes façons ce n'est pas ça... et il semble que j'ai passé beaucoup de temps pour rien sur ce sujet! (quoique... cela m'a fait réviser plein de choses!).

J'ai contacté le support Njalla ce week end. Hier soir ils m'ont demandé de rechargé la config. Comme je suis têtu, j'ai dit que ce n'était pas utile car le fichier de config n'avait pas changé... ils ont insisté et m'ont certifié avoir fait des modifs donc j'ai fait ce qu'ils m'ont dit... et it works !!!!!!!!!!!!!! du 1er coup, sans rien faire de spécial!

[.Shad.]

Ah ben bonne nouvelle 🙂

Quant au switch, oui "en théorie", il m'est arrivé qu'un périphérique veuille absolument passer par le DNS primaire, sans tenir compte du secondaire. 😉 

[Grincheux41]

merci d'avoir tenté de m'aider, je me sentais seul 😂😂😂

[.Shad.]

Haha, en même temps t'avais l'air de toucher ta bille un minimum, pas sûr qu'on aurait pu beaucoup t'aider. 😉