Redirigez les requêtes sortantes de votre client vers l'adresse du proxy Egress Proxy Gateway (EPG) afin d'acheminer le trafic HTTP et HTTPS par une sortie Internet unique. EPG fournit une adresse IP de sortie fixe, un contrôle d'accès granulaire par nom de domaine ou URL, ainsi qu'un accès flexible entre VPC, éliminant ainsi la charge opérationnelle liée à la gestion d'un cluster de proxy auto-géré.
Différences entre les écouteurs HTTP et HTTPS
Lorsque vous créez une instance EPG, un écouteur HTTP et un écouteur HTTPS sont automatiquement provisionnés, par exemple HTTP:1080 et HTTPS:443. Ces deux écouteurs se distinguent par le chiffrement du canal de communication entre le client et EPG. L'écouteur HTTP offre un canal en texte clair, tandis que l'écouteur HTTPS propose un canal chiffré via TLS.
|
Comparaison |
Écouteur HTTP |
Écouteur HTTPS |
|
Chiffrement du canal proxy |
Transmission en texte clair. La sécurité du canal repose sur l'environnement réseau interne du VPC. |
Chiffrement TLS. Également appelé proxy HTTPS (Proxy over TLS) ou accès client TLS dans ce produit. |
|
Scénarios d'utilisation |
Méthode d'accès la plus courante. Dans la plupart des cas, le réseau interne du VPC est considéré comme fiable, rendant inutile le chiffrement supplémentaire du canal proxy. |
Scénarios zero trust exigeant le chiffrement du canal proxy lui-même pour des raisons de conformité. |
|
Configuration de l'adresse du proxy |
Définissez-la sous la forme |
Définissez-la sous la forme |
|
Prérequis côté client |
Aucune exigence particulière. |
Le client doit prendre en charge les proxys HTTPS. Certaines versions anciennes d'outils ou de bibliothèques HTTP ne le permettent pas. Vérifiez la compatibilité du client avant la connexion. |
L'accès client TLS et l'interception TLS sont deux concepts indépendants. Ne les confondez pas. Vous pouvez les activer séparément sans qu'ils n'aient d'incidence l'un sur l'autre.
Accès client TLS : utilise l'écouteur HTTPS pour chiffrer la communication proxy entre le client et EPG, protégeant ainsi le canal proxy lui-même. Cette méthode est couramment employée dans les scénarios zero trust.
Interception TLS : détermine si EPG déchiffre le trafic HTTPS circulant entre le client et le serveur de destination. Lorsque cette fonction est activée, EPG agit en tant que proxy intermédiaire et utilise un certificat d'autorité de certification (CA) privé pour déchiffrer le trafic en texte clair, permettant ainsi un contrôle et une auditabilité du contenu au niveau de la couche application (couche 7).
Prérequis
Vous avez créé une instance EPG dotée d'un écouteur HTTP et d'un écouteur HTTPS, et vous avez créé le pool d'adresses par défaut.
Les procédures décrites dans cette rubrique utilisent un proxy Internet à titre d'exemple. Vous devez associer au moins une adresse IP élastique (EIP) disponible à chaque zone du pool d'adresses par défaut, afin que l'instance EPG puisse acheminer les requêtes vers Internet.
Vous avez déployé une application dans le VPC auquel appartient l'instance EPG, et cette application doit accéder aux services Internet via le proxy EPG.
Configurer l'accès via le proxy
EPG fonctionne comme un proxy explicite et ne prend pas en charge l'interception transparente du trafic. Le client doit explicitement rediriger ses requêtes sortantes vers l'adresse du proxy EPG. Après avoir appliqué les règles de contrôle, EPG transfère les requêtes vers le service de destination. Si vous utilisez EPG pour la première fois, consultez le guide Démarrage rapide pour commencer.
Étape 1 : Obtenir l'adresse du proxy
Dans l'onglet Basic Information de la page des détails de l'instance, consultez le DNS domain name de l'instance, qui suit un format tel que epg-xxx.cn-shanghai.epg.aliyuncs.com. Ce nom de domaine constitue l'adresse du proxy utilisée par le client. Lorsque l'instance est déployée sur plusieurs zones, ce nom de domaine résout vers les nœuds proxy de chaque zone.
Étape 2 : Configurer les variables d'environnement du proxy
Cette étape illustre la configuration avec l'écouteur HTTP (canal proxy en texte clair). Définissez les variables http_proxy et https_proxy avec l'adresse de l'écouteur HTTP d'EPG, par exemple http://<votre nom de domaine EPG>:1080. Les termes http et https présents dans les noms des variables indiquent le protocole de destination (service HTTP ou HTTPS cible), et non le protocole utilisé par le canal proxy.
Pour chiffrer le canal de communication entre le client et EPG (scénarios zero trust), utilisez plutôt l'écouteur HTTPS et définissez l'adresse sous la forme https://<votre nom de domaine EPG>:443. Assurez-vous que le client prend en charge les proxys HTTPS (certaines versions anciennes d'outils ou de bibliothèques HTTP ne le permettent pas).
Remplacez <votre nom de domaine EPG> par le nom de domaine DNS de votre instance EPG, suivant un format tel que epg-xxx.cn-shanghai.epg.aliyuncs.com.
Accès depuis ECS
L'exemple ci-dessous utilise Alibaba Cloud Linux 4 (le shell par défaut est bash).
Les commandes suivantes écrivent la configuration du proxy dans le fichier /etc/profile.d/epg-proxy.sh afin que celle-ci reste effective après les redémarrages système et lors des nouvelles sessions de connexion.
sudo tee /etc/profile.d/epg-proxy.sh > /dev/null <<'EOF'
# The proxy port points to the HTTP listener port (such as 1080) for both http_proxy and https_proxy
export http_proxy=http://<your EPG domain name>:1080
export https_proxy=http://<your EPG domain name>:1080
# Internal networks, localhost, and Alibaba Cloud internal services bypass the proxy. For the meaning of each CIDR block, see "no_proxy recommendations" below.
export no_proxy=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10,100.100.100.200,aliyuncs.com
# Both the lowercase and the uppercase variables are set for compatibility with different tools
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export NO_PROXY="$no_proxy"
EOF
# Apply the configuration to the current session immediately. New logon sessions load it automatically.
source /etc/profile.d/epg-proxy.sh
Accès depuis les conteneurs (Docker/Kubernetes)
Dans les environnements conteneurisés, il est recommandé d'injecter les variables d'environnement du proxy via l'image ou la couche d'orchestration :
-
Dans un Dockerfile, déclarez les variables à l'aide de
ENV, ou transmettez-les lors de l'exécution dedocker runen utilisant l'option-e.# Docker: inject the proxy environment variables when you run the container (both the lowercase and the uppercase variables are set for compatibility with different tools) docker run \ -e http_proxy=http://<your EPG domain name>:1080 \ -e https_proxy=http://<your EPG domain name>:1080 \ -e no_proxy=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10,100.100.100.200,aliyuncs.com \ -e HTTP_PROXY=http://<your EPG domain name>:1080 \ -e HTTPS_PROXY=http://<your EPG domain name>:1080 \ -e NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10,100.100.100.200,aliyuncs.com \ your-image -
Dans Kubernetes, configurez les variables dans le champ
envdu conteneur au sein d'un pod ou d'un Deployment. Vous pouvez également gérer ces variables de manière centralisée via un ConfigMap.# Kubernetes: inject the proxy environment variables in the container env field (both the lowercase and the uppercase variables are set for compatibility with different tools) spec: containers: - name: your-app image: your-image env: - name: http_proxy value: "http://<your EPG domain name>:1080" - name: https_proxy value: "http://<your EPG domain name>:1080" - name: no_proxy value: "localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10,100.100.100.200,aliyuncs.com" - name: HTTP_PROXY value: "http://<your EPG domain name>:1080" - name: HTTPS_PROXY value: "http://<your EPG domain name>:1080" - name: NO_PROXY value: "localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10,100.100.100.200,aliyuncs.com"
Le préfixe de protocole et le port de l'adresse du proxy doivent correspondre. Utilisez http://<votre nom de domaine EPG>:1080 pour l'écouteur HTTP et https://<votre nom de domaine EPG>:443 pour l'écouteur HTTPS. En cas de discordance entre le préfixe de protocole et le port, la connexion au proxy échouera. Par exemple, l'erreur Proxy CONNECT aborted peut survenir.
Étape 3 : Vérifier l'efficacité du proxy
Envoyez une requête de test pour confirmer que le trafic sortant du client est bien acheminé via le proxy EPG.
# Verify HTTP access to the Internet. An HTTP status code of 301 indicates success.
curl -I --max-time 15 http://www.alibabacloud.com/help
# Verify HTTPS access to the Internet. An HTTP status code of 302 indicates success.
curl -I --max-time 15 https://www.alibabacloud.com/help
# The following example uses an ECS instance in the Shanghai region to verify that no_proxy takes effect. Alibaba Cloud internal services must be accessed directly. An XML error response indicates that the direct connection succeeds.
curl --max-time 15 https://ecs.cn-shanghai.aliyuncs.com
Configurer le proxy dans le code
Supprimer la configuration du proxy
ECS
-
Désactiver temporairement le proxy (session actuelle uniquement) : Effacez les variables d'environnement du proxy dans le shell actuel. Les nouvelles sessions de connexion rechargeront ces variables.
unset http_proxy https_proxy no_proxy HTTP_PROXY HTTPS_PROXY NO_PROXY -
Supprimer définitivement le proxy : Supprimez le script de persistance et effacez les variables d'environnement dans la session actuelle, ou reconnectez-vous. Les nouvelles sessions ne chargeront plus la configuration du proxy.
sudo rm /etc/profile.d/epg-proxy.sh unset http_proxy https_proxy no_proxy HTTP_PROXY HTTPS_PROXY NO_PROXY
Conteneurs/Kubernetes
Supprimez les variables d'environnement du proxy injectées par l'image ou la couche d'orchestration, notamment http_proxy, https_proxy et no_proxy, ainsi que leurs équivalents en majuscules. La modification prendra effet après la reconstruction de l'image ou le redéploiement de la charge de travail.
Code
Cessez de transmettre le paramètre proxies lors de l'envoi des requêtes afin de rétablir les connexions directes. Si vous utilisiez auparavant des variables d'environnement telles que no_proxy pour contrôler le périmètre du proxy, effacez-les également.
Recommandations pour no_proxy
La variable no_proxy spécifie les adresses auxquelles le client accède directement, sans passer par le proxy EPG. Cela évite que le trafic destiné à localhost, aux réseaux internes et aux services internes d'Alibaba Cloud ne soit involontairement routé via le proxy. La liste suivante décrit les types courants. Configurez-les en fonction de votre périmètre de proxy réel :
Adresses localhost :
localhostet127.0.0.1Plages CIDR privées internes :
10.0.0.0/8,172.16.0.0/12et192.168.0.0/16Plage CIDR réservée d'Alibaba Cloud :
100.64.0.0/10(plage d'adresses partagée utilisée par les services internes d'Alibaba Cloud)Service de métadonnées d'Alibaba Cloud :
100.100.100.200(si le trafic est acheminé via le proxy, l'obtention des métadonnées d'instance et des identifiants temporaires RAM échouera)Services internes d'Alibaba Cloud :
aliyuncs.com(y compris ses sous-domaines, tels queecs.cn-shanghai.aliyuncs.com. Notez qu'il ne s'agit pas dealiyun.com.)
Les règles de correspondance pour no_proxy varient selon les clients (par exemple, prise en charge ou non des sous-domaines et des blocs CIDR). Adaptez-vous au comportement du client que vous utilisez.
Notes d'utilisation
EPG prend uniquement en charge le protocole de proxy HTTP. Lors de la configuration, utilisez une adresse de proxy commençant par
http://ouhttps://. Les méthodes de proxy SOCKS, telles quesocks5://, ne sont pas prises en charge.
Quota
Pour augmenter un quota, contactez votre responsable commercial.
|
Quota |
Valeur par défaut |
Limite supérieure |
|
Nombre de ports d'écoute par instance |
2 |
50 |