VPN ഓണ് ചെയ്യുമ്പോൾ ക്ലൗഡ് ഫയർവാൾ കാണുന്ന വിലാസം
പൂർണ്ണ ടണൽ നിങ്ങളുടെ ഡാറ്റാബേസ് കാണുന്ന സ്രോതസ്സ് വിലാസം മാറ്റുന്നു. അനുവദനീയ പട്ടിക, സ്വകാര്യ പാത അല്ലെങ്കിൽ സ്പ്ലിറ്റ് ടണൽ മാറ്റുക, ക്രെഡൻഷ്യൽ അല്ല.
VPN ബന്ധിപ്പിക്കുന്നതിന് മുമ്പ് പ്രവർത്തിക്കുകയും ശേഷം പരാജയപ്പെടുകയും ചെയ്യുന്ന ഡാറ്റാബേസ് അപൂർവ്വമായി ക്രെഡൻഷ്യൽ പ്രശ്നമാണ്. ക്ലൗഡ് ഫയർവാളുകൾ സ്രോതസ്സ് വിലാസങ്ങൾ പൊരുത്തപ്പെടുത്തുന്നു, പൂർണ്ണ ടണൽ അവ പൊരുത്തപ്പെടുത്തിയിരുന്ന വിലാസം തന്നെ മാറ്റിസ്ഥാപിക്കുന്നു. നിങ്ങളുടെ ലാപ്ടോപ്പ് എന്ത് അയയ്ക്കുന്നു എന്ന് നിങ്ങൾ കരുതുന്നതും സർവർ എന്ത് സ്വീകരിക്കുന്നു എന്നതും തമ്മിലുള്ള വിടവാണ് മുഴുവൻ ബഗ്, അത് ഒരു ഘട്ടത്തിൽ തന്നെ അളക്കാനാകും.
സ്രോതസ്സ് വിലാസം എന്താകുന്നു
പൂർണ്ണ ടണലിൽ ഓരോ പാക്കറ്റും VPN ഗേറ്റ്വേയിലൂടെ പുറത്തുപോകുന്നു, അതിനാൽ സർവർ നിങ്ങളുടെ വീട്ടിലെ കണക്ഷനല്ല, ഗേറ്റ്വേയുടെ ഔട്ട്ബൗണ്ട് വിലാസമാണ് കാണുന്നത്. പാതയിൽ ഫോർവേഡ് പ്രോക്സി ഉണ്ടെങ്കിൽ അതിന്റെ വിലാസമാണ് എത്തുന്നത്. രണ്ടും സാധുവായ സ്രോതസ്സുകളാണ്, നിങ്ങളുടെ യഥാർത്ഥ നിയമത്തിലെ വിലാസം അവയിൽ ഒന്നുമല്ല.
Azure SQL-ന്റെ സർവർ-തല, ഡാറ്റാബേസ്-തല ഫയർവാൾ നിയമങ്ങൾ ലോജിക്കൽ സർവറിൽ എത്തുന്ന ക്ലയന്റ് വിലാസം പൊരുത്തപ്പെടുത്തുന്നു, പൂർണ്ണ ടണലിന് ശേഷം അത് ഔട്ട്ബൗണ്ട് വിലാസമാണ്. ഒരു വിലാസം മാത്രം അനുവദിക്കുന്ന AWS സുരക്ഷാ ഗ്രൂപ്പും അതേ രീതിയിൽ പെരുമാറുന്നു. പാക്കറ്റ് പ്രാമാണീകരണത്തിന് മുമ്പേ നീക്കം ചെയ്യപ്പെടുന്നു, അതിനാൽ ലഭിക്കുന്ന പിശക് അനുമതി പ്രശ്നത്തെക്കാൾ നെറ്റ്വർക്ക് തകരാറായി തോന്നുന്നു. ആളുകൾ പാസ്വേഡ് പുനഃസജ്ജീകരിക്കാൻ തുടങ്ങുന്നതിന്റെ കാരണം കൃത്യം അതാണ്.
അനുവദനീയ പട്ടിക എവിടെ തീരുമാനിക്കുന്നു
പരാജയപ്പെടുന്ന പാതയോട് പൊരുത്തപ്പെടുന്ന നിയമം വായിക്കുക, നിങ്ങൾ സൃഷ്ടിച്ചതായി ഓർക്കുന്ന നിയമമല്ല. അതിന്റെ പരിധി, പോർട്ട്, പ്രോട്ടോക്കോൾ, ഏതെങ്കിലും ഐഡന്റിറ്റി പരിശോധനയ്ക്ക് മുമ്പ് അത് വിലയിരുത്തപ്പെടുന്നുണ്ടോ എന്നിവ ശ്രദ്ധിക്കുക.
തുടർന്ന് ഏത് പാളിക്കാണ് ഈ തീരുമാനത്തിന്റെ സാധുവായ ഉടമസ്ഥതയുള്ളതെന്ന് തീരുമാനിക്കുക. വിലാസ നിയമം ട്രാഫിക് എവിടെ നിന്ന് വരുന്നു എന്ന് ഉത്തരം നൽകുന്നു. സ്വകാര്യ എൻഡ്പോയിന്റ് സേവനം സ്വകാര്യ പാതയിലൂടെ എത്താനാകുമോ എന്ന് ഉത്തരം നൽകുന്നു. സ്പ്ലിറ്റ്-ടണൽ ഒഴിവാക്കൽ ഏത് ലക്ഷ്യസ്ഥാനങ്ങൾ ടണൽ ഒഴിവാക്കുന്നു എന്ന് ഉത്തരം നൽകുന്നു. ഇവ പരസ്പരം മാറ്റാനാവില്ല, ടണൽ മാറുമ്പോൾ ഓരോന്നും വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു.
മൂന്ന് അറ്റകുറ്റപ്പണികൾ, മൂന്ന് പാളികൾ
താഴെയുള്ള ഓരോ ഓപ്ഷനും വ്യത്യസ്ത കാരണത്താൽ ഒഴുക്ക് ശരിയാക്കുന്നു, തെറ്റായത് തിരഞ്ഞെടുത്താൽ അടുത്ത ഗേറ്റ്വേ മാറ്റം വരെ പ്രവർത്തിക്കുന്ന കണക്ഷൻ ഉണ്ടാകും.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
ഔട്ട്ബൗണ്ട് വിലാസം ചേർക്കുന്നത് ഏറ്റവും ചെറിയ മാറ്റവും ഏറ്റവും ദുർബലവുമാണ്, കാരണം പുതിയ ഗേറ്റ്വേയോ മറ്റൊരു പ്രദേശമോ അതിനെ നിശബ്ദമായി അസാധുവാക്കുന്നു. ടണലിന്റെ നിർവചനത്തിനൊപ്പം വിലാസം രേഖപ്പെടുത്തുക, രണ്ടും ഒരുമിച്ച് നീങ്ങാൻ. താൽക്കാലിക വിശാലമായ ശ്രേണി ഒരു രോഗനിർണ്ണയമാണ്, അറ്റകുറ്റപ്പണിയല്ല; അത് അവിടെ തന്നെ വിടുന്നതാണ് ആന്തരിക സേവനങ്ങൾ തുറന്നുകിടക്കുന്ന വഴി.
നിയന്ത്രിത പ്ലാറ്റ്ഫോമിന് ടണലിൽ ചേരാൻ കഴിയാത്തത് എന്തുകൊണ്ട്
Heroku, AppHarbor അല്ലെങ്കിൽ CloudBees പോലുള്ള ആപ്ലിക്കേഷൻ പ്ലാറ്റ്ഫോമുകൾ നിങ്ങളുടെ കോഡ് tun അല്ലെങ്കിൽ tap ഉപകരണമില്ലാത്ത, അത് സൃഷ്ടിക്കാൻ അധികാരവുമില്ലാത്ത പരിസരത്ത് പ്രവർത്തിപ്പിക്കുന്നു. അവയുടെ ഇൻബൗണ്ട് മാതൃക HTTP ആണ്, ഏതെങ്കിലും കേൾക്കുന്ന സോക്കറ്റല്ല. VPN ബൈനറി കൊണ്ടുവരുന്ന buildpack-നും ഇന്റർഫേസ് വയ്ക്കാൻ ഇടമില്ല. പ്രവർത്തിക്കുന്ന മാതൃകകൾ ഡാറ്റാബേസിന് അനുവദിക്കാവുന്ന സ്ഥിര ഔട്ട്ബൗണ്ട് വിലാസം, പ്ലാറ്റ്ഫോം നൽകുന്ന സ്വകാര്യ കണക്ഷൻ ഉൽപ്പന്നം, അല്ലെങ്കിൽ DMZ-യിൽ HTTPS വഴി എത്തുന്ന പ്രോക്സി എന്നിവയാണ്.
ആ പ്രോക്സി സ്വന്തം പ്രാമാണീകരണവും ലോഗിംഗും ഉള്ള ആക്സസ് പാതയാണ്. അത് പ്ലാറ്റ്ഫോമിനെ നിങ്ങളുടെ VPN-ന്റെ അംഗമാക്കുന്നില്ല, അങ്ങനെ വിവരിക്കുന്നത് ആർക്കും ഓഡിറ്റ് ചെയ്യാനാകാത്ത നിയമങ്ങൾ സൃഷ്ടിക്കുന്നു.
പരാജയപ്പെട്ട ക്ലയന്റിൽ നിന്ന് പരിശോധിക്കുക
വീണ്ടും ബന്ധിപ്പിച്ച് ക്ലയന്റിന്റെ കൃത്യമായ പാത ആവർത്തിക്കുക. സേവനം രേഖപ്പെടുത്തുന്ന സ്രോതസ്സ് വിലാസം, ഡാറ്റാബേസ് നാമത്തിനായി ക്ലയന്റ് തിരഞ്ഞെടുക്കുന്ന റൂട്ട്, യഥാർത്ഥ ക്വറിയുടെ ഫലം എന്നിവ ആ ക്രമത്തിൽ പരിശോധിക്കുക. ഗേറ്റ്വേയിൽ നിന്നുള്ള പരിശോധന ഗേറ്റ്വേ പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, അത് ഒരിക്കലും സംശയത്തിലായിരുന്നില്ല. കണക്ഷൻ ഇപ്പോൾ പ്രാമാണീകരിക്കപ്പെട്ടാലും ക്വറി ഇപ്പോഴും പരാജയപ്പെട്ടാൽ, ബാക്കിയുള്ള പ്രശ്നം ഡാറ്റാബേസ് അനുമതിയാണ്.
ടണൽ മാറുമ്പോഴെല്ലാം ഈ നിയമങ്ങൾ പരിശോധിക്കുക. പകരം വച്ച ഗേറ്റ്വേയോ പുതിയ ഔട്ട്ബൗണ്ട് ശ്രേണിയോ ആപ്ലിക്കേഷൻ കോൺഫിഗറേഷനിൽ യാതൊരു മാറ്റവുമില്ലാതെ പാത തകർക്കുന്നു.