AWS Lambda bereikt een private proxy niet: controleer het VPC-pad
Gebruik het adres en de poort van de proxy-listener voor de eerste VPC-verbinding, met de juiste richting van de beveiligingsgroep en DNS-weergave.
Als Requests is ingesteld voor een forward-proxy, verbindt Lambda eerst met die listener. Een HTTPS-site op 443 maakt van een proxy die op 3128 luistert niet de eerste-hop-poort 443.
Lambda code → configured VPC path → proxy listener → destinationVoor een private proxy op EC2 koppelt u de functie aan de bedoelde VPC-subnetten en beveiligingsgroepen. Lambda beheert de netwerkinterfaces voor die koppeling. Andere subnetten kunnen werken als hun routing en toegangscontrole de verbinding toestaan.
| Controle | Vereiste voor de eerste hop in een direct gerouteerde opzet binnen dezelfde VPC |
|---|---|
| Beveiligingsgroep van de functie | Uitgaande TCP naar de proxy-listener |
| Beveiligingsgroep van de proxy | Inkomende TCP op die poort vanaf de bedoelde bron of beveiligingsgroep van de functie |
| Proxyproces | Listener op de bereikbare interface met toegestane clienttoegang |
Een inkomende regel alleen op de functiegroep kan deze uitgaande clientverbinding niet toestaan. Neem routetabellen en netwerk-ACL's van het subnet op in de padcontrole.
Voor een private proxynaam in Route 53 verifieert u de VPC-koppeling van de gehoste zone en de DNS-configuratie, inclusief enableDnsHostnames en enableDnsSupport. Een geslaagde opzoeking vanaf de laptop bewijst de DNS-weergave van Lambda niet. Noteer of de mislukte naam de proxy of de website is; de website naar een numeriek IP veranderen is geen oplossing voor de proxynaam.
Als deze hop werkt, heeft de proxy zijn eigen verdere route nodig. Lambda aan een openbaar subnet koppelen geeft geen openbaar IP en levert niet automatisch directe internettoegang; bepaal uitgaand verkeer apart voor beide verbindingen.