Posts Tagged ‘client’

« Older Entries

solution pour “la déconnexion fatale” des clients Windows

vendredi, novembre 26th, 2010

L’équipe travail à l’intégration d’un nouveau client pour les Windows (XP/Vista/Seven/2000/2003/2008) qui tient en compte ce que le client natif de Windows ne fait pas : prendre en charge le DPD (dead peer detection).
Le client (shrew http://www.shrew.net/) gère DPD et donc permet en cas de déconnexion du client au serveur de reprendre en moins d’une minute la connexion perdue.

Nous sommes en phases de test du client sur les diverses plateformes.

Techniquement la connexion s’effectue en deux partie.
– le lancement du client IPSEC (shrew)
– le lancement d’une connexion PPTP pour l’authentification sur le realm souhaité. Cette partie est géré par Windows.

La solution est en phase de test
La documentation provisoire est installation_shrew-20101215

Tags:, , ,
Posted in Informations utilisateurs | 1 Comment »

Gestion des proxies sous Firefox

vendredi, mai 23rd, 2008

Lorsque vous êtes connecté à un réseau à travers l’un des serveurs VPN universitaires, vous allez certainement vous retrouver dans un réseau de classe privée. Vos accès Internet devront donc impérativement passer par les serveurs mandataires (Proxy) de l’UFC. Sous IE, il est possible de gérer un serveur proxy par connexion du fait de l’intégration avancée du navigateur avec le système. Pour plus d’informations, consultez l’article Problème Windows : IE7 et proxy.

Sous Firefox, la bascule entre les accès directs à Internet et l’utilisation obligatoire d’un proxy peut devenir irritante. L’installation du plugin FoxyProxy peut vous rendre bien des services.

Ce plugin vous permettra de sélectionner très facilement l’utilisation de tel ou tel serveur proxy ou bien sûr l’accès direct sans aucun mandataire.

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

Problème Windows : IE7 et proxy

jeudi, avril 10th, 2008

Internet Explorer 7 permet de définir les proxies en fonction de chaque connexion. Il est donc impératif si vous voulez travailler avec IE7 sous une connexion VPN de définir le proxy.pac de l’UFC dans les propriétés de la connexion VPN.
La documentation sur le VPN (document PDF) indique la marche à suivre.

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

Client Linux et Serveur : options dans sysctl.conf

jeudi, avril 10th, 2008

Pour le bon fonctionnement du proxy-arp du serveur VPN,

le fichier /etc/sysctl.conf du serveur VPN doit être configuré comme suit en ajoutant ces options :
net.ipv4.ip_forward=1
net.ipv4.icmp_ignore_bogus_error_responses=1
net.ipv4.conf.all.log_martians=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2


Sans ces options, le proxy-arp du serveur VPN ne fonctionne pas correctement et empêche le client d’accéder à quoi que ce soit hors le serveur VPN lui même.

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

Problème linux : log de connexion

mercredi, avril 9th, 2008

Les logs liés à une connexion VPN se trouvent dans /var/log/auth.log, /var/log/syslog et /var/log/messages.
Au lancement de la connexion IPsec (on voit ici que la connexion est à travers du nat) vous devez avoir des logs similaires à ceux-ci dans /var/log/auth.log (ou /var/log/messages):
#49: initiating Main Mode
#49: ignoring unknown Vendor ID payload [4f456c4c4f5d5264574e5244]
#49: received Vendor ID payload [Dead Peer Detection]
#49: received Vendor ID payload [RFC 3947] method set to=110
#49: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
#49: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
#49: STATE_MAIN_I2: sent MI2, expecting MR2
#49: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
#49: I am sending my cert
#49: I am sending a certificate request
#49: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
#49: STATE_MAIN_I3: sent MI3, expecting MR3
#49: Main mode peer ID is ID_IPV4_ADDR: '194.57.91.251'
#49: no crl from issuer "C=FR, ST=Franche-Comte, L=Besancon, O=UFC, OU=CRI, CN=CA-vpn, E=vpn-master@univ-fcomte.fr" found (strict=no)
#49: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
#49: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
#50: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+UP {using isakmp#49}
#50: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
#50: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x2e19c272 <0x37ba5dd5 xfrm=AES_0-HMAC_SHA1 NATD=194.57.91.251:4500 DPD=none}

Si vous n’avez pas de log de connexion IPsec, il faut vérifier votre fichier ipsec.conf, car il doit contenir des erreurs de syntaxe.

lors de la connexion (x)l2tp vous devriez avoir dans /var/log/syslog :
: pppd 2.4.4 started by root, uid 0
: Using interface ppp0
: Connect: ppp0 <--> /dev/pts/2
: Remote message: user2@lifc-edu connecte a lifc-edu^J
: PAP authentication succeeded
: replacing old default route to eth0 [192.168.1.254]
: local IP address 172.20.128.37
: remote IP address 192.168.255.201
: primary DNS address 194.57.91.200
: secondary DNS address 194.57.91.200

votre nouvelle adresse IP est précisée ici : : local IP address 172.20.128.37

Si vous n’avez pas de log (x)l2tp, vous pouvez lancer l2tpd en mode debug avec la commande suivante, en utilisateur root :
/etc/init.d/xl2tpd stop ou /etc/init.d/l2tpd stop
xl2tpd -D -c /etc/xl2tpd/xl2tpd.conf ou l2tpd -D -c /etc/l2tpd/l2tpd.conf
Ensuite effetcuez dans une autre fenêtre root le montage du lien PPP
echo "c user2" > /var/run/xl2tpd/l2tp-control ou echo "c user2" > /var/run/l2tp-control
Le résultat des logs dans la première fenêtre doit vous apporter de l’aide pour corriger votre problème.
Si cela persiste n’hésitez pas à contacter votre correspondant réseau ou vpn-master@univ-fcomte.fr

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

Problème linux : je perds ma route par défaut en déconnectant le VPN

mercredi, avril 9th, 2008

Lorsque vous effectuez la connexion VPN, les routes sur votre ordinateur ressemblent à cela :
cri-29:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.255.201 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
194.57.91.251 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

Lors de la déconnexion, il ne vous reste que :
cri-29:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.255.201 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
194.57.91.251 192.168.1.254 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

La route par défaut a disparu et vous ne pouvez plus aller sur Internet.
Pour résoudre ce problème, vous pouvez taper manuellement (sous l’utilisateur root) :
route add default gw 192.168.1.254
ou utiliser les scripts suivants :
/etc/ppp/ip-pre-up
#!/bin/sh
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
export PATH
PPP_IFACE="$1"
PPP_TTY="$2"
PPP_SPEED="$3"
PPP_LOCAL="$4"
PPP_REMOTE="$5"
PPP_IPPARAM="$6"
export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM
PPP_TTYNAME=`/usr/bin/basename "$2"`
export PPP_TTYNAME
run-parts /etc/ppp/ip-pre-up.d \
--arg="$1" --arg="$2" --arg="$3" --arg="$4" --arg="$5" --arg="$6"
EOF

etc/ppp/ip-pre-up.d/save-defaultroute
#! /bin/bash
GW=$(route -n | grep '^0.0.0.0' | tr -s ' ' ' ' | cut -d' ' -f2)
[ -n "$GW" ] && echo $GW > /tmp/$PPP_IFACE.defaultroute
exit 0;

et etc/ppp/ip-down.d/restore-defaultroute
#! /bin/sh -e
[ -f /tmp/$PPP_IFACE.defaultroute ] || exit 0
GW=$(cat /tmp/$PPP_IFACE.defaultroute)
route add default gw $GW
exit 0;

Si vous utilisez xl2tpd, un autre problème se pose pour vous. xl2tpd ne fait pas appel aux scripts de déconnexion de la session PPP. Il faut donc patcher xl2tpd en utilisant le repository du LIFC par exemple.

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

Configuration Linux avec ou sans NAT

mercredi, avril 9th, 2008

Le fichier /etc/ipsec.conf permet de déterminer si on utilise le NAT ou non.

Que l’on soit naté (chez soit avec sa ligne ADSL par exemple) ou non, vous pouvez utiliser dans la rubrique config setup
nat_traversal=yes

Très important dans la rubrique conn ufc-vpn
leftnexthop=192.168.1.254

Attention à mettre l’adresse de son routeur à la place du 192.168.1.254

Le client ipsec.conf configuré ici avec le serveur VPN 194.57.91.251
version 2
config setup
uniqueids=yes
nhelpers=0
nat_traversal=yes

conn vpn-ufc
authby=rsasig
keyingtries=1
rightprotoport=17/1701
leftprotoport=17/1701
keyexchange=ike
pfs=no
auto=add
left=%defaultroute
leftnexthop=192.168.1.254
leftcert="/etc/ipsec.d/certs/vpn-cri-29-cert.ufc.pem"
leftrsasigkey=%cert
leftsendcert=always
right=194.57.91.251
rightrsasigkey=%cert
rightca=%same

le fichier /etc/ipsec.secrets :
: RSA /etc/ipsec.d/private/vpn-cri-29-cert.key "testvpncri29"

le fichier xl2tpd.conf ou l2tpd.conf :
[global]
port = 1701

[lac user2]
lns = 194.57.91.251
redial = yes
redial timeout = 5
max redials = 3
length bit = yes
require authentication = no
refuse chap = yes
require pap = yes
name = user2
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client

le fichier /etc/ppp/options.l2tpd.client :

defaultroute
replacedefaultroute
debug
lock
user user2@lifc-edu
noipdefault
usepeerdns
noauth
lcp-echo-interval 20
lcp-echo-failure 10
noaccomp

le fichier /etc/ppp/pap-secrets :
user2@lifc-edu * ''user2''
ou

Cela peut être évité en utilisant l’astuce décrite dans cet article

Le montage du lien s’effectue en deux temps. IPSEC puis XL2TP
ipsec auto --up ufc-vpn
echo ''c user2'' > /var/run/xl2tpd/l2tp-control

L’arrêt du lien s’effectue par :
echo ''d user2'' > /var/run/xl2tpd/l2tp-control
ipsec auto --down ufc-vpn

Si vous utilisez L2TP les fichiers de configuration auront les mêmes contenu, mais le lancement s’effectue par :
ipsec auto --up ufc-vpn
echo ''c user2'' > /var/run/l2tp-control

L’arrêt du lien s’effectue par :
echo ''d user2'' > /var/run/l2tp-control
ipsec auto --down ufc-vpn

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

Installer xl2tpd sous debian etch

mercredi, avril 9th, 2008

mettre le repository du LIFC dans le fichier /etc/apt/sources.list :
# deb LIFC
deb http://lifc.univ-fcomte.fr/debian/ etch-lifc main

Ensuite effectuer :
apt-get update
apt-remove xl2tpd
apt-get install xl2tpd

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

Authentification PPP

mercredi, avril 9th, 2008

L’authentification entre le serveur PPP et le client PPP via (X)L2TP n’est pas nécessaire. Dans le fichier /etc/l2tpd/l2tpd.conf ou /etc/xl2tpd/xl2tpd.conf l’option doit être configurée comme suit :
refuse authentication = yes
ou par :
require authentication = no
Le serveur VPN est configuré ainsi.

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

Utilité des options rightprotoport/leftprotoport

mercredi, avril 9th, 2008

Une cohérence doit exister entre la configuration du serveur VPN et celle du client : si le fichier de configuration d’IPsec du serveur VPN comporte la ligne protoport, le fichier de configuration du client doit également la comporter.

Dans le fichier ipsec.conf, au niveau du paramètrage des connexions (conn <blabla>), nous devons trouver les options :
rightprotoport=17/1701
leftprotoport=17/1701

sinon le lancement de la connexion :
ipsec auto --up blabla
ne fonctionnera pas.

A l’inverse, si cette option protoport n’est pas présente dans le fichier de configuration du serveur, elle devient inutile dans le fichier de configuration du client VPN.

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

« Older Entries