Ubuntu 7.04 Erreur de VPN sans raison ? - Page 1

Voilà, le problème concerne la gestion du VPN Windows sous Ubuntu 7.04. La connexion doit se faire à un serveur Windows, dont le login est (suivant si on veut ou non accès aux imprimantes internes au réseau, notamment) "sim\p07xxxxx", ou "p07xxxxx".

Lorsque je veux me connecter, ça indique "Impossible de se connecter en raison d'un échec de login, Bad username or password". Vu le temps que ça met (environ une demi-seconde), je doute très fortement que Ubuntu ait même cherché à joindre le serveur.

J'ai déjà regardé les logs, et absolument rien de clair n'est dit.

1- Comment savoir ce qu'a tenté de faire le système ?
2- Comment peut-on le forcer à contacter le serveur ?
3- Comment savoir ce que le serveur a répondu exactement ?
4- Comment savoir ce que le serveur attend exactement ? (liée à la précédente)
5- Sous Windows la configuration d'un VPN se fait en 3 à 4 clics, et ne pose pas de question techniques auxquelles on ne peut pas répondre. Quels sont les critères par défaut d'une telle connexion, qu'on puisse s'en servir sous Linux?

T'as vérifié que le client est configuré avec les même protocoles de communication que le serveur, à savoir ici PPTP (protocole VPN de Microsoft) et non en L2TP par exemple?

C'est quoi ton client VPN sous Feisty?

Vérifie aussi les critères communs d'authentification (PAP/CHAP...) et de chiffrement des données (AES, EAS...) mais c'est vrai que sous Dows on ne te demande pas tout ça côté serveur alors que sous Nux si (c'est la puissance de Nux).

Voui, c mis en PPTP, le seul protocole dont j'aie installé la prise en charge, d'ailleurs.

Le client VPN, c'est pptp-linux.

Les critères d'authentification sont peut-être le problème, je n'ai touché à rien de ce côté en espérant que la configuration par défaut serait la même que sous Windows.

Je veux bien demander ces paramètres encore une fois à la DGTIC, mais comme ils ne supportent pas Linux, ils ne sont pas censés le savoir, et effectivement, la dernière fois on m'a répondu "J'en sais rien, c'est pas nécessaire de renseigner ce paramètre sous Windows."

Moi j'ai résolu hier mes problème de VPN sous Feisty avec les dépôts pptp-linux et pptp car pptpconfig marche plus depuis Edgy.

Moi comme paramètres sous ce client, j'ai désactivé le cryptage de l'authentification EAP mais à part ça j'ai laissé par défaut.

Question conne mais qui est le piège du débutant : tu fais ton vpn en local ou via Internet? Car dans ce dernier cas il est indispensable de faire un port forwarding vers ta machine qui a le serveur vpn depuis l'extérieur (au niveau de tes règles firewall de ton routeur si t'en as un), sinon elle sera inatteignable depuis Internet.

J'espère que c'était ton problème.

Le pptp ne fonctionnait pas non plus sous Edgy, mais je ne me souviens plus ce que j'utilisais.

Où est l'option de cryptage de l'authentification EAP ? Car dans l'onglet "Authentication" (non, il a pas été traduit, lui.) se trouvent "Refuse EAP", et dans l'onglet "Compression & Encryption" se trouve, sous "Encryption", "Require MPPE encryption", et "Require 128 bit MPPE encryption". Toutes ces options sont décochées, donc désactivées.

VPN via Internet: je cherche à atteindre une machine distante sur laquelle je n'ai aucun contrôle, et qui justement est prévue pour accepter les connexions venant de l'extérieur. L'autre PC est un Windows 2000, avec une adresse 192.168.1.100, et le Linux est au même niveau (un réseau filaire tout simple), avec 192.168.1.103. Le routeur 192.168.1.1 est connecté dans la DMZ 192.168.15.100 d'un autre routeur téléphonique, lui relié au modem. Jamais cette configuration ne m'a posé de problème, et à preuve, tous les P2P fonctionnent (habituellement très tâtillons sur les ports), et, de Windows 2000, le VPN se connecte sans pb, et je peux accéder aux imprimantes payantes dans le VPN.

Donc, si le réseau est en faute, ce n'est au moins pas dans le routeur.

Oki je vois, alors voici les trucs touts bêtes à vérifier :
- ne tente pas de te connecter au vpn via ta carte Wifi (par défaut pptp-linux utilise ton interface eth0), sinon ça marche pas et y a une bidouille à faire pour y arriver
- laisse les paramètres par défaut MAIS coche le refus de l'authentification EAP (même si là je ne peux tester si c'est indispensable ou pas)
- le routeur derrière lequel est le serveur vpn doit OBLIGATOIREMENT comporter des règles firewall, créant un port forwarding des requêtes entrantes à destination du port 1723 (PPTP) vers ce même port de la machine serveur - POUR UNE CONNEXION VPN VIA INTERNET - sinon le serveur sera INJOIGNIABLE (normal car sinon le routeur est incapable de savoir à quelle machine s'adresse la requête PPTP, le NAT dynamique adressant à toutes les machines locales la même ip publique)

Ensuite relance le tout peut-être avec un "sudo killall NetworkManager" et un "sudo NetworkManager &".

- Alors en cochant cette option "Refuse EAP", toujours le même message d'erreur. Même chose en tuant puis relançant le NetworkManager.
- Je n'ai aucun contrôle sur le routeur juste avant le serveur de destination, mais j'imagine qu'il est correctement configuré, vu que ça marche sous Windows. D'ailleurs c'est sûrement bien plus complexe qu'un seul routeur, vu la taille du réseau distant. Parlons plutôt de routeur "virtuel".
- Là je fais les tests en filaire, mais ultimement, le VPN devrait être utilisé surtout en WiFi, quelle manip faut faire pour que ça marche ? (Évidemment ce genre de trucs super utile n'est JAMAIS indiqué dans la documentation...RTFM...wait...What M ??)

Bon le truc délirant... maintenant je n'arrive plus à me connecter en filaire au vpn..... seule une connexion sur au moins 50 essais m'a été fructueuse... alors qu'en wifi j'y arrive à chaque fois...

En précision, j'ai juste changé d'endroit géographique et suis dans le même réseau maintenant que le serveur vpn à atteindre mais bon ça change rien.

Par contre, un détail important : si tu veux te connecter au vpn en wifi, il te faut mettre la connexion obligatoirement en roaming mode, sinon il ne se passera rien.

EDIT : Moi aussi j'ai eu ton problème de bad username and password, effectivement il ne contacte pas le serveur dans ce cas, ça se voit mais c'est parce sous Feisty la connexion wifi est pas toujours instantanée. J'ai donc ce message quand je ne suis pas connecté (le dhclient résoud le problème), mais en filaire c'est bizarre.

Donc alterne les possibilités de connexion (eth0/eth1, dhcp/roaming mode...), tu devrais finir par réussir, j'en suis sûr, ce client vpn est capricieux au moment de la connexion mais il marche.

Connexions filaires et Wifi sont en roaming mode ("Itinérant"), puisque ce portable peut être utilisé en filaire et wifi pratiquerment n'importe où, entre mon bureau officiel à l'Hôpital, chez moi, ou en filaire à la fac. Pour le Wifi c'est encore plus évident, d'un point d'accès à l'autre..

En attendant Feisty est le seul qui m'ait permis d'utiliser le wifi ss passer par la ligne de commande. Edgy, ça ne marchait jamais, et c'est un des principales raisons qui me feront pas revenir en arrière.

En activant direct DHCP sur le filaire, pas plus de succès en VPN; il ne contacte pas le serveur. Y'a quoi d'autre d'alternable?

Le shell n'est pas du tout indispensable sous Edgy pour le wifi.

En filaire j'arrivais à me connecter au vpn de chez mon père, là je ne peux plus qu'en wifi en mode itinérant, va savoir...

Si tu te connectes en itinérant en wifi mais qu'avant tu fais un "dhclient" dans le terminal en root et qu'après tu essaies de te connecter au vpn, il te dit la même chose?

Vois s'il essaie au moins de s'y connecter en affichant un cadenas sur le logo wifi en haut à droite, tu devrais y voir une animation (une sorte de courant électrique doré) quand il essaie vraiment de se connecter.

Question conne bis : avec le dépôt "pptp-linux" tu as bien téléchargé celui nommé "pptp" également?

Pour être sûr d'avoir les 2 bons dépôts et leur dernière version tape en root un "apt-get install network-manager-gnome network-manager-pptp", même si je pense que de ce côté-là t'as déjà tout.

Pas moyen de tester le Wifi ici, par contre tout indice sur le filaire est bienvenu.

Après un "sudo dhclient" sur la connexion filaire, il essaie vraiment de se connecter cette fois, mais toujours la même erreur.

Pour les paquets, en plus de "pptp-linux", vient avec "network-manger-pptp", mais il n'y a pas de paquet nommé "pptp" à proprement parler. LE plus proche est "pptpd", qui est un daemon, donc inutile pour moi, vu que je ne suis pas le serveur VPN.

Comme tu viens de le dire, apt-get machin m'indique que tous les bons paquets sont là...J'en ait profité pour enlever ceux qu'il indiquaient ne plus être nécessaires (un truc qui manque à Synaptic, tiens...)

Oui tu sembles tout avoir effectivement.

Sinon oui pptpd est une partie serveur (d'ailleurs je me pencherai dessus tiens).

C'est bizarre que tu obtiennes encore cette erreur alors que le délai de réponse est pour toi plus long qu'avant.

Moi en filaire ça foire maintenant à chaque fois mais je n'ai pas ce message mais un truc à base de "vpn connection failure".

J'aurais bien 2-3 idées mais si tu me dis que ton client vpn Windows n'a aucun paramètres spéciaux que tu aurais entrés... là je vois pas... logiquement si le serveur semble avoir répondu, cela ne peut être qu'un problème d'authentification (t'es bien sûr du login et pass?) ou alors la partie serveur n'a aucun cryptage des données d'activé et le client Ubuntu si (par défaut le chiffrement MPPE est exigé lors de la négociation client/serveur au niveau du client Ubuntu).
Essaie alors de décocher toute contrainte de sécurité exigée par le client.

Bah le client VPN Windows est la bête fonction qui est intégrée...Si y'a un moyen de savoir chaque paramètre, je le connais pas.

J'ai coché les option "Allow" pour la compression, et décoché toutes les options qui seraient contraignantes (les "require"), toujours impossible de se connecter.

Depuis le temps que je me sers de ce serveur sous Windows, je les connais, les login/pass...

Hmm... et si en plus tu me dis que la partie serveur est configurée par défaut... on est mal barré... là comme ça je vois pas...

Moi j'ai résolu mes problèmes comme je t'ai dit mais jamais je n'ai eu de rejet de login/pass... sauf une fois mais je n'étais en fait pas connecté.

Sinon, ne serait-il pas possible que de leur côté, ils aient changé le login/pass du serveur vpn (question con mais bon...)?

Je ne sais pas comment est configuré le serveur VPN. Il marche sous Windows et avec un Windows distant, c'est tout ce que je sais. Login et mot de passe ont été contrôlés avec le logiciel prévu à cet effet par le service informatique, et ils sont valides et actifs.

Pour la forme, j'ai refait la connexion sous Windows. Évidemment, c'est aujourd'hui qu'il a décidé de me faire chier, ça m'a pris 5 essais, mais ça a fini par connecter. D'un autre côté, ce Windows est un peu "cassé" aussi...

Donc, un petit passage sous VMware contenant une copie fraîche de Win 2000 convenablement configurée, ça marche du premier coup. Bilan, l'autre Windows est trop cassé pour s'en sortir. CE QUI NE RÉSOUT TJS PAS LE PB DE LINUX !!

Petit avantage de Win, c possible de lire sommairement à quel étape il est rendu ds la connexion.

En touchant à paramètres avancés (normalement je laisse ça à "automatique", mais pour la cause...), je vois que c'est sélectionné "Exiger le cryptage de données, déconnecter si aucun.", et "Exiger un mot de passe sécurisé". Dans les options spécifiant les protocoles autorisés, seuls MS-CHAP et MS-CHAP v2 sont autorisés.

Sous Linux, j'ai donc coché "Refuse EAP" et "Refuse CHAP" (Les 2 autres sont décochées), puis "Require MPPE encryption". Ça tente de connecter, mais ça finit avec le même message d'erreur que toi, cette fois: "VPN connection failed".

Euh, pourquoi tu refuses le CHAP ? CHAP et MS CHAP sont incompatibles ?

Le but n'est pas de refuser quoique ce soit mais de laisser le serveur décider, étant donné que tu ne connais pas les paramètres de son côté.

Donc, côté client, décoche toutes les options de type "refuse"et "require" qui mettraient en péril la négociation client/serveur au moment de l'authentification, même "refuse EAS", car si ça se trouve le serveur que t'essaies de joindre l'exige, même si j'y crois pas une seconde mais bon....

Refusés au cas où il tenterait de les utiliser, puisque ces protocoles ne sont apparamment pas utilisés par Windows (le client VMWare, pour rappel)

Bon, après avoir tout re-décoché, des nèfles. Même message d'erreur.