Depuis la version 16.1
modifié par Stéphane Dugravot
sur 03/06/2014 - 14:19
sur 03/06/2014 - 14:19
Commentaire de modification :
Il n'y a aucun commentaire pour cette version
À la version 14.1
modifié par Nicolas Rogier
sur 06/03/2013 - 12:28
sur 06/03/2013 - 12:28
Commentaire de modification :
Il n'y a aucun commentaire pour cette version
Résumé
-
Propriétés de la Page (2 modifications, 0 ajouts, 0 suppressions)
-
Objets (1 modifications, 0 ajouts, 0 suppressions)
Détails
- Propriétés de la Page
-
- Auteur du document
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. dugravot61 +XWiki.rogier5 - Contenu
-
... ... @@ -28,7 +28,7 @@ 28 28 29 29 = Configuration du VPN @ul = 30 30 31 -* (% class="confluence-link" %) [[(% class="confluence-link" %)Documentation générale VPN(%%) UL>>doc:xwiki: publique.dn.com.infra.Servicesnumériques.Documentation officielleVPN.WebHome]]31 +* (% class="confluence-link" %) [[(% class="confluence-link" %)Documentation générale VPN(%%) UL>>doc:xwiki:interne.dir.dn.infra.infra.VPN.WebHome]] 32 32 33 33 = Split tunel = 34 34 ... ... @@ -35,21 +35,15 @@ 35 35 Le VPN met en œuvre de la tunnélisation partielle (split tunel), ce qui signifie que chaque serveur, chaque subnet doit clairement être déclaré pour qu'un usager du VPN soit tunnélisé vers la ressource à obtenir. Contrairement au VPN de type tunnélisation complète, toutes les requêtes ne sont pas redirigées dans le tunnel. Ceci a 3 conséquences majeures : 36 36 37 37 1. L'accès aux ressources locales reste possible, par exemple si le VPN est utilisé depuis le domicile ou depuis un réseau local, l'imprimante du réseau local, ou le serveur de fichier restera accessible. 38 -1. L'ensemble des communication ne seront pas "protégés" par la tunnélisation. Par exemple dans le cas de l'usage d'un réseau WiFi de type ouvert (cas du réseau [[Universite de Lorraine>>doc:xwiki:interne.dir.dn.infra. DNDoc.Reseaux sans fil - WiFi.WebHome]]) une partie des connexions n'est donc plus nécessairement sécurisée par le VPN.38 +1. L'ensemble des communication ne seront pas "protégés" par la tunnélisation. Par exemple dans le cas de l'usage d'un réseau WiFi de type ouvert (cas du réseau [[Universite de Lorraine>>doc:xwiki:interne.dir.dn.infra.infra.Réseaux sans fil - WiFi.WebHome]]) une partie des connexions n'est donc plus nécessairement sécurisée par le VPN. 39 39 1. Il devient nécessaire de déclarer une route que le concentrateur VPN va mettre en œuvre pour le client afin d'assurer que le client accède à cette ressource. Sans cela, la requête ne passera pas à travers le VPN, et les accès seront sans doute impossibles. 40 40 41 41 = ACLs = 42 42 43 -== Coté services == 44 - 45 45 Le VPN @ul tunnélise des adresses du subnet **172.19.96.0/21** 46 46 47 47 Ceci doit vous permettre de faire les ouvertures d'ACLs nécessaires. 48 48 49 -== Coté subnet client == 50 - 51 -Voir la page : [[Déclarations d'ACL nécessaires au bon fonctionnement du client VPN>>doc:xwiki:publique.dn.com.infra.Services numériques.Documentation officielle VPN.Déclarations d'ACL nécessaires au bon fonctionnement du client VPN.WebHome]] 52 - 53 53 = Tableau des demandes d'ouvertures de routes statiques = 54 54 55 55 Pour assurer l'accès aux ressources, il vous est nécessaire de réaliser ici des demandes de mise en place de routes statiques. Inscrivez simplement dans la colonne Route, le(s) subnet(s) sous la forme CIDR de la ressource à rendre disponible au travers du VPN. Le processus est le suivant : ... ... @@ -127,12 +127,3 @@ 127 127 )))|(% colspan="1" %)((( 128 128 129 129 ))) 130 -|(% colspan="1" %)((( 131 -INSERM-Lionnois 132 -)))|(% colspan="1" %)((( 133 -193.55.6.247 134 -)))|(% colspan="1" %)((( 135 -Accès serveur CRONOS 136 -)))|(% colspan="1" %)((( 137 -✅️ 138 -)))
- Confluence.Code.ConfluencePageClass[0]
-
- Id
-
... ... @@ -1,1 +1,1 @@ 1 - 2491385161 +54598608