Archive for the ‘informations techniques’ Category

« Older Entries
Newer Entries »

windows + WIFI SSID ufc-vpn + problème MTU

mardi, novembre 25th, 2014

Sous windows 7 en étant sur le Wifi (ssid ufc-vpn), il est possible d’avoir un souci de MTU.
C’est Gérard Asensio qui nous remonte un problème d’accès à un serveur de jeton et sa solution :

netsh interface ipv4>show interface

Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
14 30 1500 connected Connexion réseau sans fil
17 5 1500 disconnected Connexion réseau sans fil 2 <-- SSID ufc-vpn 13 5 1500 disconnected Connexion au réseau local 19 30 1300 connected Connexion au réseau local* 4 <---- connexion vpn

Pour que le jeton de licence passe, il faut un mtu de 1300 sur les interfaces physiques utilisables par le VPN ( wifi ou filaire ) :

netsh interface ipv4>set subinterface "Connexion réseau sans fil" mtu=1300 store=persistent
Ok.

netsh interface ipv4>set subinterface "Connexion au réseau local" mtu=1300 store=persistent
Ok.

netsh interface ipv4>show interface

Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
14 30 1300 connected Connexion réseau sans fil
17 5 1500 disconnected Connexion réseau sans fil 2 <-- SSID ufc-vpn 13 5 1300 disconnected Connexion au réseau local 19 30 1380 connected Connexion au réseau local* 4 <---- connexion vpn

Remettre un interface en mtu 1500 :

netsh interface ipv4>set subinterface "Connexion réseau sans fil 2" mtu=1500 store=persistent
Ok.

netsh interface ipv4>set subinterface "Connexion au réseau local* 4" mtu=1500 store=persistent
Ok.

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

Problème VISTA : la connexion ne fonctionne pas, pas de message d’erreur

mardi, octobre 20th, 2009

Sous VISTA si le petit patch de la base de registre est mal appliqué (ou la machine n’est pas rebooté), il est possible que la connexion VPN échoue sans aucun message d’erreur.

Néanmoins dans les logs du serveur VPN nous aurons :

STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
STATE_QUICK_R2: IPsec SA established {ESP=>0xd3e37be6 <0xb8baa9ac xfrm=AES_128-HMAC_SHA1 NATD=172.20.10.58:4500 DPD=none} received Delete SA(0x7e993ed9) payload: deleting IPSEC State #61676 received and ignored informational message

Un log de connexion réussi :

STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
STATE_QUICK_R2: IPsec SA established {ESP=>0x1a850fb1 <0x72559a9e xfrm=AES_128-HMAC_SHA1 NATD=172.21.7.183:4500 DPD=none}

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

GNU Linux Magazine France

mardi, mai 19th, 2009

Le premier d’une série de quatre articles consacrés à la mise en oeuvre de notre solution VPN pour l’UFC a été publié dans le numéro 116 de GNU Linux Magazine France (GLMF).

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

Linux : outils

mardi, avril 28th, 2009

Dans la boite à outils que propose Linux nous pouvons trouver :
iwconfig
dhclient

iwconfig permet de voir la configuration d’une interface WIFI …
iwconfig eth1
eth1 IEEE 802.11b ESSID:"ufc-personnels" Nickname:"ipw2100"
...

… ou de la reconfigurer :

iwconfig eth1 essid ufc-vpn

iwconfig eth1
eth1 IEEE 802.11b ESSID:"ufc-vpn" Nickname:"ipw2100"
...

et l’outils dhclient vous permet de récupérer via DHCP une adresse IP :

dhclient
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth1/00:04:23:96:c2:09
Sending on LPF/eth1/00:04:23:96:c2:09
Listening on LPF/eth0/00:06:1b:d8:c4:cb
Sending on LPF/eth0/00:06:1b:d8:c4:cb
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 172.21.7.254
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 172.21.7.254
bound to 172.21.7.231 -- renewal in 5416 seconds.

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

problème serveur : les utilisateurs ont un problème de routage asymétrique

mardi, janvier 6th, 2009

Si les utilisateurs ont un problème de route asymétrique entre l’envoie d’un paquet et sa réception ce qui entraîne une rupture de connexion de la part du FireWall, il faut commencer par regarder la configuration des interfaces car c’est à cet endroit que nous effectuons un routage.
Pour rappel, le FireWall divise en quatre grandes classes l’ensemble des classe IP de l’UFC (chacune à sa VRF).
Sur le FW, plusieurs de ces classes sont réunis et il faut faire extrêmement attention à ne pas créer sur la machine VPN un routage inter-classe qui entraînera pour le moins un dysfonctionnement pour l’utilisateur (au pire un dysfonctionnement d’une partie du réseau de l’UFC).
Avec le code suivant :
auto eth0.168
iface eth0.168 inet static
address 172.20.16.220
netmask 255.255.255.0
network 172.20.16.0
broadcast 172.20.16.255
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
up ip rule add fwmark 18 table admin.pres
down ip rule del fwmark 18
down ip route del table admin.pres

Nous avons deux règles très importantes :
la première :
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
qui implique une route par défaut pour tous les utilisateurs VPN du tag 18 (admin.pres).
la seconde :
up ip rule add fwmark 18 table admin.pres
car c’est par elle que l’on affecte au client le tag 18.

Si le code dans le fichier /etc/network/interfaces ressemble à
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
ip up rule add fwmark 18 table admin.pres

Tous les clients de ce réseaux ne seront pas affecté au tag 18 et donc tout leur trafic transitera par l’interface de routage par défaut de la machine qui est sans aucun doute dans une VRF distincte et donc entraînera un dysfonctionnement des connexion de ces clients vers l’extérieur de leur réseau de connexion.

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

Problème serveur : patch freeradius pour prise en compte du retour des proxies

vendredi, juin 13th, 2008

Lors de l’utilisation d’un proxy par freeradius celui-ci, et quelle que soit la réponse du proxy, retourne toujours “OK” dans l’authentification. Ce problème a été solutionné par Jean-Michel Caricand qui a proposé un patch pour freeradius :

*** freeradius-1.1.3/src/main/radiusd.c Tue May 16 18:26:07 2006
--- /root/FREERADIUS/freeradius-1.1.3/src/main/radiusd.c        Sat Jan 26
11:04:06 2008
***************
*** 1585,1590 ****
--- 1585,1595 ----
        int rcode;
        rcode = proxy_receive(request);
        switch (rcode) {
+               case RLM_MODULE_REJECT:
+                       DEBUG2("Request %d rejected in proxy_receive.", request->number);
+                       request_reject(request);
+                       goto finished_request;
+                       break;
                 default:  /* Don't Do Anything */
                         break;
                 case RLM_MODULE_FAIL:

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

Problème serveur : récupération sur radius de l’IP de l’utilisateur

vendredi, juin 13th, 2008

L’architecture du service VPN (station de travail -> VPN1/2/3/… -> RADIUS -> LDAP/RADIUS/… ) pose le problème suivant : le client RADIUS est le serveur VPN. De ce fait, RADIUS reçoit par défaut  l’adresse IP du NAS (machine VPN) alors qu’il serait intéressant d’obtenir également l’adresse IP du client réel, c’est-à-dire, la station de travail.

Sur le serveur VPN, le démon XL2TP lance le service PPP qui permet à l’utilisateur de transmettre des informations, notamment login/mot de passe. Le service PPP, inclut dans ses sources une partie RADIUSCLIENT (les binaires radiusclient1 que l’on charge sur le serveur VPN sont donc inutiles) qui adresse au serveur RADIUS via le protocole RADIUS les informations reçues par le serveur VPN.

Or nous avons besoin pour certaines applications du VPN de connaître (reconnaître) l’adresse IP de l’utilisateur (client final à ne pas confondre avec le client du serveur RADIUS) pour l’autoriser ou non à établir une connexion.
Or les arguments transmis par le VPN au serveur RADIUS sont les suivants :

Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "utilisateur@realm"
User-Password = "mot_de_passe"
NAS-IP-Address = IP_serveur_VPN
NAS-Port = 1

Le serveur RADIUS n’a donc pas d’information sur l’IP de l’utilisateur.

Jean-Michel Caricand a créé et appliqué un patch de quelques lignes pour transmettre cette information.
En effet, dans le fonctionnement de XL2TP (L2TP) sur le serveur VPN, nous pouvons transmettre des attributs statiques à l’aide de l’argument “ipparam”. Si cet argument est transmis, l’attribut qui suit est également transmis. On retrouve cela dans les fichiers de configuration avec le plus souvent une chaîne de caractères (par exemple pour éviter les récursions sur L2TP).
Notre idée est simple : introduire après l’argument ipparam l’adresse IP de l’utilisateur.
cela nous donne le patch :

--- xl2tpd-1.1.12.orig/control.c        2007-10-20 06:22:55.000000000 +0200
+++ xl2tpd-1.1.12/control.c     2008-06-12 15:01:16.000000000 +0200
@@ -954,6 +954,14 @@ int control_finish (struct tunnel *t, st
}
if (c->lns->debug)
po = add_opt (po, "debug");
+
+        po = add_opt (po, "ipparam");
+        po = add_opt (po, "%s", IPADDY (t->peer.sin_addr));
+
+        l2tp_log (LOG_DEBUG,
+             "Use ipparam option with %s value\n",
+             IPADDY (t->peer.sin_addr));
+
if (c->lns->pppoptfile[0])
{
po = add_opt (po, "file");

maintenant, nous avons bien une information supplémentaire très facile à traiter :

Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "utilisateur@realm"
User-Password = "motdepasse"
Calling-Station-Id = "IP_utilisateur"
NAS-IP-Address = IP_serveur_VPN
NAS-Port = 1

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

RADIUS : NAS-IP-Address et fichier /etc/hosts

jeudi, mai 29th, 2008

Si votre fichier /etc/hosts contient
10.0.0.1 vpn3.univ-fcomte.fr vpn3

et que l’IP véritable de vpn3 soit 194.57.89.97

et que RADIUS est bien configuré pour 194.57.89.97

La requête RADIUS venant de vpn” sera bien accepter, mais il y aura un problème d’authentification si on vérifie le NAS-IP-address

paquet recu par le serveur RADIUS

rad_recv: Access-Request packet from host 194.57.89.105:32779, id=171, length=76
Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "test@ufc"
User-Password = "monpassword"
NAS-IP-Address = 10.0.0.1
NAS-Port = 0

au lieu de :

rad_recv: Access-Request packet from host 194.57.89.105:32779, id=171, length=76
Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "test@ufc"
User-Password = "monpassword"
NAS-IP-Address = 194.57.89.105
NAS-Port = 0

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

installation d’un serveur VPN : ajout d’un REALM

mercredi, mai 21st, 2008

Ajout d’un REALM “le-realm” sur un réseau “ttt.ttt.ttt.nnn 255.255.255.ZZZ”, vlan XXX

creation du vlan sur le commutateur CISCO
conf t
vlan XXX
name blabla
exit
int vlanXXX
desc blabla
ip vrf forwarding FW_YYYYY
ip address ttt.ttt.ttt.ttt 255.255.255.ZZZ
no shutdown
exit
interface GigabitEthernet3/29
switchport trunk allowed vlan add XXX
interface GigabitEthernet3/38
switchport trunk allowed vlan add XXX

sur le serveur VPN
emacs /etc/network/interfaces
auto eth0.XXX
iface eth0.XXX inet static
address ttt.ttt.ttt.ttu
netmask 255.255.255.ZZZ
network ttt.ttt.ttt.0
broadcast ttt.ttt.ttt.ttv
up ip route add default via ttt.ttt.ttt.ttt dev eth0.XXX table le.realm
up ip rule add fwmark MMM table le-realm
down ip rule del fwmark MMM
down ip route del table le.realm

emacs /etc/iproute2/rt_tables
10 femto.ext
11 lifc.lab
12 lifc.edu
13 ufc.generic
MMM le.realm

modification de la base de données realmacl
add realm
add network
=> choix du nas
=> tranche ip
=> marque iptable

sur le serveur RADIUS (exemple avec le realm ufc-pub sur 194.57.81.0/24 coupé en trois parties) :
/etc/raddb/radiusd.conf
realm ufc-pub {
format = suffix
delimiter = "@"
ignore_default = no
ignore_null = no
}

ippool ufc_pub_pool {
name = ufc_pub_pool
range-start = 194.57.81.1
range-stop = 194.57.81.10
netmask = 255.255.255.0
cache-size = 800
session-db = ${raddbdir}/db-ufc_pub_pool.ippool
ip-index = ${raddbdir}/db-ufc_pub_pool.ipindex
override = no
maximum-timeout = 0
}

ippool ufc_pub_pool1 {
name = ufc_pub_pool1
range-start = 194.57.81.11
range-stop = 194.57.81.251
netmask = 255.255.255.0
cache-size = 800
session-db = ${raddbdir}/db-ufc_pub_pool1.ippool
ip-index = ${raddbdir}/db-ufc_pub_pool1.ipindex
override = no
maximum-timeout = 0
}
...
}

authorize {
ufc-pub
}

accounting {
ufc_pub_pool
ufc_pub_pool1
}

post-auth {
ufc_pub_pool
ufc_pub_pool1
}

créer et attribuer à radiusd.radiusd les fichier ${raddbdir}/db-ufc_pub_pool.ippool et ${raddbdir}/db-ufc_pub_pool.ipindex.

dans le fichier /etc/raddb/users on attribue les méthodes d’authentification, d’autorisation et les pool pour le DHCP :
DEFAULT Realm == "ufc-pub", NAS-IP-Address == 194.57.91.251, Pool-Name := "ufc_pub_pool", Auth-Type = "LDAP_UFC", Autz-Type = "LDAP_UFC"
Fall-Through = No
DEFAULT Realm == "ufc-pub", NAS-IP-Address == 194.57.91.250, Pool-Name := "ufc_pub_pool1", Auth-Type = "LDAP_UFC", Autz-Type = "LDAP_UFC"
Fall-Through = No
DEFAULT Realm == "ufc-pub", NAS-IP-Address == 194.57.89.65, Pool-Name := "ufc_pub_pool2", Auth-Type = "LDAP_UFC", Autz-Type = "LDAP_UFC"
Fall-Through = No

Ne pas oublier le fichier /etc/raddb/clients.conf :
client 194.57.91.250 {
secret = blabla
shortname = test-vpn
nastype = other
}

client 194.57.91.251 {
secret = blabla
shortname = vpn1
nastype = other
}

client 194.57.89.65 {
secret = blabla
shortname = vpn2
nastype = other
}

comme nous avons un identificateur de realm il faut aussi (même si ce realm est géré en local sur ce radius) configurer le fichier /etc/raddb/proxy.conf :
realm ufc-pub {
type = radius
authhost = LOCAL
accthost = LOCAL
# strip
}

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

Installation d’un serveur VPN : la base

mercredi, mai 21st, 2008

installation serveur VPN debian Etch (exemple avec vpn2.univ-fcomte.fr en 194.57.89.65)

swap 2Go primaire
/boot 0.1Go primaire
/ 1Go primaire
/usr 5Go logique
/tmp 1Go logique
/var 24Go logique
/backup 37Go logique

vi /etc/apt/sources.list
mettre un # devant le cdrom

apt-get install vlan
modprobe 8021q
echo "8021q" >> /etc/modules

modifier le fichier /etc/network/interfaces
#auto eth0
#iface eth0 inet static

auto eth1
iface eth1 inet static
address 194.57.89.65
netmask 255.255.255.240
network 194.57.89.64
broadcast 194.57.89.79
gateway 194.57.89.78
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 194.57.91.200
dns-search univ-fcomte.fr
#mtu 1400

un /etc/init.d/network restart ne suffit pas (eth0 reste configuré) => reboot de la machine.
=> corrigé par la procédure suivante :
– stopper l’interface (ifdown eth…)
– modifier les interfaces (suppression/ajout/modif)
– relancer l’interface (ifup eth…)

configurer le commutateur pour mettre le port correspondant à eth0 en trunk

modification du fichier /etc/sysctl.conf
ajout de :
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.all.accept_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.ip_forward=1
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

sysctl -p

apt-get install ssh x-window-system vim emacs openswan traceroute wireshark tcpdump

apt-get install sendmail logwatch tripwire rsync ntp
modif du fichier sendmail :
DS[smtp.univ-fcomte.fr]
DMvpn2.univ-fcomte.fr

/etc/init.d/sendmail restart

vi /etc/aliases
root : vpn-master@univ-fcomte.fr
newaliases

mettre à jour le serveur DNS avec vpn2.univ-fcomte.fr 194.57.89.65

config de /etc/ntp.conf
server ntp.univ-fcomte.fr prefer
server cri-08.univ-fcomte.fr

apt-get remove exim4

rsync -av 194.57.91.250:/etc/ipsec* /etc/
config avec la valeur ip du serveur

vi /etc/apt/sources.list
deb http://172.20.65.21/debian/ etch-lifc main
apt-get update
wget http://172.20.65.21/etch/lifc-apt.key
apt-key add lifc-apt.key
apt-get install xl2tpd radiusclient1
apt-get remove l2tpd
rsync -av 194.57.91.250:/etc/radiusclient /etc/
ajout du serveur VPN dans les clients RADIUS sur le serveur RADIUS.

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

« Older Entries
Newer Entries »