AWS Lambda non raggiunge un proxy privato: controllate il percorso VPC
Usate l'indirizzo e la porta del listener del proxy per la prima connessione VPC, con la direzione corretta del gruppo di sicurezza e la vista DNS.
Con Requests configurato per un proxy di inoltro, Lambda si connette prima a quel listener. Un sito HTTPS sulla 443 non trasforma un proxy in ascolto sulla 3128 nella porta 443 del primo salto.
Lambda code → configured VPC path → proxy listener → destinationPer un proxy privato ospitato su EC2, collegate la funzione alle subnet e ai gruppi di sicurezza VPC previsti. Lambda gestisce le interfacce di rete di quel collegamento. Subnet diverse possono funzionare quando routing e controlli di accesso lo consentono.
| Controllo | Requisito del primo salto in una configurazione instradata direttamente nella stessa VPC |
|---|---|
| Gruppo di sicurezza della funzione | TCP in uscita verso il listener del proxy |
| Gruppo di sicurezza del proxy | TCP in ingresso su quella porta dall'origine o dal gruppo di sicurezza previsto della funzione |
| Processo del proxy | Listener sull'interfaccia raggiungibile con accesso client consentito |
Una regola in ingresso solo sul gruppo della funzione non può autorizzare questa connessione client in uscita. Includete tabelle di routing e ACL di rete della subnet nel controllo del percorso.
Per un nome di proxy privato in Route 53, verificate l'associazione della zona ospitata alla VPC e la configurazione DNS, inclusi enableDnsHostnames e enableDnsSupport. Una risoluzione riuscita dal portatile non dimostra la vista DNS di Lambda. Annotate se il nome che fallisce è il proxy o il sito; cambiare il sito con un IP numerico non corregge il nome del proxy.
Una volta che questo salto funziona, il proxy ha bisogno della propria rotta in avanti. Collegare Lambda a una subnet pubblica non assegna un IP pubblico né fornisce automaticamente accesso diretto a Internet; decidete l'uscita separatamente per entrambe le connessioni.