Posts Tagged ‘vpn’

Fin prévu de vpn14 et évolution de vpn20

jeudi, janvier 6th, 2022

Bonjour à toutes et tous,

depuis 2008, le VPN évolue pour rendre un service plus simple (souvent) et plus sécurisant (toujours).

Voici le rappel des versions successives :

  • 2008-2014 : vpn1 (Besançon), vpn2 (Montbéliard), vpn3 (Belfort) en IPSEC/ikeV1/L2TP
  • 2014-2020 : vpn14 IPSEC/ikeV1/SHREW
  • 2020-2022 : vpn20-1, vpn20-2 IPSEC/ikeV2/natif OS

La pandémie et l’accélération du “travail à la maison/télétravail” a fait prendre conscience à chacun de la nécessité des outils de travail à distance. Le VPN a donc évolué en 2020 pour en faciliter l’accès.

Serveur vpn14, connexion SHREW

Nous projetons maintenant la fermeture de l’ancien serveur vpn14 (ikev1/shrew) pour juillet 2022.

Si vous possédez un accès VPN avec SHREW, il faudra penser à évoluer sur la nouvelle infrastructure.

Administration du service

Dans le même temps, nous allons changer de procédure de création des droits d’accès au VPN pour le déléguer aux composantes et laboratoires. La création de certificat n’étant plus nécessaire, cette délégation permettra de simplifier la mise en place des droits des usagers sur les realms @ufc et @ufc-pub d’une part et sur les realms spécifiques d’autre part.

MFA (Multi-Factor Authentication)

Nous allons mettre en place pour le VPN un 2FA (Double Authentification). Cette mesure permettra de sécuriser un peu plus les accès au sein de l’UFC.

Le moyen retenu pour le moment est Google Authenticator.

Cela se concrétise par l’usage d’un code (généré par une application ou un add-on de navigateur) à la fin de votre mot de passe.

L’application se base sur la date, l’heure et un nombre tiré au hasard (propre à votre instance d’application et au système d’authentification de l’UFC pour votre compte) pour générer le code à appliquer en plus de votre mot de passe. Code qui certifiera que vous êtes bien la personne qui doit être authentifiée.

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.

liste des serveurs VPN et des REALMS

vendredi, juillet 4th, 2008

VPN1 : Besançon 194.57.91.250, realm @ufc @lifc-lab @lifc-edu, @femto, @cri, @admin-bu et @admin-presidence.
VPN2 : Montbéliard 194.57.89.97, realm @ufc
VPN3 : Belfort 194.57.89.105, realm @ufc et @iutbm (à venir @lifc-lab)

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.

Problème Windows : connexion filaire OK connexion WIFI NOK

mercredi, 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

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

jeudi, 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.

VPN : qui s’occupe de quoi ?

jeudi, avril 10th, 2008

Le projet est techniquement réalisé par Jean-Michel Caricand, Ghislaine Foltête et Marc Hamelin.
Par techniquement on entend la configuration/debug/patch sur les applications openswan, (x)l2tpt, freeradius, gantry, apache, postgresql, openCA/tinyCA. C’est l’interaction entre ces différentes briques de base qui définit le projet VPN.
Le projet est opérationnellement maintenu sur différents niveaux :
RSSI : Bertrand Astric, Patrice Koch
Patch Centos : Ghislain Pruniaux
Patch sur les outils : Jean-Michel Caricand
Maintenance VPN (tous les outils) : Jean-Michel Caricand, Ghislaine Foltête et Marc Hamelin
Suivi des certificats : Ghislaine Foltête et Marc Hamelin sous couvert des RSSI
Realm : correspondants réseaux
Droits utilisateurs : correpondants réseaux
Documentation : Jean-Michel Caricand, Ghislaine Foltête et Marc Hamelin
Communication : Ghislaine Foltête et Marc Hamelin