-
-
Configuration de Citrix ADC pour Citrix Virtual Apps and Desktops
-
Préférence de zone optimisée pour l'équilibrage de la charge du serveur global (GSLB)
-
Déploiement d'une plateforme de publicité numérique sur AWS avec Citrix ADC
-
Amélioration de l'analyse des flux de clics dans AWS à l'aide de Citrix ADC
-
Citrix ADC dans un cloud privé géré par Microsoft Windows Azure Pack et Cisco ACI
-
-
Déployer une instance de Citrix ADC VPX sur AWS
-
Installer une instance Citrix ADC VPX sur le cloud VMware sur AWS
-
Installer une instance Citrix ADC VPX sur des serveurs Microsoft Hyper-V
-
Installer une instance Citrix ADC VPX sur la plate-forme Linux-KVM
-
Provisionnement de l'appliance virtuelle Citrix ADC à l'aide d'OpenStack
-
Provisionnement de l'appliance virtuelle Citrix ADC à l'aide de Virtual Machine Manager
-
Configuration des appliances virtuelles Citrix ADC pour utiliser l'interface réseau SR-IOV
-
Configuration des appliances virtuelles Citrix ADC pour utiliser l'interface réseau PCI
-
Provisioning de l'appliance virtuelle Citrix ADC à l'aide du programme virsh
-
Provisioning de l'appliance virtuelle Citrix ADC avec SR-IOV, sur OpenStack
-
Configuration d'une instance Citrix ADC VPX sur KVM pour utiliser les interfaces hôtes OVS DPDK
-
Déployer une instance de Citrix ADC VPX sur AWS
-
Serveurs d'équilibrage de charge dans différentes zones de disponibilité
-
Haute disponibilité dans toutes les zones de disponibilité AWS
-
Déployer une paire VPX haute disponibilité avec des adresses IP privées dans différentes zones AWS
-
Ajout d'un service de mise à l'échelle automatique AWS back-end
-
Configurer une instance Citrix ADC VPX pour utiliser l'interface réseau SR-IOV
-
Configurer une instance Citrix ADC VPX pour utiliser la mise en réseau améliorée avec AWS ENA
-
Déployer une instance de Citrix ADC VPX sur Microsoft Azure
-
Architecture réseau pour les instances Citrix ADC VPX sur Microsoft Azure
-
Configurer plusieurs adresses IP pour une instance autonome Citrix ADC VPX
-
Configurer une configuration haute disponibilité avec plusieurs adresses IP et cartes réseau
-
Configurer une instance Citrix ADC VPX pour utiliser la mise en réseau accélérée Azure
-
Configurer les nœuds HA-INC à l'aide du modèle de haute disponibilité Citrix avec Azure ILB
-
Ajouter des paramètres de mise à l'échelle automatique Azure
-
Configurer GSLB sur une configuration haute disponibilité active en veille
-
Configurer des pools d'adresses (IIP) pour une appliance Citrix Gateway
-
Scripts PowerShell supplémentaires pour le déploiement Azure
-
Déployer une instance Citrix ADC VPX sur Google Cloud Platform
-
Déployer une paire haute disponibilité VPX sur Google Cloud Platform
-
Déployer une paire VPX haute disponibilité avec des adresses IP privées sur Google Cloud Platform
-
Ajouter un service de mise à l'échelle automatique GCP back-end
-
Prise en charge de la mise à l'échelle VIP pour l'instance Citrix ADC VPX sur GCP
-
-
Automatiser le déploiement et les configurations de Citrix ADC
-
Solutions pour les fournisseurs de services de télécommunication
-
Trafic de plan de contrôle d'équilibrage de charge basé sur les protocoles Diameter, SIP et SMPP
-
Utilisation de la bande passante à l'aide de la fonctionnalité de redirection de cache
-
Optimisation TCP de Citrix ADC
-
Authentification, autorisation et audit du trafic des applications
-
Fonctionnement de l'authentification, de l'autorisation et de l'audit
-
Composants de base de la configuration d'authentification, d'autorisation et d'audit
-
Autorisation de l'accès des utilisateurs aux ressources applicatives
-
Citrix ADC en tant que proxy du service de fédération Active Directory
-
Citrix Gateway sur site en tant que fournisseur d'identité pour Citrix Cloud
-
Prise en charge de la configuration de l'attribut de cookie SameSite
-
Configuration d'authentification, d'autorisation et d'audit pour les protocoles couramment utilisés
-
Résoudre les problèmes liés à l'authentification et à l'autorisation
-
-
-
Prise en charge de la configuration Citrix ADC dans la partition d'administration
-
Prise en charge de VXLAN pour les partitions d'administration
-
Prise en charge de SNMP pour les partitions d'administration
-
Prise en charge des journaux d'audit pour les partitions d'administration
-
Afficher les adresses PMAC configurées pour la configuration VLAN partagée
-
-
-
-
Configuration de l'expression de stratégie avancée : Mise en route
-
Expressions de stratégie avancées : utilisation de dates, d'heures et de nombres
-
Expressions de stratégie avancées : analyse des données HTTP, TCP et UDP
-
Expressions de stratégie avancées : analyse des certificats SSL
-
Expressions de stratégie avancées : adresses IP et MAC, débit, ID VLAN
-
Expressions de stratégie avancées : fonctions d'analyse de flux
-
Référence aux expressions - Expressions de stratégie avancées
-
Résumé d'exemples d'expressions et de stratégies de syntaxe par défaut
-
Didacticiel exemples de stratégies de syntaxe par défaut pour la réécriture
-
Migration des règles Apache mod_rewrite vers la syntaxe par défaut
-
-
-
Traduire l'adresse IP de destination d'une requête vers l'adresse IP d'origine
-
-
Prise en charge de la configuration de Citrix ADC dans un cluster
-
-
-
Groupes de nœuds pour les configurations spotted et striped partielles
-
Suppression du nœud d'un cluster déployé à l'aide de l'agrégation de liens de cluster
-
Surveillance des itinéraires pour les itinéraires dynamiques dans le cluster
-
Surveillance de la configuration du cluster à l'aide de MIB SNMP avec liaison SNMP
-
Surveillance des échecs de propagation des commandes dans un déploiement de cluster
-
Prise en charge de MSR pour les nœuds inactifs dans une configuration de cluster spotted
-
Liaison d'interface VRRP dans un cluster actif à nœud unique
-
Scénarios de configuration et d'utilisation du cluster
-
Migration d'une configuration HA vers une configuration de cluster
-
Interfaces communes pour le client et le serveur et interfaces dédiées pour le backplane
-
Commutateur commun pour le client, le serveur et le backplane
-
Commutateur commun pour le client et le serveur et commutateur dédié pour le backplane
-
Services de surveillance dans un cluster à l'aide de la surveillance des chemins
-
Opérations prises en charge sur des nœuds de cluster individuels
-
-
-
Configurer les enregistrements de ressources DNS
-
Créer des enregistrements MX pour un serveur d'échange de messagerie
-
Créer des enregistrements NS pour un serveur faisant autorité
-
Créer des enregistrements NAPTR pour le domaine des télécommunications
-
Créer des enregistrements PTR pour les adresses IPv4 et IPv6
-
Créer des enregistrements SOA pour les informations faisant autorité
-
Créer des enregistrements TXT pour contenir du texte descriptif
-
Configurer Citrix ADC en tant que résolveur de stub adapté à la sécurité sans validation
-
Prise en charge des trames Jumbo pour DNS pour gérer les réponses de grandes tailles
-
Configurer la mise en cache négative des enregistrements DNS
-
-
Équilibrage de charge globale des serveurs
-
Configurer les entités GSLB individuellement
-
Cas d'utilisation : Déploiement d'un groupe de services d'échelle automatique basé sur l'adresse IP
-
-
Remplacer le comportement de proximité statique en configurant les emplacements préférés
-
Configurer la sélection du service GSLB à l'aide du changement de contenu
-
Configurer GSLB pour les requêtes DNS avec les enregistrements NAPTR
-
Exemple de configuration parent-enfant complète à l'aide du protocole d'échange de mesures
-
-
Équilibrer la charge du serveur virtuel et des états de service
-
Protéger une configuration d'équilibrage de charge contre les défaillances
-
-
Configurer des serveurs virtuels d'équilibrage de charge sans session
-
Réécriture des ports et des protocoles pour la redirection HTTP
-
Insérer l'adresse IP et le port d'un serveur virtuel dans l'en-tête de requête
-
Utiliser une adresse IP source spécifiée pour la communication backend
-
Définir une valeur de délai d'attente pour les connexions client inactives
-
Utiliser un port source à partir d'une plage de ports spécifiée pour la communication backend
-
Configurer la persistance de l'IP source pour les communications backend
-
-
Paramètres avancés d'équilibrage de charge
-
Protéger les applications sur les serveurs protégés contre les surtensions de trafic
-
Activer le nettoyage des connexions de serveur virtuel et de service
-
Activer ou désactiver la session de persistance sur les services TROFS
-
Activer la vérification de l'état TCP externe pour les serveurs virtuels UDP
-
Maintenir la connexion client pour plusieurs demandes client
-
Utiliser l'adresse IP source du client lors de la connexion au serveur
-
Définir une limite de nombre de requêtes par connexion au serveur
-
Définir une valeur de seuil pour les moniteurs liés à un service
-
Définir une valeur de délai d'attente pour les connexions client inactives
-
Définir une valeur de délai d'attente pour les connexions au serveur inactif
-
Définir une limite sur l'utilisation de la bande passante par les clients
-
Configurer les moniteurs dans une configuration d'équilibrage de charge
-
Configurer l'équilibrage de charge pour les protocoles couramment utilisés
-
Cas d'utilisation 3 : Configurer l'équilibrage de charge en mode de retour direct du serveur
-
Cas d'utilisation 4 : Configurer les serveurs LINUX en mode DSR
-
Cas d'utilisation 5 : Configurer le mode DSR lors de l'utilisation de TOS
-
Cas d'utilisation 7 : Configurer l'équilibrage de charge en mode DSR à l'aide d'IP sur IP
-
Cas d'utilisation 8 : Configurer l'équilibrage de charge en mode à un bras
-
Cas d'utilisation 9 : Configurer l'équilibrage de charge en mode Inline
-
Cas d'utilisation 10 : Équilibrage de la charge des serveurs du système de détection d'intrusion
-
Cas d'utilisation 11 : Isolation du trafic réseau à l'aide de stratégies d'écoute
-
Cas d'utilisation 12 : Configurer XenDesktop pour l'équilibrage de charge
-
Cas d'utilisation 13 : Configurer XenApp pour l'équilibrage de charge
-
Cas d'utilisation 14 : Assistant ShareFile pour l'équilibrage de charge Citrix ShareFile
-
-
Configurer pour source de trafic de données Citrix ADC FreeBSD à partir d'une adresse SNIP
-
Déchargement et accélération SSL
-
Prise en charge du protocole TLSv1.3 tel que défini dans la RFC 8446
-
Suites de chiffrement disponibles sur les appliances Citrix ADC
-
Matrice de prise en charge des certificats de serveur sur l'appliance ADC
-
Prise en charge du module de sécurité matérielle du réseau Gemalto SafeNet
-
-
-
-
Authentification et autorisation pour les utilisateurs du système
-
Configuration des utilisateurs, des groupes d'utilisateurs et des stratégies de commande
-
Réinitialisation du mot de passe administrateur par défaut (nsroot)
-
Configuration de l'authentification des utilisateurs externes
-
Authentification basée sur la clé SSH pour les administrateurs Citrix ADC
-
Authentification à deux facteurs pour les utilisateurs système
-
-
-
Configuration d'un tunnel de connecteur CloudBridge entre deux centres de données
-
Configuration de CloudBridge Connector entre Datacenter et AWS Cloud
-
Configuration d'un tunnel de connecteur CloudBridge entre un centre de données et Azure Cloud
-
Configuration du tunnel Connector CloudBridge entre Datacenter et SoftLayer Enterprise Cloud
-
-
Points à prendre en considération pour une configuration de haute disponibilité
-
Restriction du trafic de synchronisation haute disponibilité à un VLAN
-
Configuration des nœuds haute disponibilité dans différents sous-réseaux
-
Limitation des basculements causés par les moniteurs de routage en mode non-INC
-
Comprendre le calcul de la vérification de l'état de haute disponibilité
-
Gestion des messages de pulsation haute disponibilité sur une appliance Citrix ADC
-
Suppression et remplacement d'un Citrix ADC dans une configuration haute disponibilité
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已动态机器翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.
Este artigo foi traduzido automaticamente.
这篇文章已经过机器翻译.放弃
Translation failed!
Extensions de protocole - cas d’utilisation
Les extensions de protocole peuvent être utilisées dans les cas d’utilisation suivants.
- Équilibrage de charge basé sur les messages (MBLB)
- Diffusion en continu
- Équilibrage de charge basé sur des jetons
- Persistance de l’équilibrage de charge
- Équilibrage de charge basé sur la connexion TCP
- Équilibrage de charge basé sur le contenu
- SSL
- Modifier le trafic
- Trafic d’origine vers le client ou le serveur
- Traitement des données sur l’établissement de connexion
Équilibrage de charge basé sur les messages
Les extensions de protocole prennent en charge l’équilibrage de charge basé sur les messages (MBLB), qui peut analyser n’importe quel protocole sur une appliance Citrix ADC et équilibrer la charge les messages de protocole arrivant sur une connexion client, c’est-à-dire distribuer les messages sur plusieurs connexions serveur. MBLB est réalisé par le code utilisateur qui analyse le flux de données TCP client.
Le flux de données TCP est transmis aux callbacks on_data pour les comportements client et serveur. Le flux de données TCP est disponible pour les fonctions d’extension via une interface de type chaîne Lua. Vous pouvez utiliser une API similaire à l’API de chaîne Lua pour analyser le flux de données TCP.
Les API utiles comprennent :
data:len()
data:find()
data:byte()
data:sub()
data:split()
Une fois que le flux de données TCP a été analysé dans un message de protocole, le code utilisateur obtient l’équilibrage de charge en envoyant simplement le message de protocole au contexte suivant disponible à partir du contexte passé au rappel on_data pour le client.
L’API ns.send () est utilisée pour envoyer des messages à d’autres modules de traitement. En plus du contexte de destination, l’API send prend le nom de l’événement et la charge utile facultative comme arguments. Il existe une correspondance un-à-un entre le nom de l’événement et les noms de fonction de rappel pour les comportements. Les rappels pour les événements sont appelés on_ <event_name>. Les noms de rappel utilisent uniquement des minuscules.
Par exemple, le client TCP et le serveur on_data callbacks sont des gestionnaires définis par l’utilisateur pour les événements nommés « DATA ». Pour envoyer le message de protocole entier dans un appel d’envoi, l’événement EOM (fin du message) est utilisé. EOM (fin du message), qui signifie la fin du message, signifie la fin du message de protocole vers le flux en aval du contexte LB, de sorte qu’une nouvelle décision d’équilibrage de charge est prise pour les données qui suivent ce message.
Le code d’extension peut parfois ne pas recevoir l’intégralité du message de protocole dans l’événement on_data. Dans ce cas, les données peuvent être conservées à l’aide de l’API ctxt:hold (). L’API Hold est disponible pour les contextes client TCP-et serveur-callback. Lorsque « hold with data » est appelé, les données sont stockées dans le contexte. Lorsque d’autres données sont reçues dans le même contexte, les données nouvellement reçues sont ajoutées aux données précédemment stockées et la fonction de rappel on_data est appelée à nouveau avec les données combinées.
Remarque : La méthode d’équilibrage de charge utilisée dépend de la configuration du serveur virtuel d’équilibrage de charge correspondant au contexte d’équilibrage de charge.
L’extrait de code suivant montre l’utilisation de l’API send pour envoyer le message de protocole analysé.
Exemple :
function client.on_data(ctxt, payload)
--
-- code to parse payload.data into protocol message comes here
--
-- sending the message to lb
ns.send(ctxt.output, "EOM", {data = message})
end -- client.on_data
function server.on_data(ctxt, payload)
--
-- code to parse payload.data into protocol message comes here
--
-- sending the message to client
ns.send(ctxt.output, "EOM", {data = message})
end -- server.on_data
Diffusion en continu
Dans certains scénarios, maintenir le flux de données TCP jusqu’à ce que l’ensemble du message de protocole soit collecté peut ne pas être nécessaire. En fait, il n’est pas conseillé à moins qu’il ne soit nécessaire. La conservation des données augmente l’utilisation de la mémoire sur l’appliance Citrix ADC et peut la rendre vulnérable aux attaques DDoS en épuisant la mémoire sur l’appliance Citrix ADC avec des messages de protocole incomplets sur de nombreuses connexions.
Les utilisateurs peuvent obtenir le streaming des données TCP dans les gestionnaires de rappel d’extension à l’aide de l’API send. Au lieu de conserver les données jusqu’à ce que l’ensemble du message soit collecté, les données peuvent être envoyées en morceaux. L’envoi de données à ctxt.output à l’aide de l’événement DATA envoie un message de protocole partiel. Il peut être suivi par d’autres événements DATA. Un événement EOM (fin du message) doit être envoyé pour marquer la fin du message de protocole. Le contexte d’équilibrage de charge en aval prend la décision d’équilibrage de charge sur les premières données reçues. Une nouvelle décision d’équilibrage de charge est prise après la réception du message EOM (fin du message).
Pour diffuser des données de message de protocole, envoyez plusieurs événements DATA suivis d’un événement EOM (fin du message). Les événements DATA contigus et l’événement EOM (fin du message) suivant sont envoyés à la même connexion serveur sélectionnée par décision d’équilibrage de charge pour le premier événement DATA de la séquence.
Pour un contexte d’envoi au client, les événements EOM (fin du message) et DATA sont effectivement les mêmes, car il n’y a pas de traitement spécial par le contexte client en aval pour les événements EOM (fin du message).
Équilibrage de charge basé sur des jetons
Pour les protocoles pris en charge en mode natif, une appliance Citrix ADC prend en charge une méthode d’équilibrage de charge basée sur un jeton qui utilise des expressions PI pour créer le jeton. Pour les extensions, le protocole n’est pas connu à l’avance, de sorte que les expressions PI ne peuvent pas être utilisées. Pour l’équilibrage de charge basé sur un jeton, vous devez définir le serveur virtuel d’équilibrage de charge par défaut pour utiliser la méthode d’équilibrage de charge USER_TOKEN et fournir la valeur de jeton à partir du code d’extension en appelant l’API send avec un champ user_token. Si la valeur du jeton est envoyée à partir de l’API send et que la méthode d’équilibrage de charge USER_TOKEN est configurée sur le serveur virtuel d’équilibrage de charge par défaut, la décision d’équilibrage de charge est prise en calculant un hachage basé sur la valeur du jeton. La longueur maximale de la valeur du jeton est de 64 octets.
add lb vserver v\_mqttlb USER\_TCP –lbMethod USER\_TOKEN
L’extrait de code de l’exemple suivant utilise une API send pour envoyer une valeur de jeton LB.
Exemple :
-- send the message to lb
-- user_token is set to do LB based on clientID
ns.send(ctxt.output, "EOM", {data = message,
user_token = token_info})
Persistance de l’équilibrage de charge
La persistance de l’équilibrage de charge est étroitement liée à l’équilibrage de charge basé sur un jeton. Les utilisateurs doivent pouvoir calculer par programmation la valeur de session de persistance et l’utiliser pour la persistance d’équilibrage de charge. L’API send est utilisée pour envoyer des paramètres de persistance. Pour utiliser la persistance de l’équilibrage de charge, vous devez définir le type de persistance USERSESSION sur le serveur virtuel d’équilibrage de charge par défaut et fournir un paramètre de persistance à partir du code d’extension en appelant l’API send avec un champ user_session. La longueur maximale de la valeur du paramètre de persistance est de 64 octets.
Si vous avez besoin de plusieurs types de persistance pour un protocole personnalisé, vous devez définir des types de persistance utilisateur et les configurer. Les noms des paramètres utilisés pour configurer les serveurs virtuels sont déterminés par l’implémenteur du protocole. La valeur configurée d’un paramètre est également disponible pour le code d’extension.
L’interface de ligne de commande et l’extrait de code suivants montrent l’utilisation d’une API d’envoi pour prendre en charge la persistance de l’équilibrage de charge. La liste des codes dans la section Liste de codes pour mqtt.lua illustre également l’utilisation du champ user_session.
Pour la persistance, vous devez spécifier le type de persistance USERSESSION sur le serveur virtuel d’équilibrage de charge et transmettre la valeur user_session à partir de l’API ns.send.
add lb vserver v\_mqttlb USER\_TCP –persistencetype USERSESSION
Envoyez le message MQTT à l’équilibreur de charge, avec le champ user_session défini sur ClientID dans la charge utile.
Exemple :
-- send the data so far to lb
-- user_session is set to clientID as well (it will be used to persist session)
ns.send(ctxt.output, “DATA”, {data = data, user_session = clientID})
Équilibrage de charge basé sur la connexion TCP
Pour certains protocoles, MBLB peut ne pas être nécessaire. Au lieu de cela, vous pouvez avoir besoin d’équilibrage de charge basé sur la connexion TCP. Par exemple, le protocole MQTT doit analyser la partie initiale du flux TCP pour déterminer le jeton d’équilibrage de charge. Et, tous les messages MQTT sur la même connexion TCP doivent être envoyés à la même connexion serveur.
L’équilibrage de charge basé sur la connexion TCP peut être réalisé en utilisant l’API send avec uniquement des événements DATA et en n’envoyant aucune EOM (fin du message). Ainsi, le contexte d’équilibrage de charge en aval basera la décision d’équilibrage de charge sur les données reçues en premier et envoie toutes les données suivantes à la même connexion serveur sélectionnée par la décision d’équilibrage de charge.
En outre, certains cas d’utilisation peuvent nécessiter la possibilité de contourner la gestion des extensions après que la décision d’équilibrage de charge a été prise. Le contournement des appels d’extension se traduit par de meilleures performances, car le trafic est traité uniquement par du code natif. Le contournement peut être fait en utilisant l’API ns.pipe(). Un appel au code d’extension de l’API pipe() peut connecter le contexte d’entrée à un contexte de sortie. Après l’appel à pipe(), tous les événements provenant du contexte d’entrée vont directement dans le contexte de sortie. Effectivement, le module à partir duquel l’appel pipe() est effectué est retiré du pipeline.
L’extrait de code suivant montre la diffusion en continu et l’utilisation de l’API pipe() pour contourner un module. La liste de code dans la section Liste de codes pour mqtt.lua illustre également comment faire le streaming et l’utilisation de pipe() API pour contourner le module pour le reste du trafic sur la connexion.
Exemple :
-- send the data so far to lb
ns.send(ctxt.output, "DATA", {data = data,
user_token = clientID})
-- pipe the subsequent traffic to the lb - to bypass the client on_data handler
ns.pipe(ctxt.input, ctxt.output)
Équilibrage de charge basé sur le contenu
Pour les protocoles natifs, la fonctionnalité de commutation de contenu comme pour les extensions de protocole est prise en charge. Avec cette fonctionnalité, au lieu d’envoyer les données à l’équilibrage de charge par défaut, vous pouvez envoyer les données à l’équilibreur de charge sélectionné.
La fonction de commutation de contenu pour les extensions de protocole est obtenue à l’aide de l’API ctxt:lb_connect (<lbname>
). Cette API est disponible pour le contexte client TCP. À l’aide de cette API, le code d’extension peut obtenir un contexte d’équilibrage de charge correspondant à un serveur virtuel d’équilibrage de charge déjà configuré. Vous pouvez ensuite utiliser l’API send avec le contexte d’équilibrage de charge ainsi obtenu.
Le contexte lb peut être NULL parfois :
- Le serveur virtuel n’existe pas
- Le serveur virtuel n’est pas du type de protocole utilisateur
- L’état du serveur virtuel n’est pas UP
- Le serveur virtuel est un serveur virtuel utilisateur, pas un serveur virtuel d’équilibrage de charge
Si vous supprimez le serveur virtuel d’équilibrage de charge cible lorsqu’il est en cours d’utilisation, toutes les connexions associées à ce serveur virtuel d’équilibrage de charge sont réinitialisées.
L’extrait de code suivant montre l’utilisation de l’API lb_connect (). Le code mappe l’ID client aux noms de serveurs virtuels d’équilibrage de charge (lbname) à l’aide de la table Lua lb_map, puis obtient le contexte LB pour lbname à l’aide de lb_connect (). Et enfin envoie au contexte LB en utilisant l’API send.
local lb_map = {
["client1*"] = "lb_1",
["client2*"] = "lb_2",
["client3*"] = "lb_3",
["client4*"] = "lb_4"
}
-- map the clientID to the corresponding LB vserver and connect to it
for client_pattern, lbname in pairs(lb_map) do
local match_idx = string.find(clientID, client_pattern)
if (match_idx == 1) then
lb_ctxt = ctxt:lb_connect(lbname)
if (lb_ctxt == nil) then
error("Failed to connect to LB vserver: " .. lbname)
end
break
end
end
if (lb_ctxt == nil) then
-- If lb context is NULL, the user can raise an error or send data to default LB
error("Failed to map LB vserver for client: " .. clientID)
end
-- send the data so far to lb
ns.send(lb_ctxt, "DATA", {data = data}
SSL
SSL pour les protocoles utilisant des extensions est pris en charge de la manière dont SSL pour les protocoles natifs est pris en charge. En utilisant le même code d’analyse pour créer des protocoles personnalisés, vous pouvez créer une instance de protocole sur TCP ou sur SSL qui peut ensuite être utilisée pour configurer les serveurs virtuels. De même, vous pouvez ajouter des services utilisateur via TCP ou SSL.
Pour plus d’informations, veuillez consulter Configuration du déchargement SSL pour MQTT et Configuration du déchargement SSL pour MQTT avec chiffrement de bout en bout.
Multiplexage de connexion serveur
Parfois, le client envoie une requête à la fois et envoie la demande suivante uniquement après réception de la réponse de la première requête du serveur. Dans ce cas, la connexion au serveur peut être réutilisée pour d’autres connexions clientes et pour le message suivant sur la même connexion, après l’envoi de la réponse au client. Pour permettre la réutilisation de la connexion serveur par d’autres connexions client, vous devez utiliser l’API ctxt : reuse_server_connection() sur le contexte côté serveur.
Remarque : Cette API est disponible dans Citrix ADC 12.1 build 49.xx et versions ultérieures.
Modifier le trafic
Pour modifier les données de la demande ou de la réponse, vous devez utiliser la fonction de réécriture native qui utilise une expression PI de stratégie avancée. Étant donné que vous ne pouvez pas utiliser d’expressions PI dans les extensions, vous pouvez utiliser les API suivantes pour modifier les données d’un flux TCP.
data:replace(offset, length, new_string)
data:insert(offset, new_string)
data:delete(offset, length)
data:gsub(pattern, replace [,n]))
L’extrait de code suivant montre l’utilisation de l’API replace().
-- Get the offset of the pattern, we want to replace
local old_pattern = “pattern to repalace”
local old_pattern_length = old_pattern:len ()
local pat_off, pat_end = data:find(old_pattern)
— le motif n'est pas présent
if (not pat_off) then
goto send_data
fin
-- If the data we want to modify is not completely present, then
-- wait for more data
if (not pat_end) then
ctxt:hold(data)
data = nil
goto done
fin
data:replace(pat_off, old_pattern_length, “new pattern”)
::send_data::
ns.send(ctxt.output, “EOM”, {data = data})
::done::
L’extrait de code suivant montre l’utilisation de l’API insert().
data:insert(5, “pattern to insert”)
L’extrait de code suivant montre l’utilisation de l’API insert (), lorsque nous voulons insérer après ou avant un motif :
-- Get the offset of the pattern, after or before which we want to insert
local pattern = “pattern after/before which we need to insert”
local pattern_length = pattern:len()
local pat_off, pat_end = data:find(pattern)
— le motif n'est pas présent
if (not pat_off) then
goto send_data
fin
-- If the pattern after which we want to insert is not
-- completely present, then wait for more data
if (not pat_end) then
ctxt:hold(data)
data = nil
goto done
fin
-- Insert after the pattern
data:insert(pat_end + 1, “pattern to insert”)
-- Insert before the pattern
data:insert(pat_off, “pattern to insert”)
::send_data::
ns.send(ctxt.output, “EOM”, {data = data})
::done::
L’extrait de code suivant montre l’utilisation de l’API delete ().
— Récupère le décalage du motif, nous voulons supprimer
local delete_pattern = “pattern to delete”
local delete_pattern_length = delete_pattern:len()
local pat_off, pat_end = data:find(old_pattern)
— le motif n'est pas présent
if (not pat_off) then
goto send_data
fin
-- If the data we want to delete is not completely present,
-- then wait for more data
if (not pat_end) then
ctxt:hold(data)
data = nil
goto done
fin
données:delete (pat_off, delete_pattern_length)
::send_data::
ns.send(ctxt.output, “EOM”, {data = data})
::done::
L’extrait de code suivant montre l’utilisation de l’API gsub().
— Remplace toutes les instances du modèle par la nouvelle chaîne
data:gsub(“old pattern”, “new string”)
— Remplace seulement 2 instances de « ancien modèle »
data:gsub(“old pattern”, “new string”, 2)
— Insérer new_string avant toutes les instances de « http »
data:gsub(“input data”, “(http)”, “new_string%1”)
— Insérer new_string après toutes les instances de « http »
data:gsub(“input data”, “(http)”, “%1new_string”)
— Insérer new_string avant seulement 2 instances de « http »
data:gsub(“input data”, “(http)”, “new_string%1”, 2)
Remarque : Cette API est disponible dans Citrix ADC 12.1 build 50.xx et versions ultérieures.
Trafic d’origine vers le client ou le serveur
Vous pouvez utiliser l’API ns.send () pour envoyer des données provenant du code d’extension à un client et à un serveur principal. Pour envoyer ou recevoir une réponse directement avec un client, à partir du contexte client, vous devez utiliser ctxt.client comme cible. Pour envoyer ou recevoir une réponse directement avec un serveur back-end à partir d’un contexte de serveur, vous devez utiliser ctxt.server comme cible. Les données de la charge utile peuvent être des données de flux TCP ou une chaîne Lua.
Pour arrêter le traitement du trafic sur une connexion, vous pouvez utiliser l’API ctxt:close () à partir du client ou du contexte du serveur. Cette API ferme la connexion côté client ou toute connexion serveur qui lui est liée.
Lorsque vous appelez l’API ctxt:close (), le code d’extension envoie le paquet TCP FIN aux connexions client et serveur et si plus de données sont reçues du client ou du serveur sur cette connexion, l’appliance réinitialise la connexion.
L’extrait de code suivant montre l’utilisation des API ctxt.client et ctxt:close().
-- If the input packet is not MQTT CONNECT type, then
-- send some error response to the client.
function client.on_data(ctxt, payload)
données locales = payload.data
local offset = 1
local msg_type = 0
local error_response = “Missing MQTT Connect packet.”
byte = data:byte(offset)
msg_type = bit32.rshift(byte, 4)
if (msg_type ~= 1) then
-- Send the error response
ns.send(ctxt.client, “DATA”, {data = error_response})
-- Since error response has been sent, so now close the connection
ctxt:close()
fin
L’extrait de code suivant montre l’exemple lorsque l’utilisateur peut injecter les données dans le flux de trafic normal.
-- After sending request, send some log message to the server.
function client.on_data(ctxt, payload)
données locales = payload.data
local log_message = “client id : “..data:sub(3, 7)..” user name : “ data:sub(9, 15)
-- Send the request we get from the client to backend server
ns.send(ctxt.output, “DATA”, {data = data})
After sending the request, also send the log message
ns.send(ctxt.output, “DATA”, {data = log_message”})
fin
L’extrait de code suivant montre l’utilisation de l’API ctxt.to_server.
-- If the HTTP response status message is “Not Found”,
-- then send another request to the server.
function server.on_data(ctxt, payload)
données locales = payload.data
local request “GET /default.html HTTP/1.1\r\n\r\n”ss
local start, end = data:find(“Not Found”)
if (start) then
— Envoie une autre requête au serveur
ns.send(ctxt.server, “DATA”, {data = request})
fin
Remarque : Cette API est disponible dans Citrix ADC 12.1 build 50.xx et versions ultérieures.
Traitement des données sur l’établissement de connexion
Il peut y avoir un cas d’utilisation où vous souhaitez envoyer des données à l’établissement de connexion (lorsque le ACK final est reçu). Par exemple, dans le protocole proxy, vous pouvez souhaiter envoyer les adresses IP source et de destination du client et les ports au serveur principal de l’établissement de connexion. Dans ce cas, vous pouvez utiliser le gestionnaire de rappel client.init() pour envoyer les données sur l’établissement de la connexion.
L’extrait de code suivant montre l’utilisation du callback client.init() :
-- Send a request to the next processing context
-- on the connection establishment.
function client.init(ctxt)
local request “PROXY TCP4” + ctxt.client.ip.src.to_s + “ “ + ctxt.client.ip.dst.to_s + “ “ + ctxt.client.tcp.srcport + “ “ + ctxt.client.tcp.dstport
— Envoie une autre requête au serveur
ns.send(ctxt.output, “DATA”, {data = request})
fin
Remarque : Cette API est disponible dans Citrix ADC 13.0 build xx.xx et versions ultérieures.
Partager
Partager
Dans cet article
- Équilibrage de charge basé sur les messages
- Diffusion en continu
- Équilibrage de charge basé sur des jetons
- Persistance de l’équilibrage de charge
- Équilibrage de charge basé sur la connexion TCP
- Équilibrage de charge basé sur le contenu
- SSL
- Multiplexage de connexion serveur
- Modifier le trafic
- Trafic d’origine vers le client ou le serveur
- Traitement des données sur l’établissement de connexion
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select Do Not Agree to exit.