Archive for the ‘informations techniques’ Category

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}

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).

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.

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.

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:

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

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

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
}

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.

Surveillance des services sur les serveurs VPN

mardi, mai 20th, 2008

Pour effectuer la surveillance des serveurs VPN (une fois opérationnel, ces serveurs seront des points d’entrée critique), nous avons décider d’utiliser NAGIOS et l’addon NRPE.
Sur les serveurs VPN, lancer apt-get update && apt-get install nagios-plugins nagios-nrpe-server
et apt-get install nagios-plugins-lifc.
Modifier le fichier /etc/nagios/nrpe.cfg
allowed_hosts=127.0.0.1,<adresse_serveur_nagios>

#command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hda1
#command[check_disk2]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hdb1
command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /
command[check_ppp_connect]=/usr/lib/nagios/plugins/check_ppp_connect -w 20 -c 30
command[check_xl2tpd]=/usr/lib/nagios/plugins/check_xl2tpd

relancer le serveur NRPE : /etc/init.d/nagios-nrpe-server restart

modification non obligatoire dans le fichier /etc/services
nrpe 5666/tcp # Nagios NRPE

On vérifie que le service nrpe tourne correctement :
netstat -at | grep nrpe

Tester la connexion depuis le serveur Nagios : /usr/local/nagios/libexec/check_nrpe -H <adresse_client_nagios> -c check_users
sur le serveur nagios
définition d’un template service :
define service{
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 2
notification_interval 120
contact_groups admins-serveurs-vpn
notification_options w,u,c,r
notification_interval 120
notification_period 24x7
name services-vpn
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized (disabling this can lead to major performance problems)
obsess_over_service 1 ; We should obsess over this service (if necessary)
check_freshness 0 ; Default is to NOT check service 'freshness'
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
}

définition d’un template host :
define host{
name linux-box ; The name of this host template
use generic-host ; This template inherits other values from the generic-host template
check_period 24x7 ; By default, Linux hosts are checked round the clock
check_interval 5
# retry_interval 1
max_check_attempts 10
check_command check-host-alive
notification_period 24x7
notification_interval 120
notification_options d,r
contact_groups admins-serveurs-vpn
register 0
}

création des hotes :

define host{
host_name Besancon_Bouloie_metro-C_test-vpn ; The name we're giving to this server
alias test-vpn ; A longer name for the server
address 194.57.91.251 ; IP address of the server
use linux-box ; Inherit default values from a template
}
...

création des services :

define service{
use services-vpn
host_name Besancon_Bouloie_metro-C_test-vpn
service_description CPU Load
check_command check_nrpe!check_load
}
...

création du hostgroup :

define hostgroup{
hostgroup_name TEST_Equipements
alias TEST
members Besancon_Bouloie_metro-C_test-vpn, Besancon_Bouloie_metro-C_vpn1, Besancon_Bouloie_metro-C_vpn2
}