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 і не забезпечує автоматично прямого доступу до інтернету; вихідний трафік вирішуйте окремо для обох з'єднань.