Présentation du service de redirection HTTP
Le trafic des requêtes HTTP des abonnés est agrégé à partir des réseaux d’accès sur un routeur B-RAS (Broadband Remote Access Server), où le trafic HTTP peut être intercepté et redirigé vers un portail captif sur un périphérique externe. Le portail captif est souvent la page initiale qu’un abonné voit après s’être connecté à une session d’abonné. Le portail captif reçoit et gère également les requêtes HTTP adressées à des ressources Web non autorisées.
Par exemple, l’utilisateur peut être redirigé vers une page Web qui affiche le logo de l’entreprise et une politique d’utilisation du réseau, ou vers une page où l’abonné paie pour des services. Le portail captif fournit généralement des services d’authentification et d’autorisation pour les abonnés redirigés avant d’accorder l’accès à des serveurs protégés en dehors d’un jardin clos.
Un jardin clos, également connu sous le nom de liste d’autorisation, définit un groupe de serveurs où l’accès est fourni aux abonnés sans nouvelle autorisation via un portail captif. Ces jardins clos vous permettent d’augmenter vos revenus en commercialisant divers services auprès de vos clients.
Les liens typiques des jardins clos sont les suivants :
Services offerts par les fournisseurs, tels que la location d’automobiles
Portails de programmes de fidélisation ou d’entreprise pour les hôtels et motels
Services en chambre
Attractions locales et météo
Cette documentation utilise les termes service de redirection HTTP et service de livraison de contenu de portail captif (CPCD) de manière interchangeable .
Le service de redirection HTTP implémente un gestionnaire de données et un gestionnaire de contrôle et les enregistre avec les règles de service applicables aux applications HTTP. Ces règles sont analysées par le processus cpcdd sur le moteur de routage. Le gestionnaire de données applique les règles aux flux de données HTTP et gère la réécriture de l’adresse IP de destination ou l’envoi d’une réponse HTTP avec une URL de redirection préconfigurée. Le message de réponse inclut un code d’état HTTP. À partir de Junos OS version 17.3R1, le code d’état renvoyé dépend de la version HTTP utilisée par le client HTTP qui a envoyé la requête GET. Lorsque la version est supérieure à HTTP 1.0, le serveur de redirection renvoie le code d’état 307 (redirection temporaire). Lorsque la version est HTTP 1.0, le code d’état 302 (trouvé) est renvoyé. Dans les versions antérieures à la version 17.3R1, le serveur de redirection renvoie le code d’état 302, quelle que soit la version HTTP. Les deux codes indiquent au client HTTP d’utiliser l’URL d’origine, plutôt que l’URL de redirection, pour les requêtes GET ultérieures.
Lorsque la réponse à la requête HTTP est envoyée à l’abonné, l’URL d’origine est conservée en l’ajoutant éventuellement à la fin de l’URL de redirection configurée. La longueur maximale de l’URL de redirection, y compris l’URL d’origine ajoutée, est de 128 octets. À partir de la version 17.3R1 de Junos, la longueur maximale de l’URL de redirection est augmentée à 1360 octets et le serveur de redirection peut ajouter des informations supplémentaires sur l’abonné à l’URL de redirection. La longueur maximale s’applique indépendamment du fait que des informations sur l’abonné soient ajoutées ou non à l’URL. Pour ajouter des informations sur l’abonné, vous pouvez spécifier certains attributs d’abonné dans les VSA renvoyés dans le message d’acceptation d’accès RADIUS en réponse à la connexion de l’abonné ou dans un message de changement d’autorisation (CoA) RADIUS. Cela s’applique à la fois aux VSA Activer le service (26-65) et Désactiver le service (26-66). Les informations sur l’abonné sont extraites de la base de données de session de l’abonné.
Le gestionnaire de contrôle maintient une connexion avec le processus cpcdd sur le moteur de routage pour apprendre les modifications de configuration, telles que l’URL de redirection et l’adresse IP de réécriture de destination et de port. Pour obtenir des performances plus rapides, le gestionnaire de contrôle gère un cache des entités configurées pertinentes, telles que les URL, sur un concentrateur de port modulaire (MPC).
Les services de redirection HTTP sont pris en charge pour IPv4 et IPv6. Vous pouvez attacher un service de redirection HTTP ou un ensemble de services à une interface statique ou dynamique. Pour une gestion dynamique des abonnés, vous pouvez attacher des services HTTP ou des ensembles de services de manière dynamique lors de la connexion de l’abonné ou à l’aide d’un changement d’autorisation (CoA) RADIUS.
À partir de Junos OS version 17.2R1, il existe trois méthodes pour configurer les services de redirection HTTP. À partir de Junos OS version 19.3R2, la redirection HTTP peut également être configurée sur la carte de traitement des services MX-SPC3 si les services de nouvelle génération sont activés. Le Tableau 1 répertorie les méthodes prises en charge pour les services de redirection HTTP et les versions de Junos OS qui prennent en charge chaque méthode.
Nous vous recommandons d’utiliser Junos OS version 15.1 et versions ultérieures pour implémenter les services de redirection HTTP.
Méthode |
Versions de Junos OS prises en charge |
|
|---|---|---|
MS-DPC-based |
(Non pris en charge pour les services nouvelle génération sur la carte de services MX-SPC3) |
|
Statique |
Versions antérieures à la version 15.1 |
|
Convergence |
Non pris en charge |
|
MS-MPC-based |
(Non pris en charge pour les services nouvelle génération sur la carte de services MX-SPC3.) |
|
Statique |
À partir de Junos OS version 15.1 |
|
Convergence |
À partir de Junos OS version 17.2 |
|
MX-SPC3-based |
|
|
|
Statique |
À partir de Junos OS version 19.3R2 si les services de nouvelle génération sont activés sur la carte de services MX-SPC3. |
|
Convergence |
À partir de Junos OS version 19.3R2 si les services de nouvelle génération sont activés sur la carte de services MX-SPC3. |
Routing Engine-based |
|
|
Statique |
Toutes les versions de Junos OS |
|
Convergence |
À partir de Junos OS versions 16.1R4 et 17.2 |
|
Pour toutes les méthodes, vous configurez le walled garden en tant que filtre de service de pare-feu statique.
Portail captif basé sur des cartes de services
- Portail captif basé sur MS-MPC
- Portail captif basé sur une carte de services MX-SPC3
- Walled garden configuré en tant que filtre de service
Portail captif basé sur MS-MPC
À partir de Junos OS version 15.1R4, la seule combinaison carte de ligne et carte d’interface prenant en charge les services de redirection HTTP sur les routeurs MX Series est le concentrateur de ports modulaires multiservices (MS-MPC) avec une carte d’interface modulaire multiservices (MS-MIC). Cette combinaison offre une évolutivité améliorée et des performances élevées. Les MS-MIC et MS-MPC disposent de capacités de mémoire améliorées (16 Go pour MS-MIC, 32 Go par NPU pour MS-MPC) et de capacités de traitement améliorées. Les interfaces de services sur les MS-MPC et les MS-MIC sont identifiées dans la configuration par un préfixe ms- (par exemple, ms-1/2/1).
Dans cette documentation, le terme basé sur MS-MPC fait référence aux MPC sur lesquels les MS-MIC sont installés et aux MS-MIC seuls lorsqu’ils sont installés sur des routeurs MX Series qui n’acceptent pas les cartes de ligne.
Portail captif basé sur une carte de services MX-SPC3
À partir de Junos OS version 19.3R2, vous pouvez configurer les services de redirection HTTP si les services de nouvelle génération sont activés sur la carte de services MX-SPC3. Les interfaces de services sur les MX-SPC3 sont identifiées dans la configuration par un préfixe vms- (par exemple, vms-1/2/1).
Walled garden configuré en tant que filtre de service
Le flux de paquets pour un portail captif basé sur une carte de services diffère selon la façon dont vous configurez le jardin clos. Le trafic HTTP destiné aux serveurs situés dans le jardin clos n’est pas acheminé vers la carte de services. Toutefois, tout trafic HTTP destiné à l’extérieur du jardin clos est acheminé vers la carte de services.
Pour les demandes d’abonnés contenues dans le premier paquet de trafic de données, le système s’attend à ce que le proxy TCP génère un indicateur TCP SYN, ce qui oblige le gestionnaire de données à effectuer une recherche de règles et à appliquer ces règles aux flux de données HTTP.
Pour une condition de réécriture HTTP : si l’adresse IP de destination n’est pas fournie dans la stratégie, le gestionnaire de contrôle recherche l’adresse IP de destination.
Pour une condition de redirection HTTP, le proxy TCP est déclenché pour effectuer son établissement de liaison à trois voies.
Pour les paquets de requêtes HTTP.
Pour une condition de réécriture HTTP : le gestionnaire de contrôle utilise l’adresse IP de destination mise en cache et modifie le paquet de données.
Pour une condition de redirection HTTP : le gestionnaire de contrôle envoie une réponse HTTP 302 ou 307 avec une URL de redirection préconfigurée.
Portail captif basé sur un moteur de routage
Le portail captif basé sur le moteur de routage prend en charge un jardin clos comme filtre de service de pare-feu pour les services statiques et convergents. Dès que le trafic HTTP correspond aux règles définies dans le filtre du service de pare-feu, le trafic HTTP est envoyé au moteur de routage. Les interfaces de services sur le moteur de routage sont identifiées par un préfixe si- (par exemple, si-1/1/0). L’interface si- gère tout le trafic et les services de redirection et de réécriture pour le moteur de routage. L’interface si- doit être opérationnelle avec un état de jusqu’à pour activer et activer le service de diffusion de contenu de portail captif (CPCD). Une fois le service CPCD activé, toute modification de l’état de fonctionnement de l’interface si- n’affecte pas les services CPCD existants.
Provisionnement de services convergents pour les services de redirection HTTP
À partir de Junos OS version 17.2R1, le provisionnement de services convergents est pris en charge pour les portails captifs basés sur le moteur de routage et MS-MPC/MS-MIC. À partir de Junos OS version 19.3R2, le provisionnement de services convergents est également pris en charge pour les portails captifs basés sur des cartes de services MX-SPC3 si les services de nouvelle génération sont activés sur la carte de services MX-SPC3. Le provisionnement de services convergent signifie que vous pouvez configurer le provisionnement de services dans un profil dynamique. Vous pouvez spécifier des variables définies par l’utilisateur pour les services renseignés au moyen d’un VSA RADIUS ou d’un message de changement d’autorisation (CoA).
Par exemple, vous souhaiterez peut-être avoir une URL de redirection différente pour chaque abonné. Vous pouvez créer une variable redirect-url dans le profil dynamique, puis configurer une règle de service pour rediriger l’abonné correspondant vers $redirect-url. Lorsque RADIUS authentifie l’utilisateur, le VSA Activate-Service (26–65) fournit l’URL spécifique à cet utilisateur.
Provisionnement de services statiques pour les services de redirection HTTP
À partir de Junos OS version 17.4R1, le provisionnement de services statiques est pris en charge pour les portails captifs basés sur le moteur de routage et MS-MPC/MS-MIC. À compter de Junos OS version 19.3R2, le provisionnement de services statiques est également pris en charge pour les portails captifs basés sur MX-SPC3 si les services nouvelle génération sont activés sur la carte de services MX-SPC3. Le provisionnement de services statiques signifie que vous pouvez configurer le provisionnement de services dans un profil statique. Vous pouvez spécifier des variables définies par l’utilisateur (par exemple, http://portal.wifi.example.com/xx?wlanuseraddr=%subsc-ip%&nasaddr=%nas-ip%&acname=%ac -name%&url=%dest-url%&userlocation=%nas-port-id%&usermac=%mac-sa%& session-id=%sess-id%&username=%user-name%&wlanuseraddrv6=%subsc-ipv6%) pour les services renseignés au moyen d’un VSA RADIUS ou d’un message de changement d’autorisation (CoA).
Dans le CPCD statique, les attributs d’une URL de redirection ne sont pas envoyés dans les VSA Juniper Networks, Activate-Service (26-65) et Deactivate-Service (26-66). Vous pouvez le configurer comme indiqué dans l’exemple suivant :
captive-portal-content-delivery {
rule redirect {
match-direction input;
term t1 {
then {
redirect url;
}
}
}
}
Les jetons dans l’url tels que « subsc-ip », « nas-ip », « ac-name » doivent être spécifiés entre le symbole « % ». L’ordre des jetons n’a pas d’importance.
Voici une liste de jetons avec leur signification :
%subsc-ip% : adresse IP privée de l’abonné.
%nas-ip% : adresse IP BNG.
%ac-name% : il sera vide pour le BNG.
%dest-url% : URL de la requête d’origine.
%nas-port-id% : utilisé pour l’abonné. Ce paramètre doit inclure le nom de l’interface, pvlan et cvlan. Le nom de l’interface peut être un nom d’interface physique ou virtuelle. Par exemple, ge0/0/0 ou ae0. La plage pvlan et cvlan est de 14095
%mac-sa% : adresse MAC du client WLAN.
%sess-id% : ID de session de l’abonné.
%user-name% : nom d’utilisateur d’un abonné.
%subsc-ipv6% : adresse IPv6 de l’abonné (adresse IANA uniquement). Si l’adresse IANA n’est pas spécifiée pour l’abonné, ce champ sera vide.
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plate-forme et la version que vous utilisez. Utilisez l’Explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.