Gestion des proxies sous Firefox

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.

Connexion VPN depuis Mac OS X Leopard

mai 22nd, 2008

Nous vous informons que le système Mac OS X Leopard est compatible avec l’architecture VPN universitaire.

Actuellement 3 machines fonctionnant avec ce système d’exploitation sont en cours de tests.

La documentation décrivant la création d’une connexion VPN sur Leopard est disponible ici.

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

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

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.

Problème Windows : connexion filaire OK connexion WIFI NOK

mai 21st, 2008

si votre connexion filaire fonctionne parfaitement bien et qu’en wifi vous n’arrivez pas à joindre le serveur VPN (code erreur windows 698…), il est fort possible que vous ayez un client VPN type “NETGEAR VPN CLIENT” déjà configuré sur votre machine. Celui-ci n’empêche pas la connexion filaire met prend la main sur les connexions WIFI

Surveillance des services sur les serveurs VPN

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
}

Configuration serveur : connexion client XP/VISTA

mai 15th, 2008

Depuis la sortie de VISTA SP1, la connexion IPSEC ne s’effectue plus correctement car il manque une commande (forceencaps=yes) dans la configuration des connexions pour les clients XP/VISTA.

Si, dans la configuration du serveur nous modifions légèrement la connexion pour les clients XP/VISTA en ajoutant :
conn vpn-l2tp-XP
# force l'encapsulation en UDP
forceencaps=yes

alors la connexion d’un VISTA SP1 fonctionne.
De fait, il faudra faire attention en cas de problème de connexion à bien ajouter dans REGEDIT la valeur (pour VISTA) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
(pour XP) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec valeur DWORD AssumeUDPEncapsulationContextOnSendRule à 2 comme cela est spécifié dans l’article Problème VISTA/XP SP2 : modification de la base de registre

Pour le moment nous avons deux choix au niveau du serveur :
– imposer la manipulation de regedit pour les clients XP et garder un type de connexion commune pour XP et VISTA
– régénérer des certificats pour les clients VISTA et créer une connexion spécifique pour VISTA et conserver la connexion XP actuelle.
Le choix sera déterminé semaine 21 suivant les essais faits avec XP SP2 et SP3 et VISTA sans SP1 et avec SP1. Pour le moment seuls les clients XP SP2 et VISTA sans SP1 peuvent utiliser les serveurs IPSEC.

Les résultats des tests démontrent que pour Windows XP SP1/SP2 et SP3 nous pouvons conserver la même configuration client et serveur => aucun changement à effectuer sur les postes clients XP ni de changement de certificat.

Pour Windows VISTA sans SP1 ou avec SP1, il faut mettre à jour la base de registre.

Problème mail : utilisation d’un client mail à travers le VPN

mai 15th, 2008

Si vous êtes à l’extérieur de l’UFC et que vous utilisez un client de messagerie (par exemple le client de messagerie installé sur votre poste personnel à la maison), vous allez être confronté à un problème : l’adresse IP que vous fournit le serveur VPN est en classe privée, vous ne pouvez donc pas vous connecter à votre fournisseur d’accès (provider) privé.
– Pour remédier à cela vous pouvez reconfigurer votre client de messagerie avec les indications suivantes. Attention, cette solution ne fonctionnera plus si vous vous connectez en dehors d’une connexion VPN.
– L’autre solution est de ne se servir de sa messagerie personnelle qu’en dehors de la connexion VPN.

Problème WIFI SSID vpn-ufc : DNS / adresse IP

mai 15th, 2008

Attention, lorsque vous configurez l’adresse du serveur VPN en utilisant le SSID vpn-ufc présent sur les bornes de l’Université de Franche-Comté, vous ne devez pas mettre le nom du serveur mais son adresse IP.
ex : 194.57.91.251 au lieu de test.vpn.univ-fcomte.fr
ex : 194.57.91.250 au lieu de vpn1.univ-fcomte.fr

En effet, ce SSID ufc-vpn n’a accès qu’aux serveurs VPN et donc n’a pas accès aux différents serveurs de nom (que ce soit ceux de l’UFC ou de votre provider).

Problème Windows : Zone Alarm

mai 13th, 2008

Zone Alarm peut vous poser des soucis de connexion car établir un VPN est une action de connexion sur un site distant via un logiciel non enregistré par Zone Alarm.
blocage du serveur VPN

Pour cela il suffit d’ajouter le serveur dans les machines autorisées pour une connexion (ajout d’une adresse IP) :
déblocage du serveur VPN

Le même problème surviendra pour les accès sur des réseaux intérieurs à l’UFC via le VPN :
blocage d\'un réseau

il faudra encore une fois ajouter ce réseau à la liste des réseaux sécurisés :
déblocage d\'un réseau