AWS Lambda സ്വകാര്യ പ്രോക്സിയിൽ എത്തുന്നില്ല: VPC പാത പരിശോധിക്കുക

ആദ്യ VPC കണക്ഷനുവേണ്ടി പ്രോക്സി ലിസണറുടെ വിലാസവും പോർട്ടും ഉപയോഗിക്കുക, ശരിയായ സെക്യൂരിറ്റി-ഗ്രൂപ്പ് ദിശയും DNS കാഴ്ചയും സഹിതം.

Requests ഫോർവേഡ് പ്രോക്സിക്കായി കോൺഫിഗർ ചെയ്തിരിക്കുമ്പോൾ Lambda ആദ്യം ആ ലിസണറുമായി ബന്ധിക്കുന്നു. 443-ൽ ഉള്ള ഒരു HTTPS സൈറ്റ് 3128-ൽ കേൾക്കുന്ന പ്രോക്സിയെ ആദ്യ-ഹോപ്പ് പോർട്ട് 443 ആക്കുന്നില്ല.

Lambda code → configured VPC path → proxy listener → destination

EC2-ൽ ഹോസ്റ്റ് ചെയ്ത സ്വകാര്യ പ്രോക്സിക്കായി ഫംഗ്ഷൻ നിശ്ചിത VPC സബ്നെറ്റുകളിലും സെക്യൂരിറ്റി ഗ്രൂപ്പുകളിലും ബന്ധിപ്പിക്കുക. Lambda ഈ ബന്ധത്തിന്റെ നെറ്റ്വർക്ക് ഇന്റർഫേസുകൾ കൈകാര്യം ചെയ്യുന്നു. അവയുടെ റൂട്ടിംഗും ആക്സസ് നിയന്ത്രണങ്ങളും അനുവദിക്കുമ്പോൾ വ്യത്യസ്ത സബ്നെറ്റുകൾക്കും പ്രവർത്തിക്കാം.

നിയന്ത്രണംഒരേ VPC-യിൽ നേരിട്ട് റൂട്ട് ചെയ്ത ക്രമീകരണത്തിലെ ആദ്യ-ഹോപ്പ് ആവശ്യകത
ഫംഗ്ഷൻ സെക്യൂരിറ്റി ഗ്രൂപ്പ്പ്രോക്സി ലിസണറിലേക്കുള്ള പുറത്തേക്ക് പോകുന്ന TCP
പ്രോക്സി സെക്യൂരിറ്റി ഗ്രൂപ്പ്നിശ്ചിത ഫംഗ്ഷൻ ഉറവിടത്തിൽ നിന്നോ സെക്യൂരിറ്റി ഗ്രൂപ്പിൽ നിന്നോ ആ പോർട്ടിലേക്കുള്ള അകത്തേക്ക് വരുന്ന TCP
പ്രോക്സി പ്രോസസ്സ്എത്തിച്ചേരാവുന്ന ഇന്റർഫേസിൽ ക്ലയന്റ് ആക്സസ് അനുവദിച്ച ലിസണർ

ഫംഗ്ഷൻ ഗ്രൂപ്പിൽ മാത്രമുള്ള ഒരു ഇൻബൗണ്ട് നിയമത്തിന് ഈ ഔട്ട്ബൗണ്ട് ക്ലയന്റ് കണക്ഷൻ അനുവദിക്കാനാവില്ല. പാത പരിശോധനയിൽ റൂട്ട് ടേബിളുകളും സബ്നെറ്റിന്റെ നെറ്റ്വർക്ക് ACL-കളും ഉൾപ്പെടുത്തുക.

സ്വകാര്യ Route 53 പ്രോക്സി നാമത്തിന് ഹോസ്റ്റഡ് സോണിന്റെ VPC ബന്ധവും DNS കോൺഫിഗറേഷനും പരിശോധിക്കുക, enableDnsHostnames, enableDnsSupport ഉൾപ്പെടെ. ലാപ്ടോപ്പിലെ വിജയകരമായ തിരച്ചിൽ Lambda-യുടെ DNS കാഴ്ച തെളിയിക്കുന്നില്ല. പരാജയപ്പെട്ട പേര് പ്രോക്സിയാണോ വെബ്സൈറ്റാണോ എന്ന് രേഖപ്പെടുത്തുക; സൈറ്റ് സംഖ്യാ IP-യാക്കി മാറ്റുന്നത് പ്രോക്സി നാമത്തിന്റെ പരിഹാരമല്ല.

ഈ ഹോപ്പ് പ്രവർത്തിച്ചാൽ പ്രോക്സിക്ക് സ്വന്തമായി മുന്നോട്ടുള്ള പാത വേണം. Lambda-യെ പൊതു സബ്നെറ്റിലേക്ക് ബന്ധിപ്പിക്കുന്നത് പൊതു IP നൽകുന്നില്ല, നേരിട്ടുള്ള ഇന്റർനെറ്റ് ആക്സസ് സ്വയമേവ നൽകുന്നുമില്ല; രണ്ട് കണക്ഷനുകൾക്കും എഗ്രസ് വെവ്വേറെ തീരുമാനിക്കുക.

അനുബന്ധ ലേഖനങ്ങൾ