AWS Lambda ne atingas privatan prokuron: kontrolu la VPC-vojon
Uzu la adreson kaj pordon de la prokura aŭskultanto por la unua VPC-konekto, kun la ĝusta direkto de la sekureca grupo kaj DNS-vido.
Kiam Requests estas agordita por antaŭa prokuro, Lambda unue konektiĝas al tiu aŭskultanto. HTTPS-retejo ĉe 443 ne igas prokuron aŭskultantan ĉe 3128 la pordon 443 de la unua salto.
Lambda code → configured VPC path → proxy listener → destinationPor privata prokuro gastigata en EC2, alligu la funkcion al la celataj VPC-subretoj kaj sekurecaj grupoj. Lambda administras retinterfacojn por tiu alligo. Diversaj subretoj povas funkcii kiam ilia enkursigo kaj alirkontroloj permesas la konekton.
| Kontrolo | Postulo de la unua salto en rekte enkursigita agordo en la sama VPC |
|---|---|
| Sekureca grupo de la funkcio | Eliranta TCP al la prokura aŭskultanto |
| Sekureca grupo de la prokuro | Eniranta TCP ĉe tiu pordo el la celata fonto aŭ sekureca grupo de la funkcio |
| Prokura procedo | Aŭskultanto ĉe la atingebla interfaco kun permesita klientaliro |
Enira regulo nur en la funkcia grupo ne povas rajtigi ĉi tiun elirantan klientkonekton. Inkluzivu enkursigajn tabelojn kaj retajn ACL-ojn de la subreto en la vojkontrolon.
Por privata prokura nomo en Route 53, kontrolu la VPC-asocion de la gastiga zono kaj la DNS-agordon, inkluzive de enableDnsHostnames kaj enableDnsSupport. Sukcesa serĉo de la tekkomputilo ne pruvas la DNS-vidon de Lambda. Notu ĉu la malsukcesa nomo estas la prokuro aŭ la retejo; ŝanĝi la retejon al numera IP ne riparas la prokuran nomon.
Post kiam ĉi tiu salto funkcias, la prokuro bezonas sian propran pluan vojon. Alligi Lambda al publika subreto ne asignas publikan IP nek aŭtomate provizas rektan interretan aliron; decidi la eliron aparte por ambaŭ konektoj.