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 لامبدا را اثبات نمی‌کند. ثبت کنید که نام ناموفق پروکسی است یا وب‌سایت؛ تغییر وب‌سایت به IP عددی اصلاح نام پروکسی نیست.
پس از کارکردن این گام، پروکسی به مسیر رو به جلوی خود نیاز دارد. اتصال Lambda به زیرشبکه عمومی IP عمومی اختصاص نمی‌دهد و دسترسی مستقیم به اینترنت را خودکار فراهم نمی‌کند؛ خروجی را برای هر دو اتصال جداگانه تصمیم بگیرید.