Les VPN lancés automatiquement par LAC sont également appelés VPN de numérotation automatique LAC. Celles-ci agissent exactement comme elles le font une fois la configuration de LAC terminée, celui-ci composera automatiquement le LNS et établira un tunnel et une session L2TP, ce qui signifie qu'il n'est pas nécessaire que l'utilisateur de l'organisation de la succursale se connecte pour déclencher cette opération. Pour l'utilisateur de l'organisation de la succursale, cela signifie que l'accès au réseau du siège est identique à l'accès au réseau de sa propre agence et qu'il ne se sentira pas du tout comme s'il se trouvait sur une connexion à distance. Cependant, dans cette méthode, le LNS n’authentifie que le LAC. Ainsi, tant que l’utilisateur de l’organisation de la succursale est capable de se connecter au LAC, il peut utiliser le tunnel L2TP pour se connecter au siège, ce qui signifie que cette méthode offre une sécurité légèrement inférieure à celle du VPN initiés par un NAS.
1 Principes et configuration de VPN initiés automatiquement par LAC
Comme le montre la figure 1-1, le processus de configuration des VPN initiés automatiquement par le LAC est similaire à celui des VPN initiés
par le client, sauf que pour les VPN initiés par le LAC, le LAC a remplacé le rôle joué par le client L2TP. pour les VPN initiés par le client.
Figure 1-1 Processus de configuration des VPN initiés automatiquement par LAC
Chaque étape du processus de configuration est en grande partie similaire au processus de configuration des VPN initiés par le client. Je n’en
dirai pas plus, si ce n’est que vous pouvez consulter «5.4 VPN initiés par le client L2TP». Un point à noter est qu'à l'étape 3, le LNS authentifie
uniquement le LAC et, une fois l'authentification réussie, il attribue une adresse IP à l'interface VT du LAC,et non à l'utilisateur de l'organisation
de la succursale. Bien que le LNS n'attribue pas d'adresse IP à l'organisation de la succursale, cela ne signifie pas que l'adresse IP de celle-ci
peut être configurée à volonté. Afin de garantir un accès normal entre le réseau de l’agence et le réseau du siège, planifiez des segments de
réseau privés indépendants et distincts pour l’organisation de la succursale et les réseaux du siège, et veillez à ce que les segments du réseau
ne se chevauchent pas
La configuration de VPN initiés automatiquement par LAC n’est pas compliquée et nous pouvons configurer un réseau comme celui illustré à la
figure 1-2.
Figure 1-2 Réseau VPN auto-initié par LAC
La configuration du LAC et du LNS est présentée dans le tableau 1-1. Un point essentiel est que les connexions entre le LAC, le LNS et le serveur
interne sont des connexions directes, éliminant ainsi la nécessité de configurer le routage. L'authentification utilisateur utilise également une
authentification locale relativement simple. De plus, les passerelles doivent être configurées à la fois pour l'utilisateur de l'organisation de branche
et le serveur de réseau interne, afin de garantir que les paquets échangés entre les deux puissent être envoyés au LAC et au LNS.
Tableau 1-1 Configuration d'un VPN initié automatiquement par LAC L2TP
LAC | LNS |
l2tp enable l2tp-group 1 tunnel authentication tunnel password cipher Password1 tunnel name lac start l2tp ip 1.1.1.2 fullusername lac //Désigne une adresse pour l'autre terminal du tunnel. interface Virtual-Template 1 ppp authentication-mode chap ppp chap user lac ppp chap password cipher Password1 ip address ppp-negotiate call-lns local-user lac binding l2tp-group 1 //LAC compose le LNS. ip route-static 192.168.0.0 255.255.255.0 Virtual-Template 1 //Configurer un route statique vers le réseau du siège; cela diffère de celui des VPN initiés par le client et des VPN initiés par le NAS, et le LAC doit configurer cette route pour guider les paquets d'utilisateurs de l'organisation de branche cherchant à accéder au réseau HQ dans le tunnel L2TP. | l2tp enable interface Virtual-Template 1 ppp authentication-mode chap ip address 10.1.1.1 255.255.255.0 remote address pool 1 l2tp-group 1 tunnel authentication tunnel password cipher Password1 allow l2tp virtual-template 1 remote lac //Permet l'accès à distance. aaa local-user lac password Password1 local-user lac service-type ppp ip pool 1 10.1.1.2 //Étant donné que le LNS n'attribue que des adresses pour le LAC, une seule adresse IP doit être configurée dans le pool d'adresses. ip route-static 172.16.0.0 255.255.255.0 Virtual-Template 1 //Configurer un route statique vers le réseau de l'organisation de la succursale; si un NAT source est configuré sur le LAC, cette route n'a pas besoin d'être configurée et des informations supplémentaires à ce sujet sont fournies ci-dessous. |
Les caractéristiques des tunnels VPN initiés automatiquement par LAC sont brièvement résumées ci-dessous:
Comme le montre la figure 1-3, dans les scénarios VPN auto-initiés par LAC, un tunnel permanent est établi entre LAC et LNS, qui ne transporte
qu'une session permanente L2TP et une connexion PPP. La session L2TP et la connexion PPP existent uniquement entre le LAC et le LNS.
Figure 1-3 Relation entre le tunnel / la session L2TP et la connexion PPP sur un VPN auto-initié par le LAC
L'encapsulation PPP et l'encapsulation L2TP dans un VPN auto-initié par le LAC sont limitées uniquement aux paquets échangés entre le LAC
et le LNS, comme illustré à la Figure 1-4.
Figure 1-4 Processus d'encapsulation de paquets VPN initié automatiquement par LAC
De plus, il reste un autre problème qui nécessite une attention particulière, à savoir comment les paquets de retour entrent dans le tunnel.
Ce processus est différent de celui des VPN initiés par le client et des VPN initiés par le NAS; Dans les VPN lancés automatiquement par
le LAC, le LNS n'émet qu'une seule adresse de destination pour la route UNR de l'adresse d'interface VT du LAC et aucune route ne se dirige
vers le réseau de l'organisation de la succursale. En réponse à cela, le LNS affirme: "Je ne suis responsable que de l'attribution d'adresses IP
et je peux m'assurer que l'interface VT du LAC est atteinte. les adresses sont, alors je ne peux que dire "Désolé, je ne peux pas vous aider" ".
Comment ce problème peut-il être résolu? La méthode la plus simple consiste à configurer manuellement un itinéraire statique vers le réseau de
l'organisation de branche sur le LNS, en guidant les paquets de retour dans le tunnel:
[LNS] ip route-static 172.16.0.0 255.255.255.0 Virtual-Template 1
Existe-t-il d'autres méthodes que nous pouvons utiliser en plus de la configuration d'un itinéraire statique? Je viens de rappeler NAT, que nous
avons mentionné plus tôt! Même si le LNS ne reconnaît que les adresses IP qu'il attribue, nous pouvons configurer une fonction NAT source sur
le LAC pour convertir les adresses source des paquets de la succursale ayant accès au réseau HQ en adresse de l'interface VT il s'agit de
l'adresse Easy-IP méthode "source NAT" de la méthode. Une fois que le LNS a reçu un paquet de retour et qu'il a découvert que l'adresse de
destination est l'adresse de l'interface VT du LAC, il la transmettra par une route directe dans le tunnel. De cette manière, il n’est pas nécessaire
de configurer un itinéraire statique sur le LNS.
J'utiliserai ensuite un réseau réel illustré à la figure 1-5, à titre d'exemple, pour présenter brièvement le processus complet d'encapsulation et de
décapsulation de paquets lorsqu'un utilisateur d'organisation de branche accède au serveur de siège après la configuration du NAT source sur un
LAC:
Figure 1-5 Processus d'encapsulation de paquets VPN initié automatiquement par le LAC après la configuration du NAT source sur le LAC
1. Une fois que le LAC a reçu un paquet original d'un utilisateur de l'organisation souhaitant accéder au serveur HQ, il vérifie l'itinéraire en fonction
de l'adresse de destination, sélectionne notre itinéraire statique configuré manuellement et envoie le paquet à l'interface VT.
2. Le LAC effectue une conversion NAT sur le paquet d'origine à l'interface VT, convertissant l'adresse source en adresse de l'interface VT,
puis encapsule un en-tête PPP, un en-tête L2TP et une adresse réseau publique sur le paquet. Le LAC vérifie ensuite l'itinéraire en fonction
de l'adresse de destination du réseau public et envoie le paquet encapsulé au LNS.
3. Une fois que le LNS a reçu le paquet, il supprime l'en-tête PPP et l'en-tête L2TP, vérifie l'itinéraire en fonction de l'adresse de destination
(il s'agit d'un itinéraire directement connecté), puis envoie le paquet au serveur HQ.
4. Une fois que le LNS a reçu le paquet de retour du serveur HQ, il vérifie l'itinéraire en fonction de l'adresse de destination, sélectionne l'itinéraire
émis automatiquement par le LNS et envoie le paquet à l'interface VT.
5. Le paquet est encapsulé avec un en-tête PPP, un en-tête L2TP et une adresse réseau publique sur l'interface VT. Le LNS vérifie l'itinéraire en
fonction de l'adresse du réseau public et envoie le paquet encapsulé au LAC.
6. Une fois que le LAC a reçu le paquet, il supprime l'en-tête PPP et l'en-tête L2TP, convertit l'adresse de destination du paquet en adresse de
l'utilisateur de l'organisation de la branche, puis envoie le paquet à l'utilisateur de l'organisation de la branche.
Un exemple de configuration du NAT source de la méthode Easy-IP sur le LAC est donné ci-dessous (cet exemple suppose que l'interface du
LAC qui se connecte au réseau de l'organisation de succursale appartient à la zone de confiance et que l'interface VT appartient à la zone DMZ):
[LAC] nat-policy interzone trust dmz outbound
[LAC-nat-policy-interzone-trust-dmz-outbound] policy 1
[LAC-nat-policy-interzone-trust-dmz-outbound-1] policy source 172.16.0.0 0.0.0.255
[LAC-nat-policy-interzone-trust-dmz-outbound-1] action source-nat
[LAC-nat-policy-interzone-trust-dmz-outbound-1] easy-ip Virtual-Template 1
2 Approche de la configuration de la politique de sécurité
L'approche globale de la configuration des politiques de sécurité dans les VPN auto-initiés par LAC est fondamentalement la même que les
approches de configuration présentées dans les deux sections précédentes, mais nous en discuterons encore brièvement ci-dessous.
Dans la Figure 1-6, nous supposons que sur les réseaux LAC et LNS, les GE0 / 0/1 sont connectés au réseau privé et appartiennent à la zone
de confiance; Les GE0 / 0/2 sont connectés à Internet et appartiennent à la zone de confiance. les interfaces VT appartiennent à la zone DMZ.
Figure 1-6 Configuration de la politique de sécurité réseau dans un VPN lancé automatiquement par le LAC
Le processus de configuration de la politique de sécurité est le suivant:
1. Nous configurons d’abord la politique de sécurité interzone la plus large possible pour faciliter les ajustements / tests du réseau privé virtuel
L2TP.
L'action de filtrage de paquets par défaut interzone du LAC est définie sur "permit":
[LAC] firewall packet-filter default permit all
L'action de filtrage de paquets par défaut interzone du LNS est définie sur "permit":
[LNS] firewall packet-filter default permit all
2. Une fois que le LAC et le LNS ont configuré avec succès le protocole L2TP, un utilisateur de l'organisation de la succursale envoie une
commande ping au serveur de réseau interne pour qu'il lance l'accès, puis les tables de session du LAC et du LNS sont vérifiées.
? LAC session table
[LAC] display firewall session table verbose
Current Total Sessions : 2
l2tp VPN:public --> public
Zone: local--> untrust TTL: 00:02:00 Left: 00:01:57
Interface: GigabitEthernet0/0/2 NextHop: 1.1.1.2 MAC: 00-00-00-c5-48-00
<--packets:38 bytes:2517 -->packets:62 bytes:4270
1.1.1.1:60416-->1.1.1.2:1701
icmp VPN:public --> public
Zone: trust--> dmz TTL: 00:00:20 Left: 00:00:07
Interface: Virtual-Template1 NextHop: 192.168.0.2 MAC: 00-00-00-c5-48-00
<--packets:1 bytes:60 -->packets:1 bytes:60
172.16.0.2:11749-->192.168.0.2:2048
La table de session fournit la direction des paquets sur le LAC, comme illustré à la figure 1-7.
Figure 1-7 Direction du paquet LAC
Comme indiqué ci-dessus, le LAC doit configurer une stratégie de sécurité Trust -> DMZ afin de permettre aux paquets de l'utilisateur de
l'organisation de la succursale cherchant l'accès au serveur interne de passer; il doit également configurer une stratégie de sécurité
Local -> Untrust pour permettre au LAC et au LNS d'établir un tunnel L2TP.
? LNS session table
[LNS] display firewall session table verbose
Current Total Sessions : 2
l2tp VPN:public --> public
Zone: untrust--> local TTL: 00:02:00 Left: 00:01:52
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets:18 bytes:987 -->packets:23 bytes:2057
1.1.1.1:60416-->1.1.1.2:1701
icmp VPN:public --> public
Zone: dmz--> trust TTL: 00:00:20 Left: 00:00:00
Interface: GigabitEthernet0/0/1 NextHop: 192.168.0.2 MAC: 54-89-98-62-32-60
<--packets:4 bytes:336 -->packets:5 bytes:420
172.16.0.2:52651-->192.168.0.2:2048
Il existe deux sessions sur le LNS: une session L2TP et une session ICMP. La table de session fournit la direction de paquet du LNS,
comme indiqué à la figure 1-8.
Figure 1-8 Direction des paquets LNS
D'après ce qui précède, il est évident qu'une stratégie de sécurité DMZ -> Trust doit être configurée sur le LNS pour permettre aux paquets des
utilisateurs de l'organisation de branche cherchant l'accès au serveur de réseau interne de passer; Untrust-->Local security policy doit également être configuré pour permettre au LAC et au LNS d’établir un tunnel L2TP.
Une fois le tunnel L2TP établi, lorsque le PC lance un appel sur le serveur, la direction du paquet est opposée à celle du serveur qui accède au PC, et nous n’avons pas besoin de préciser cette information.
Pour résumer, les stratégies de sécurité devant être configurées sur le LAC et le LNS dans diverses conditions sont présentées dans
le tableau 1-2, et nous devrions configurer les stratégies de sécurité qui correspondent le mieux aux conditions existantes.
Tableau 1-2 Sélection des stratégies de sécurité pour le LAC et le LNS en fonction des conditions existantes
Direction de la transaction | Dispositif | Zone de sécurité source | Zone de sécurité destination | Adresse source | Adresse de destination | Utilisé dans |
PC cherche à accéder au serveur | LAC | Local | Untrust | 1.1.1.1/32 | 1.1.1.2/32 | L2TP |
Trust | DMZ | 172.16.0.0/24 | 192.168.0.0/24 | * | ||
LNS | Untrust | Local | 1.1.1.1/32 | 1.1.1.2/32 | L2TP | |
DMZ | Trust | 172.16.0.0/24 | 192.168.0.0/24 | * | ||
Le serveur cherche à accéder au PC | LAC | DMZ | Trust | 192.168.0.0/24 | 172.16.0.0/24 | * |
LNS | Trust | DMZ | 192.168.0.0/24 | 172.16.0.0/24 | * | |
*: L'utilisation dans cette instance est liée au type de transaction et peut être configurée en fonction des circonstances réelles (par exemple: TCP, UDP et ICMP). | ||||||
Par conséquent, dans les scénarios L2TP utilisant la méthode de numérotation automatique LAC, les interfaces VT de LAC et de LNS doivent être ajoutées aux zones de sécurité, et les zones de sécurité auxquelles appartiennent les interfaces VT déterminent le sens du paquet dans le périphérique. Si une interface VT appartient à la zone de confiance, il n'est pas nécessaire de configurer une stratégie de sécurité interzone DMZ-Trust, mais cela ajoutera un risque de sécurité supplémentaire. Par conséquent, il est suggéré d’ajouter les interfaces VT à des zones de sécurité distinctes et de configurer la stratégie de sécurité la plus appropriée.
3. Enfin, l'action du filtrage de paquets par défaut est définie sur "deny".
Définissez l'action de filtrage de paquets par défaut interzone du LAC sur "deny":
[LAC] firewall packet-filter default deny all
Définissez l'action de filtrage de paquets interzone par défaut du LNS sur "Deny":
[LNS] firewall packet-filter default deny all
3 Résumé
Au cours des trois dernières sections, j'ai présenté trois types de VPN L2TP, et nous résumerons ces trois types de VPN L2TP
dans le tableau 1-3.
Tableau 1-3 Comparaison de trois types de VPN L2TP
Article | VPN initié par le client | VPN initié par NAS | VPN initié par LAC-Auto |
Méthode de négociation | Le client L2TP et le LNS négocient l'établissement d'un tunnel L2TP et d'une session L2TP, et établissent une connexion PPP. | L'utilisateur d'accès utilise un dial-up PPPoE pour déclencher l'établissement d'un tunnel L2TP et d'une session L2TP entre BAC et LNS et l'utilisateur d'accès et LNS négocient l'établissement d'une connexion PPP. | La BAC initie la composition et négocie l'établissement d'un tunnel L2TP et d'une session L2TP et d'une connexion PPP avec le LNS |
Relation tunnel et session | Un tunnel L2TP est établi entre chaque client L2TP et LNS et chaque tunnel porte uniquement une session L2TP et une connexion PPP. | Plusieurs tunnels L2TP peuvent exister entre un LAC et un LNS et un tunnel L2TP peut transporter plusieurs sessions L2TP. | Un tunnel L2TP permanent est établi entre BAC et LNS qui ne porte qu'une session L2TP permanente et une connexion PPP. |
Sécurité | Le LNS effectue l'authentification PPP du client L2TP (PAP ou CHAP) ; ce procédé offre une sécurité relativement élevée. | Le LAC authentifie les utilisateurs d'accès, puis le LNS effectue une authentification secondaire (facultative) des utilisateurs d'accès ; ceci offre la plus haute sécurité. | Le LAC n'effectue pas l'authentification des utilisateurs ; le LNS effectue l'authentification PPP (PAP ou CHAP) des utilisateurs configurés de BAC. Ceci assure une faible sécurité. |
Itinéraire de retour | Le LNS émettra automatiquement un itinéraire UNR, guidant le paquet de retour dans le tunnel L2TP ; la configuration manuelle n'est pas requise. | Le LNS émettra automatiquement un itinéraire UNR, guidant le paquet de retour dans le tunnel L2TP ; la configuration manuelle n'est pas requise. | Il est nécessaire de configurer manuellement le LNS de sorte que l'adresse de destination est la route statique du segment réseau, ou configurer la source NAT de la méthode -IP facile pour leLAC. |
Affectation d'adresse IP | Le LNS attribue une adresse IP au client. | Le LNS attribue une adresse IP au client. | Le LNS attribue une adresse IP pour l'interface VT de LAC. |
Notre regard sur les VPN L2TP est terminé. Il est important de noter qu'aucune des méthodes VPN L2TP ne prend en charge les fonctions de
cryptage. Par conséquent, des risques de sécurité sont présents pendant le processus de transmission de données via le tunnel. Comment ce
problème peut-il être résolu? La réponse sera claire après avoir étudié les VPN IPSec puissants, difficiles à configurer et hautement sécurisés.
Questions de Dr. WoW:
1. L'adresse source et l'adresse de destination de l'en-tête IP de la couche externe d'un paquet GRE sont-elles identiques à l'adresse IP de son
interface de tunnel?
2. Pour les VPN L2TP, quelle est la principale différence entre les scénarios pour lesquels les VPN initiés par le NAS et les VPN initiés par le
client devraient être utilisés?
3. Pour les VPN initiés par le client L2TP, il est généralement conseillé d'affecter les adresses du pool d'adresses et l'adresse du réseau HQ à
différents segments de réseau. Si nous voulons configurer les adresses du pool d'adresses et l'adresse réseau du siège social dans le même
segment de réseau, que devons-nous faire?
4. Dans les VPN initiés par le client L2TP, comment le LNS s'assure-t-il que les paquets en retour provenant du serveur interne du siège peuvent
entrer dans le tunnel L2TP et revenir au client L2TP?
5. Dans les VPN L2TP initiés par le NAS, quelles méthodes le LNS doit-il utiliser pour authentifier les utilisateurs d'accès?
Pour afficher la liste de tous les postes techniques de Dr. WoW, cliquez ici.
