AWS Lambda n'atteint pas un proxy privé : vérifiez le chemin VPC
Utilisez l'adresse et le port de l'écouteur du proxy pour la première connexion VPC, avec le bon sens du groupe de sécurité et la vue DNS.
Lorsque Requests est configuré pour un proxy de transfert, Lambda se connecte d'abord à cet écouteur. Un site HTTPS sur 443 ne transforme pas un proxy qui écoute sur 3128 en port 443 du premier saut.
Lambda code → configured VPC path → proxy listener → destinationPour un proxy privé hébergé sur EC2, rattachez la fonction aux sous-réseaux et groupes de sécurité VPC prévus. Lambda gère les interfaces réseau de ce rattachement. D'autres sous-réseaux peuvent fonctionner si leur routage et leurs contrôles d'accès autorisent la connexion.
| Contrôle | Exigence du premier saut dans un montage routé directement au sein du même VPC |
|---|---|
| Groupe de sécurité de la fonction | TCP sortant vers l'écouteur du proxy |
| Groupe de sécurité du proxy | TCP entrant sur ce port depuis la source ou le groupe de sécurité prévu de la fonction |
| Processus du proxy | Écouteur sur l'interface joignable avec accès client autorisé |
Une règle entrante sur le seul groupe de la fonction ne peut pas autoriser cette connexion cliente sortante. Incluez les tables de routage et les ACL réseau du sous-réseau dans la vérification du chemin.
Pour un nom de proxy privé dans Route 53, vérifiez l'association de la zone hébergée au VPC et la configuration DNS, y compris enableDnsHostnames et enableDnsSupport. Une résolution réussie depuis l'ordinateur portable ne prouve pas la vue DNS de Lambda. Notez si le nom en échec est le proxy ou le site ; remplacer le site par une IP numérique ne corrige pas le nom du proxy.
Une fois ce saut fonctionnel, le proxy a besoin de sa propre route vers l'avant. Rattacher Lambda à un sous-réseau public n'attribue pas d'IP publique et ne fournit pas automatiquement un accès Internet direct ; décidez la sortie séparément pour les deux connexions.