AWS Lambda не можа дасягнуць прыватнага проксі: праверце шлях VPC
Для першага злучэння VPC выкарыстоўвайце адрас і порт праксі-слухача, з правільным кірункам групы бяспекі і DNS-прадстаўленнем.
Калі Requests наладжаны на прамы проксі, Lambda спачатку злучаецца з гэтым слухачом. Сайт HTTPS на 443 не ператварае проксі, які слухае на 3128, у порт першага кроку 443.
Lambda code → configured VPC path → proxy listener → destinationДля прыватнага проксі на EC2 далучыце функцыю да патрэбных падсетак і груп бяспекі VPC. Lambda кіруе сеткавымі інтэрфейсамі для гэтага далучэння. Розныя падсеткі могуць працаваць, калі іх маршрутызацыя і кантроль доступу дазваляюць злучэнне.
| Кантроль | Патрабаванне першага кроку ў наладзе з прамой маршрутызацыяй у тым жа VPC |
|---|---|
| Група бяспекі функцыі | Зыходны TCP да слухача проксі |
| Група бяспекі проксі | Уваходны TCP на гэтым порце з патрэбнай крыніцы або групы бяспекі функцыі |
| Працэс проксі | Слухач на дасяжным інтэрфейсе з дазволеным доступам кліентаў |
Адно правіла ўваходу ў групе функцыі не можа дазволіць гэтае зыходнае кліенцкае злучэнне. Уключыце табліцы маршрутаў і сеткавыя ACL падсеткі ў праверку шляху.
Для прыватнага імя проксі Route 53 праверце сувязь зоны з VPC і наладку DNS, у тым ліку enableDnsHostnames і enableDnsSupport. Паспяховы запыт з ноўтбука не даказвае DNS-прадстаўленне Lambda. Зафіксуйце, ці няўдалае імя адносіцца да проксі ці да сайта; пераўтварэнне сайта ў лікавы IP не выпраўляе імя проксі.
Пасля таго як гэты крок працуе, проксі патрабуе ўласнага далейшага маршруту. Далучэнне Lambda да публічнай падсеткі не прызначае публічны IP і не дае аўтаматычна прамога доступу ў інтэрнэт; выхад вырашайце асобна для абодвух злучэнняў.