Archive for the ‘Informations utilisateurs’ Category

« Older Entries
Newer Entries »

Problème de navigation une fois le VPN activé suite à upgrade en debian 10.10 et ubuntu 20.04/21.04

mercredi, septembre 15th, 2021

Il est possible que la connexion au VPN (vpn20-1, vpn2-2 ou vpn20-3) via la WIFI ne fonctionne pas correctement.

Il se trouve que sur ces OS récents, il n’est plus possible de faire le réglage de la MTU via les paramètres graphique de la connexion WIFI.

Un ip address va vous informer sur l’état de votre conenxion.

Exemple :

dsin@dsin-NL40-50GU:~$ ip address
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlp0s12f0: mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:41:8c:68:37:56 brd ff:ff:ff:ff:ff:ff
inet 172.21.205.141/20 brd 172.21.207.255 scope global dynamic noprefixroute wlp0s12f0
valid_lft 4992sec preferred_lft 4992sec
inet 10.248.3.19/32 scope global wlp0s12f0
valid_lft forever preferred_lft forever
inet6 fe80::3c5:7d40:52b7:1452/64 scope link noprefixroute
valid_lft forever preferred_lft forever

ce qu’il faut voir ici est la ligne :

2: wlp0s12f0: mtu 1500 qdisc noqueue state UP group default qlen 1000

Qui indique un MTU à 1500 octets.

Ainsi la connexion VPN basé sur le WIFI n’est pas fonctionnelle.

Il faut ré-appliquer “à la main” la procédure suivante (merci à Sébastien Picard d’avior été vigilent sur ce point) dans le fichier /etc/NetworkManager/dispatcher.d/01-ifupdown :

if [ "$2" = "vpn-up" ] || [ "$2" = "vpn-down" ]; then
ADDRESS_FAMILIES=""
ip link set dev "$1" mtu 1300
fi

Une fois cela fait vous pouvez arrêter le VPN, relancer la connexion WIFI et relancer la connexion VPN.

Tags:, , , , ,
Posted in informations techniques, Informations utilisateurs | No Comments »

Statistiques des connexions VPN 01/01/2019 – 01/04/2021

mercredi, avril 28th, 2021

La courbe entre janvier 2019 et février 2021 est l’activité normale pré-covid19. Il n’y avait alors qu’un seul serveur VPN actif (vpn14). Dès mars 2021, le serveur vpn20-1 et surtout vpn20-2 ont été ajoutés pour permettre d’absorber les nombreuses connexions induites par le “travail à la maison”. En décembre 2020, le serveur vpn20-2 a migré de l’infrastructure de virtualisation sur une machine dédiée. Cela a permis de passer un nouveau cap de connexions simultanées.

Graphe des connexions VPN durant les confinements successifs.

Tags:, , ,
Posted in Informations utilisateurs | No Comments »

IKEv2 & Windows 10 : message d’erreur “Paramètres incorrects”

vendredi, mars 26th, 2021

Si vous utilisez le script powershell pour créer la connexion VPN en IKEv2 sous Windows 10 (comme indiqué dans les instructions d’installation) et que, lorsque vous essayez de vous connecter, le message “parameter is incorrect” apparaît, procédez comme suit :

  • 1. Effacer les caches réseau

Exécutez la fenêtre cmd de Windows (cliquez sur le menu de démarrage de Windows, tapez ‘cmd’, faites un clic droit sur ‘Command Prompt’ et sélectionnez ‘Run as Administrator’).

Tapez la commande suivante :
netsh int ip reset

puis tapez :
netsh int ipv6 reset

puis tapez :
netsh winsock reset

Redémarrez votre ordinateur.

  • 2. Réinitialiser les adaptateurs du Gestionnaire de périphériques

Ouvrez le Gestionnaire de périphériques
Trouvez les adaptateurs réseau
Désinstaller les pilotes WAN Miniport (IKEv2, IP, IPv6, etc.)
Cliquez sur Action > Analyser les changements de matériel
Les adaptateurs que vous venez de désinstaller devraient réapparaître.

La connexion VPN fonctionne alors.

Posted in Informations utilisateurs | No Comments »

Windows : ajouter un serveur DNS indépendant de ceux de l’UFC

lundi, mars 23rd, 2020

Si votre serveur DNS n’est pas associé à un sous-domaine universitaire sur le DNS de l’UFC, alors la connexion VPN en vous imposant les 194.57.91.200 et 201 va empêcher les connexions vers vos serveurs nommés sur votre serveur de nom (par exemple 172.20.7.250).

Pour corriger cela, vous devez avoir les droits d’utiliser Powershell sur votre poste Windows (droit administrateur).

La ligne suivante permet l’ajout de votre serveur de nom. Mais pour que celui-ci soit pris en compte il faut interrompre la connexion VPN, taper la ligne et relancer la connexion VPN.

Add-VpnConnectionTriggerDnsConfiguration -ConnectionName "VPN CTU" -DnsSuffix ".univ-fcomte.fr" -DnsIPAddress "172.20.7.250" -PassThru

Pour enlever cet ajout :

Remove-VpnConnectionTriggerDnsConfiguration -ConnectionName "VPN UFC - VPN20-2 - CTU" -DnsSuffix .univ-fcomte.fr

Et là aussi, il faut arrêter et relancer la connexion pour que cela soit pris en compte.

Tags:,
Posted in Informations utilisateurs | No Comments »

Linux : problème de connexion (chaîne de certification)

lundi, mars 23rd, 2020

Si votre système (ubuntu 18.xx par exmple) n’est pas bien à jour, il est possible que la chaîne de certification qu’il embarque ne soit plus valide. Cela est visible sur certains serveurs Web en https certifiés par Digicert, mais du coup aussi sur les serveur VPN vpn20-1 ou vpn20-2 qui utilise également ce type de certificat et de chaîne de certification.

Le log (merci Clément) :

Mar 23 07:51:31 SCI-DIEBOLD4 charon-nm: 09[IKE] no trusted RSA public key found for 'vpn20-2.univ-fcomte.fr'

Sur le serveur VPN nous avons cela :

Mon, 2020-03-23 07:51:31 10[ENC] parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Mon, 2020-03-23 07:51:31 10[ENC] generating INFORMATIONAL response 2 [ N(AUTH_FAILED) ]

Pour corriger le problème et réussir à établir la connexion, Clément nous à fourni la solution :

dpkg-reconfigure ca-certificates
(vous pouvez laisser tous les certificats coché, sinon celui qui est impératif est celui de Digicert)
update-ca-certificates

Tags:, ,
Posted in Informations utilisateurs | No Comments »

Windows : problème d’accès aux services une fois la connexion établie

mardi, mars 17th, 2020

Attention, ce post est un peu technique.

Sous Windows, lorsque vous établissez la connexion VPN, une connexion est établie entre votre matériel et le serveur VPN. Pour cela, il est créé sur votre matériel une nouvelle connexion réseau.

Malheureusement, malgré la connexion parfaitement établie, vous n’accéder pas au service voulu. En faisant un ping, vous arrivez à atteindre un certain nombre de services, mais globalement pas les services dont vous avez besoin (document partagé/apogee/harpege/cocktail/…).

Analyse

Vous pouvez la voir en ouvrant une console de commande (taper cmd dans la barre de texte en bas à gauche) et en tapant

netsh interface ip show config

Vous pouvez repérer la connexion de base (WIFI ou filaire) que vous avez utilisée pour vous connecter au VPN. Souvent une interface comme cela :

Configuration pour l'interface « Ethernet 3 »
DHCP activé : Non
Adresse IP : 192.168.1.6
Préfixe de sous-réseau : 192.168.1.0/24 (masque 255.255.255.0)
Passerelle par défaut : 192.168.1.254
Métrique de passerelle : 256
Métrique de l'interface : 25
Serveurs DNS configurés statiquement : 8.8.8.8
8.8.4.4
Enregistrer avec le suffixe : Aucun
Serveurs WINS configurés statiquement : Aucun

et la connexion VPN :

Configuration pour l'interface « Ethernet 8 »
DHCP activé: Oui
Adresse IP : 172.20.250.4
Préfixe de sous-réseau : 172.20.250.0/24 (masque 255.255.255.0)
Métrique de l'interface : 55
Serveurs DNS configurés via DHCP : Aucun
Enregistrer avec le suffixe : Principale uniquement
Serveurs WINS configurés via DHCP : Aucun

Ce qui nous intéresse ici, ce sont les deux valeurs de métrique
Configuration pour l’interface « Ethernet 3 »
Métrique de l’interface : 25
Configuration pour l’interface « Ethernet 8 »
Métrique de l’interface : 55

Pour que l’information transite bien par le VPN et pas par votre connexion de base, il faut que la valeur de la métrique de la connexion VPN ( « Ethernet 8 » ici) soit inférieure à celle de la connexion de base ( « Ethernet 3 » ).

Correction

Pour corriger cela, il suffit dans la fenêtre de commande de taper :

netsh int ip set interface interface=\"Ethernet 8\" metric=10

Ce qui va passer la métrique de la connexion VPN en deçà de celle de base et donc les connexions aux services que vous cherchez à atteindre passeront par le VPN.

Tags:, , , , ,
Posted in Informations utilisateurs | No Comments »

Opérateurs et IPv6

lundi, août 26th, 2019

Chez certains opérateurs, la connexion réseau s’établit en IPv6.
Cela n’impacte pas votre navigation, mais comme le serveur VPN est en IPv4 seulement, vous ne pourrez pas vous connecter.

Donc si vous utilisez votre téléphone pour connecter votre portable informatique (plus le partage de connexion WIFI ou USB).

Il faut donc aller dans les paramètres du téléphone pour valider IPv4 uniquement et refaire la procédure de connexion VPN.

Tags:, ,
Posted in informations techniques, Informations utilisateurs | No Comments »

Problèmes Windows

mardi, février 12th, 2019

Deux types de problème ces derniers jours.

PROBLEME : la connexion SHREW s’établit, mais il semble que rien ne soit possible ensuite.
SOLUTION trouvée : désinstallation de SHREW, réinstallation SHREW et ré-importation du certificat.

PROBLEME : la connexion ne veut pas s’établir et passe en erreur (timeout)
SOLUTION :
– avec Kaspersky, vérifier si SHREW fait bien parti des logiciels autorisé ?
– avec certain anti-virus, il faut désinstaller l’anti-virus, rebooter la machine lancer la connexion VPN.
Si cela fonctionne, réinstaller l’anti-virus.

Posted in Informations utilisateurs, problèmes utilisateurs | No Comments »

Windows 10 et route par défaut

mercredi, janvier 4th, 2017

Sous Windows 10 (suite à une mise à jour de l’OS) nous avons remarqué que le système conserve l’ancienne route par défaut lors de la mise en place de la connexion VPN via SHREW.

De fait votre système utilise la route par défaut classique (au lieu de la route qui mène au serveur VPN) pour la résolution de nom (entre autre).

Cela entraîne un dysfonctionnement lors de l’accès à des ressources privées de l’UFC.

Pour corriger cela, il faut :
– Cliquez sur démarrer > exécuter, tapez ”ncpa.cpl” et cliquez sur OK ;
– Faites un clic droit sur l’adaptateur réseau souhaité puis cliquez sur “Propriétés” ;
– Sélectionnez Propriétés Internet version 4 (TCP/IPv4) puis cliquez sur “Propriétés” ;
– Cliquez sur Avancé…
– Décochez “Métrique automatique” puis spécifiez ”100” sur la métrique de routage au niveau du champ “Métrique de l’interface”.

Votre VPN devrait maintenant être utilisé pour toutes les connexions réseau.

Tags:, , ,
Posted in Informations utilisateurs, problèmes utilisateurs | No Comments »

Pas de réseau

jeudi, janvier 14th, 2016

Après la mise en route du VPN et de votre authentification, vous vous rendez compte que vous n’avez pas de réseau.
Même un ping sur votre passerelle (172.20.252.254 si vous êtes dans le realm @ufc) ne passe pas.
Pourtant le système VPN vous a bien donné une ip (172.20.252.xxx si vous êtes dans le realm @ufc).

C’est un souci qui se produit parfois suite à plusieurs déconnexions et reconnexions de votre client VPN (SHREW, sous MACOSX ce problème ne s’est pas posé en ces termes).
Ces déconnexions/connexions peuvent être volontaire ou non c’est-à-dire qu’il est possible qu’elles passent inaperçues.

Pour résoudre le souci, il faut :
– se déconnecter du VPN
– fermer la fenêtre de connexion VPN (SHREW)
– stopper le démon iked et ipsecd
* sous linux faire sudo iked
* sous window dans une fenêtre cmd
net stop ipsecd
net stop iked
net start iked
net start ipsecd

puis refaire les opérations de connexion :
– relancer le démon iked
– relancer la fenêtre de connexion VPN (SHREW)
– se connecter au VPN

Sinon vous avez aussi la possibilité de relancer votre poste de travail.

Tags:, , , , , , ,
Posted in Informations utilisateurs, problèmes utilisateurs | No Comments »

« Older Entries
Newer Entries »