പോയിന്റ്-ടു-സൈറ്റ് VPN വഴി സ്വകാര്യ Container Apps ആപ്പ് എത്തിച്ചേരുക
ഒരു ആന്തരിക Container Apps പരിസ്ഥിതിക്ക് സ്വകാര്യ പ്രവേശനം, പൊരുത്തപ്പെടുന്ന ഹോസ്റ്റ്നെയിം, VPN എത്തിച്ചേരാവുന്ന റസോൾവർ എന്നിവ ആവശ്യമാണ്. ഓരോ ഘട്ടവും പ്രവർത്തിപ്പിച്ച്, ശേഷം നിരസിക്കൽ പരിശോധിക്കുക.
ഈ റൺബുക്ക് വർക്ക്ലോഡ് പ്രൊഫൈലുകളുള്ള ഒരു Container Apps പരിസ്ഥിതിയെയും അതിന്റെ ആന്തരിക വെർച്വൽ-നെറ്റ്വർക്ക് പ്രവേശനത്തെയും ഉൾക്കൊള്ളുന്നു; അനുവദിച്ച പോയിന്റ്-ടു-സൈറ്റ് VPN വഴി ലാപ്ടോപ്പിൽ നിന്ന് ഇതിൽ എത്തുന്നു, ആപ്പിന്റെ നേരിട്ടുള്ള FQDN ഉപയോഗിച്ച്, പരിസ്ഥിതി തലത്തിൽ HTTP റൂട്ടുകളില്ലാതെ. പരിസ്ഥിതിയുടെ പ്രവേശനം ക്ലയന്റിൽ നിന്ന് എത്താവുന്നതാണ്, ആപ്പിന്റെ ഇൻഗ്രെസ് പരിധി വിളിക്കുന്നയാളെ അനുവദിക്കുന്നു, ഹോസ്റ്റ്നെയിം സ്വകാര്യ പ്രവേശനത്തിലേക്ക് റസോൾവ് ചെയ്യുന്നു. താഴെയുള്ള ഓരോ ഘട്ടവും പരിശോധിക്കാവുന്ന ഫലവും നിങ്ങൾ മാറ്റാത്ത ഒന്നിനെയും സ്പർശിക്കാത്ത റോൾബാക്കും അവശേഷിപ്പിക്കുന്നു. നൽകിയ ക്രമത്തിൽ അവ പൂർത്തിയാക്കുക, കാരണം ഘട്ടം 1-ൽ തെറ്റായി എടുത്ത പരിധി തീരുമാനം പിന്നീടുള്ള ഏത് ഘട്ടത്തിനും നികത്താനാവില്ല.
DNS സ്പർശിക്കുന്നതിന് മുമ്പ് ആന്തരികം എന്ന വാക്ക് വ്യക്തമാക്കുക. ഈ ഉൽപ്പന്നത്തിൽ ഇത് രണ്ട് വ്യത്യസ്ത പരിധികൾക്ക് ഉപയോഗിക്കുന്നു, അവ കൈമാറുന്നതാണ് പ്രവർത്തിക്കുന്ന ഒരു നാമം ഇപ്പോഴും ഉപയോഗപ്രദമായ ഒന്നും തിരികെ നൽകാത്തതിന്റെ ഏറ്റവും സാധാരണ കാരണം.
ഘട്ടം 1: പരിസ്ഥിതിയുടെയും ആപ്പിന്റെയും പരിധി നിശ്ചയിക്കുക
ഏതെങ്കിലും റെക്കോർഡ് മാറ്റുന്നതിന് മുമ്പ് ആപ്പിന്റെ ഇൻഗ്രെസ് കോൺഫിഗറേഷൻ വായിക്കുക:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
ആന്തരിക ഇൻഗ്രെസ് പരിസ്ഥിതിയുടെ VNet-നുള്ളിൽ പരിസ്ഥിതിയുടെ ആന്തരിക ലോഡ് ബാലൻസറിൽ വെളിപ്പെടുത്തുന്നു, അതിനാൽ ചോദ്യം ലാപ്ടോപ്പ് മറ്റൊരു കണ്ടെയ്നർ ആപ്പാണോ എന്നതല്ല, അത് ആ VNet-ൽ എത്താമോ എന്നതാണ്. VNet-ലേക്ക് റൂട്ടുള്ളതും പരിസ്ഥിതിയുടെ ഡിഫോൾട്ട് ഡൊമെയ്ൻ സ്വകാര്യ സോണിലൂടെ റസോൾവ് ചെയ്യുന്നതുമായ VPN ക്ലയന്റ് യോഗ്യമായ വിളിക്കുന്നയാളാണ്, ബാക്കിയുള്ള ഘട്ടങ്ങൾ കൃത്യമായി അതാണ് നിർമ്മിക്കുന്നത്. പൊതു പ്രവേശനമില്ലാത്ത ആന്തരിക പരിസ്ഥിതി ആന്തരിക ഇൻഗ്രെസ്സുള്ള ആപ്പിൽ നിന്ന് വ്യത്യസ്തമായ വസ്തുതയാണ്, ആപ്പ് തലത്തിലുള്ള ബാഹ്യ ഇൻഗ്രെസ് പരിസ്ഥിതിക്ക് പൊതു വാതിൽ നൽകുന്നില്ല. പരിധി പോർട്ടലിലും ടിക്കറ്റിലും എഴുതുക, കാരണം അടുത്ത എൻജിനീയർ ആദ്യം ടിക്കറ്റ് വായിക്കുന്നു.
തുടരുന്നതിന് മുമ്പ് ആ പരിധി കോൺഫിഗറേഷൻ ഉടമയുമായി സ്ഥിരീകരിക്കുക, ഗേറ്റ് ഇടുങ്ങിയതായി സൂക്ഷിക്കുക: പരിസ്ഥിതിയുടെ VNet-ലേക്ക് റൂട്ട് ഇല്ലെങ്കിൽ, അല്ലെങ്കിൽ പരിസ്ഥിതിയുടെ ഡിഫോൾട്ട് ഡൊമെയ്ൻ സ്വകാര്യ സോണിലൂടെ റസോൾവ് ചെയ്യുന്നില്ലെങ്കിൽ, നിർത്തി ആദ്യം ആ പാത ശരിയാക്കുക. VNet-ൽ എത്താനോ നാമം റസോൾവ് ചെയ്യാനോ കഴിയാത്ത വിളിക്കുന്നയാളെ പിന്നീടുള്ള ഏത് ഘട്ടത്തിനും പകരം വയ്ക്കാനാവില്ല.
ഘട്ടം 2: യഥാർത്ഥ ഹോസ്റ്റ്നെയിമും പ്രവേശന വിലാസവും ശേഖരിക്കുക
പരിസ്ഥിതിയുടെ ഡിഫോൾട്ട് ഡൊമെയ്ൻ, അതിന്റെ സ്ഥിരമായ സ്വകാര്യ പ്രവേശന വിലാസം, ആപ്പിന്റെ കോൺഫിഗർ ചെയ്ത FQDN എന്നിവ രേഖപ്പെടുത്തുക; പഴയ സ്ക്രീൻഷോട്ടിൽ നിന്നോ വിക്കി പേജിൽ നിന്നോ അല്ല, റിസോഴ്സിൽ നിന്ന് എടുക്കുക:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"Container Apps-ന്റെ സ്വകാര്യ പ്രവേശന മാർഗ്ഗനിർദ്ദേശം ആപ്ലിക്കേഷന്റെ ഹോസ്റ്റ്നെയിമുകൾ അതേപടി നിലനിർത്തിക്കൊണ്ട് പരിസ്ഥിതിയുടെ ഡൊമെയ്ൻ അതിന്റെ ആന്തരിക വിലാസവുമായി പൊരുത്തപ്പെടുത്തുന്നത് വിവരിക്കുന്നു. നിങ്ങൾ ഇവിടെ കൈകൊണ്ട് നിർമ്മിക്കുന്ന രൂപം കൃത്യമായി അതാണ്, അതിനാൽ പുതിയ നാമകരണ പദ്ധതി കണ്ടുപിടിക്കുന്നതിന് പകരം സോണിന്റെ ഉള്ളടക്കം അതുമായി യോജിപ്പിക്കുക.
നിങ്ങൾ വായിച്ച ഡൊമെയ്ൻ ആപ്പ് റിപ്പോർട്ട് ചെയ്യുന്ന FQDN-മായി പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, നിർത്തി ഇപ്പോൾ അവ യോജിപ്പിക്കുക. തെറ്റായ പ്രത്യയത്തിൽ സോൺ നിർമ്മിക്കുന്നത് തികച്ചും റസോൾവ് ചെയ്യപ്പെടുകയും എന്നിട്ടും തെറ്റായ വെർച്വൽ ഹോസ്റ്റിൽ ഇറങ്ങുകയും ചെയ്യുന്ന ഒരു ഹോസ്റ്റ്നെയിം സൃഷ്ടിക്കുന്നു.
ഘട്ടം 3: സ്വകാര്യ സോൺ VPN-ന്റെ റസോൾവർ പാതയിൽ വയ്ക്കുക
പരിസ്ഥിതിയുടെ യഥാർത്ഥ ഡിഫോൾട്ട് ഡൊമെയ്നിനായി പിന്തുണയ്ക്കുന്ന സ്വകാര്യ DNS സോൺ സൃഷ്ടിക്കുകയോ വീണ്ടും ഉപയോഗിക്കുകയോ ചെയ്യുക, രേഖപ്പെടുത്തിയ വൈൽഡ്കാർഡും വിലാസ റെക്കോർഡുകളും സ്ഥിരമായ പ്രവേശനത്തിലേക്ക് ചൂണ്ടുന്നു. ആ സോൺ ഉചിതമായ വെർച്വൽ നെറ്റ്വർക്കുമായി ലിങ്ക് ചെയ്യുക, ലിങ്ക് മതിയെന്ന് അനുമാനിക്കുന്നതിന് പകരം VPN-ന്റെ അംഗീകൃത റസോൾവർ പാതയിലൂടെ സ്വകാര്യ അധികാരം എത്താവുന്നതാക്കുക.
പോയിന്റ്-ടു-സൈറ്റ് ക്ലയന്റിന് ആ സോണിൽ എത്താൻ സാധാരണയായി ഒരു സ്വകാര്യ റസോൾവറിന്റെ ഇൻബൗണ്ട് എൻഡ്പോയിന്റോ പിന്തുണയ്ക്കുന്ന DNS ഫോർവേഡറോ ആവശ്യമാണ്. സോൺ ലിങ്ക് ചെയ്യുന്നത് ലിങ്ക് ചെയ്ത നെറ്റ്വർക്കുകൾക്കായി Azure റസോൾവ് ചെയ്യുന്നത് മാറ്റുന്നു; അത് ഓരോ ബാഹ്യ ലാപ്ടോപ്പിന്റെയും പൊതു റസോൾവറിനെ റീഡയറക്ട് ചെയ്യുന്നില്ല. മറ്റൊരു Container Apps നെറ്റ്വർക്കിംഗ് മോഡലിൽ നിന്ന് കടമെടുത്ത സ്വകാര്യ-എൻഡ്പോയിന്റ് DNS സോൺ ഉപയോഗിച്ച് അത് മാറ്റരുത്, കാരണം റെക്കോർഡ് നാമങ്ങളും സോൺ പ്രത്യയവും പൊരുത്തപ്പെടില്ല.
ഈ ഘട്ടത്തിന്റെ റോൾബാക്ക് സോൺ ലിങ്കോ നിങ്ങൾ ചേർത്ത റെക്കോർഡോ നീക്കം ചെയ്യുന്നതാണ്. അവയിൽ ഏതായിരുന്നു എന്ന് രേഖപ്പെടുത്തുക, കാരണം ഒരു ലിങ്ക് പിൻവലിക്കാൻ പങ്കിട്ട സോൺ ഇല്ലാതാക്കുന്നത് രണ്ടാമത്തെ പരിസ്ഥിതി തകർക്കാനുള്ള അറിയപ്പെടുന്ന വഴിയാണ്.
ഘട്ടം 4: നാമം പരിശോധിക്കുക, തുടർന്ന് നിരസിക്കപ്പെട്ട പ്രേക്ഷകരെ
ഹോസ്റ്റ്നെയിമും TLS ഐഡന്റിറ്റിയും ഒരുമിച്ച് പരിശോധിക്കുക, വിലാസം മാത്രമല്ല. നിയന്ത്രിത നാമ-മാപ്പിംഗ് ഡയഗ്നോസ്റ്റിക്സിനായി ഹോസ്റ്റ്നെയിം നിലനിർത്തിക്കൊണ്ട് വിലാസം പിൻ ചെയ്യാം:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/ഹോസ്റ്റ്നെയിം യഥാർത്ഥ ആപ്പ് FQDN കൊണ്ടും വിലാസം യഥാർത്ഥ ആന്തരിക പ്രവേശനം കൊണ്ടും മാറ്റുക. ഇത് ആ ഒരു അഭ്യർത്ഥനയെ മാത്രം ബാധിക്കുന്നു, DNS പ്രൊവിഷനിംഗ് അല്ല. ഐഡന്റിറ്റി പരാജയത്തെ കാണുന്ന വിജയമാക്കി മാറ്റാൻ -k ചേർക്കരുത്, കാരണം സർട്ടിഫിക്കറ്റ് പൊരുത്തക്കേടാണ് നിങ്ങൾ തെറ്റായ ശ്രോതാവിനെ തൊടുന്നു എന്ന സൂചന.
സംഖ്യാത്മക വിലാസം നേരിട്ട് അഭ്യർത്ഥിക്കുന്നത് TCP 443 പ്രതികരിക്കുമ്പോൾ പോലും തെറ്റായ വെർച്വൽ ഹോസ്റ്റ് തിരഞ്ഞെടുക്കുകയോ സാധുത പരിശോധന പരാജയപ്പെടുത്തുകയോ ചെയ്യാം, അതിനാൽ വിജയകരമായ IP പരിശോധനയെ നെറ്റ്വർക്കിനെക്കുറിച്ചുള്ള തെളിവായി കണക്കാക്കുക, അതിൽ കൂടുതലല്ല. ഉദ്ദേശിച്ച ലാപ്ടോപ്പിൽ നിന്ന് സാധാരണ റസോൾവർ പാത ക്ലയന്റിന്റെ DNS ഫോർവേഡറോ സോൺ ഹോസ്റ്റ് ചെയ്യുന്ന സ്വകാര്യ റസോൾവറിന്റെ ഇൻബൗണ്ട് എൻഡ്പോയിന്റോ ആണ്, അവിടത്തെ പരാജയം കാണാത്ത റെക്കോർഡല്ല, റസോൾവർ എത്തിച്ചേരൽ പ്രശ്നമാണ്. അതേ അഭ്യർത്ഥന ആ പാതയിൽ വിജയിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, തുടർന്ന് നിരസിക്കപ്പെട്ട പ്രേക്ഷകർ ഇപ്പോഴും നിരസിക്കപ്പെട്ടിരിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക.
എന്ത് രേഖപ്പെടുത്തണം, എന്ത് റോൾബാക്ക് ചെയ്യണം
കണ്ടെയ്നറിന്റെ ലക്ഷ്യ പോർട്ടും ക്ലയന്റിന്റെ HTTPS പോർട്ടും വെവ്വേറെ ക്രമീകരണങ്ങളാണ്. കണ്ടെയ്നർ അവിടെ കേൾക്കുന്നതിനാൽ അതിന്റെ ലക്ഷ്യ പോർട്ട് VPN വഴി പ്രസിദ്ധീകരിക്കരുത്, പോർട്ട് പരിശോധന കടക്കാൻ നെറ്റ്വർക്ക് നിയമം വിപുലീകരിക്കരുത്. രണ്ട് മാറ്റങ്ങളും സംഭവത്തിന് ശേഷവും നിലനിൽക്കുന്നു, പിന്നീട് അവ ആരോപിക്കാൻ ബുദ്ധിമുട്ടാണ്.
ഉദ്ദേശിച്ച ലാപ്ടോപ്പിൽ നിന്ന് അതിന്റെ അധികാരമുള്ള ഐഡന്റിറ്റിയും സാധാരണ DNS-ഉം ഉപയോഗിച്ച് പുതിയ ആപ്ലിക്കേഷൻ പ്രവർത്തനത്തോടെ അവസാനിപ്പിക്കുക, തുടർന്ന് അനധികൃത വിളിക്കുന്നയാൾ ഇപ്പോഴും പരാജയപ്പെടുന്നുവെന്ന് പരിശോധിക്കുക. ആപ്പ് കോൺഫിഗറേഷനിൽ ഇരിക്കുമ്പോൾ, പരിസ്ഥിതി തലത്തിലുള്ള HTTP റൂട്ട് ഈ ആപ്പിനെ ലക്ഷ്യമായി വെളിപ്പെടുത്തുന്നുണ്ടോയെന്നും സ്ഥിരീകരിക്കുക, കാരണം ആ റൂട്ട് ഇൻഗ്രെസ് പരിധി വിവരിക്കാത്ത രണ്ടാമത്തെ വാതിലാണ്.
അഞ്ച് മൂല്യങ്ങൾ ഒരുമിച്ച് രേഖപ്പെടുത്തുക: പരിസ്ഥിതിയുടെ പരിധി, ആപ്പിന്റെ ഇൻഗ്രെസ് പരിധി, FQDN, സ്വകാര്യ പ്രവേശന വിലാസം, റസോൾവർ ഉടമ. ആ അഞ്ചും മുഴുവൻ പ്രവേശന കരാറിനെ വിവരിക്കുന്നു, അടുത്തതായി ഇത് ഡീബഗ് ചെയ്യുന്ന വ്യക്തി കൃത്യമായി അവ തന്നെ ആവശ്യപ്പെടും.