ഓഫീസിനും VPN-നും ഒരു URL? അനുമതി പട്ടികയുടെ കെട്ടുകഥ പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്
VPN കണക്ഷൻ അനുമതി പട്ടികയിലുള്ള സൈറ്റ് കാണുന്ന വിലാസം മാറ്റുന്നില്ല. URL ചേർക്കുന്നതിന് മുൻപ് യഥാർത്ഥ എഗ്രസ്, വിശ്വസ്ത പ്രോക്സി ഹോപ്പ്, IPv6 പാത എന്നിവ പരിശോധിക്കുക.
ടണൽ ബന്ധിപ്പിക്കുക, അതേ ബുക്ക്മാർക്ക് തുറക്കുക, അനുമതി പട്ടികയിലുള്ള സൈറ്റ് ഓഫീസിൽ നിന്ന് ഉത്തരം നൽകിയതുപോലെ കൃത്യമായി ഉത്തരം നൽകുന്നു. ഇതാണ് മിക്ക ദൂരസ്ഥ ആക്സസ് പ്ലാനുകളും നിശ്ശബ്ദമായി ആശ്രയിക്കുന്ന അനുമാനം, മൂന്ന് വേറിട്ട കാര്യങ്ങൾ ഒരേ സമയം ശരിയായി നിൽക്കുന്നിടത്തോളം മാത്രമേ അത് നിലനിൽക്കൂ. അവയൊന്നും VPN ക്ലയന്റിന്റെ സവിശേഷതയല്ല, ഏതൊരു DNS റെക്കോർഡിനും അവയൊന്നും നൽകാനാവില്ല. വീട്ടിൽ ബുക്ക്മാർക്ക് പരാജയപ്പെടുമ്പോൾ, കാരണം നഷ്ടപ്പെട്ട റൂട്ടോ അംഗീകരിക്കാത്ത എഗ്രസ് വിലാസമോ അത് റിപ്പോർട്ട് ചെയ്യുന്ന സ്രോതസ്സ് മാറ്റിയ പ്രോക്സിയോ ആകട്ടെ, ബ്രൗസർ ഒരു പൊതു പിശക് മാത്രം നൽകുന്നു. ആ മൂന്നിനെയും ഒരു പ്രശ്നമായി കാണുന്നതാണ് ഒരു ചെറിയ നയപരിഷ്കാരം അനുമതി പട്ടികകൾ വിശാലമാക്കുന്ന ഒരു ആഴ്ചയായി മാറുന്ന വഴി.
യഥാർത്ഥ ഓഫീസ് നെറ്റ്വർക്കുമായുള്ള സമ്പർക്കം അതിജീവിക്കുന്ന രൂപകൽപ്പന അനുമാനത്തേക്കാൾ ഇടുങ്ങിയതാണ്: വ്യക്തമായ മൂന്ന് വരി തീരുമാന പട്ടിക, മറികടക്കാനാവാത്ത ഒരു നിർവ്വഹണ ബിന്ദു, എന്തെങ്കിലും തെളിയിക്കുന്ന ഒരു നിരാകരണ പരിശോധന. അനുമാനം പൊളിക്കുന്നത് ആദ്യം വരുന്നു, കാരണം അതിനു ശേഷമുള്ളതെല്ലാം ഏത് പാളിയാണ് സ്രോതസ്സിനെ തെറ്റായി അവതരിപ്പിക്കുന്നത് എന്നറിയുന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
കെട്ടുകഥ: ബന്ധിപ്പിക്കുന്നത് റൂട്ടിംഗ് അല്ല
ഒരു ടണൽ സ്ഥാപിക്കപ്പെടുന്നു, ക്ലയന്റ് ചില പ്രിഫിക്സുകൾക്ക് റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ബന്ധിപ്പിക്കുന്നത് അത്രമാത്രം ചെയ്യുന്നു. ബന്ധമില്ലാത്ത ഒരു HTTPS അഭ്യർത്ഥന ടണലിലൂടെ സഞ്ചരിക്കുമോ, എത്തുമ്പോൾ ഏത് പൊതു വിലാസത്തിൽ നിന്ന് വരുന്നതായി കാണപ്പെടും എന്നത് പിന്നീട് മറ്റ് ഘടകങ്ങൾ എടുക്കുന്ന തീരുമാനങ്ങളാണ്: റൂട്ടിംഗ് പട്ടിക പാത തിരഞ്ഞെടുക്കുന്നു, എഗ്രസ് സ്രോതസ്സ് തിരഞ്ഞെടുക്കുന്നു.
അതുകൊണ്ടാണ് ഒരേ ലാപ്ടോപ്പ്, ഒരേ ബ്രൗസർ പ്രൊഫൈൽ, ഒരേ ബുക്ക്മാർക്ക് എന്നിവയുമായി ഓഫീസും അടുക്കളമേശയും വേർതിരിയുന്നത്. ഓഫീസിൽ സൈറ്റ് ഓപ്പറേറ്റർ സമ്മതിച്ച പരിപാലിക്കുന്ന പൊതു വിലാസത്തിലൂടെയാണ് അഭ്യർത്ഥന പുറത്തുപോകുന്നത്. പൂർണ്ണ ടണലിലൂടെ അത് VPN എഗ്രസിലൂടെ പുറത്തുപോകാം, അത് വേറെ വിലാസമാണ്, ആരെങ്കിലും അത് ചേർക്കുന്നതുവരെ അംഗീകരിക്കപ്പെട്ടതല്ല. വിഭജിത ടണലിലൂടെ അത് ടണലിൽ ഒട്ടും പ്രവേശിച്ചേക്കില്ല. ആ മൂന്ന് പാതകളിൽ രണ്ടെണ്ണം മാത്രമാണ് സൈറ്റ് ഉടമയുമായുള്ള കരാറിന്റെ ഭാഗമായിരുന്നത്, മൂന്നാമത്തേത് അധിക allow വരി ചേർത്ത് പരിഹരിക്കേണ്ട ഒരു കുറവല്ല.
മൂന്ന് അഭ്യർത്ഥന അവസ്ഥകൾ, രണ്ട് അംഗീകൃത എഗ്രസുകൾ
ഫയർവാൾ തൊടുന്നതിന് മുൻപ് മാട്രിക്സ് എഴുതുക, കാരണം പട്ടികയാണ് രൂപകൽപ്പന, നിയമം അതിന്റെ ഒരു നിർവ്വഹണം മാത്രം. താഴെയുള്ള വിലാസങ്ങൾ ഡോക്യുമെന്റേഷൻ ശ്രേണികളാണ്; അവ നിങ്ങളുടെ പരിപാലിക്കുന്ന മൂല്യങ്ങളാൽ മാറ്റി, സൈറ്റ് ഉടമയ്ക്ക് പരിശോധിക്കാനാവുന്ന ഇടത്ത് സൂക്ഷിക്കുക.
| Request path | Source the site sees | Intended decision |
|---|---|---|
| Office, no tunnel | Office public exit | Admit to the application login |
| Remote, approved full tunnel | Approved VPN egress | Admit to the same login |
| Remote, ordinary connection | Neither approved address | Deny at the network boundary |
ഈ പ്ലാനുകളിൽ മിക്കതും ഒടിയുന്നത് മധ്യ വരിയിലാണ്. പ്രാധാന്യമുള്ളത് നിർവ്വഹണ ഉപകരണം കാണുന്ന വിലാസമാണ്, ലാപ്ടോപ്പ് ടണലിനുള്ളിൽ സൂക്ഷിക്കുന്ന സ്വകാര്യ വിലാസമല്ല, അതിന്റെ LAN വിലാസവുമല്ല. 10.8.0.6 പോലുള്ള ഒരു മൂല്യം ഒരു പൊതു സൈറ്റിന് ഒന്നും അർത്ഥമാക്കുന്നില്ല, 192.168.1.44 ഉം അങ്ങനെതന്നെ. ടണലിന്റെ വിലാസം ടണലിന്റെ അഡ്രസ്സിംഗ് വിശദാംശമാണ്, സൈറ്റിന് പരിശോധിക്കാനാവുന്ന ഒരു യോഗ്യതാപത്രമല്ല.
നിങ്ങളുടെ VPN-ന് സ്ഥിരവും രേഖപ്പെടുത്തിയതുമായ ഒരു എഗ്രസ് നൽകാനാവുന്നില്ലെങ്കിൽ, മാട്രിക്സിൽ സാധുവായ മധ്യ വരിയില്ല, എത്ര അനുമതി പട്ടികകളും ഒന്ന് സൃഷ്ടിക്കില്ല. ആ നിമിഷത്തെ സത്യസന്ധമായ ഓപ്ഷനുകൾ വ്യക്തമായ സ്വകാര്യ റൂട്ടുകളിലൂടെ എത്തുന്ന ഒരു സ്വകാര്യ സൈറ്റ്, അല്ലെങ്കിൽ ആപ്ലിക്കേഷന് മുൻപിൽ ഐഡന്റിറ്റി ബോധ്യമുള്ള ഒരു ആക്സസ് ഗേറ്റ്വേ എന്നിവയാണ്. രണ്ടിനും പൊതു അനുമതി പട്ടികയിൽ നിന്ന് വ്യത്യസ്തമായ കരാറുണ്ട്, രണ്ടും യാദൃച്ഛികമായി പ്രവർത്തിക്കുന്നതുവരെ വളർന്ന ഒരു പട്ടികയെക്കാൾ ഓഡിറ്ററോട് വിശദീകരിക്കാൻ എളുപ്പമാണ്.
തീരുമാനം എടുക്കുന്നിടത്ത് സ്രോതസ്സ് വായിക്കുക
നിയന്ത്രണം അഭ്യർത്ഥന അവസാനിപ്പിക്കുന്ന ഉപകരണത്തിൽ വയ്ക്കുക, മറ്റൊരു ഉത്ഭവ പാത അതിനെ മറികടക്കുന്നില്ലെന്ന് ഉറപ്പാക്കുക. Nginx ആക്സസ് മൊഡ്യൂൾ allow, deny നിർദ്ദേശങ്ങൾ ക്രമത്തിൽ വിലയിരുത്തുന്നു, ആദ്യ പൊരുത്തം ജയിക്കുന്നു, ചുറ്റുമുള്ള ബ്ലോക്കിൽ നിന്ന് പകർന്ന നിയമങ്ങൾ location-നുള്ളിൽ ഇപ്പോഴും ബാധകമാണ്. ഒരേ സ്ഥലത്ത് ഇടുങ്ങിയ allow വിശാല allow-ന്റെ അടുത്തുണ്ടെങ്കിൽ സാധാരണയായി വിശാലമാണ് തീരുമാനിക്കുന്നത്. അതിന്റെ ഒരു വരി പോലും തിരുത്തുന്നതിന് മുൻപ് ആ location-ന്റെ മുഴുവൻ ഫലപ്രദ കോൺഫിഗറേഷനും വായിക്കുക.
server {
listen 443 ssl;
server_name intranet.example.com;
set_real_ip_from 10.20.0.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
location /app/ {
allow 203.0.113.24; # office public exit
allow 198.51.100.77; # approved VPN egress
deny all;
proxy_pass http://app_backend;
}
}ലോഡ് ബാലൻസറിനോ റിവേഴ്സ് പ്രോക്സിക്കോ പിന്നിൽ ആ നിയമം പ്രോക്സിയെ കാണുന്നു, നിങ്ങൾ വേറെ പറയുന്നില്ലെങ്കിൽ. വിളിക്കുന്നയാളുടെ വിലാസം പിന്തുണയുള്ള വിശ്വസ്ത പ്രോക്സി സംവിധാനത്തിലൂടെ മാത്രം, പ്രോക്സി വിലാസങ്ങളുടെ വ്യക്തമായ പട്ടികയോടെ പുനഃസ്ഥാപിക്കുക. അംഗീകൃത വിലാസം അവകാശപ്പെടുന്ന അഭ്യർത്ഥന ഹെഡർ വിളിക്കുന്നയാൾ അത് സ്വന്തമാക്കുന്നു എന്നതിന് തെളിവല്ല, പൊതു ശ്രോതാവിൽ സാധൂകരിക്കാത്ത ഫോർവേഡ് ചെയ്ത ഹെഡർ അനുമതി പട്ടികയെ അലങ്കാരമാക്കുന്നു.
പിന്നീട് മറ്റേ വിലാസ കുടുംബം പരിശോധിക്കുക. IPv4 മാത്രം ഉൾക്കൊള്ളുന്ന ഒരു നിയമ കൂട്ടം AAAA-യിലും ഉത്തരം നൽകുന്ന ഒരു ഹോസ്റ്റ് നാമത്തിന് അപൂർണ്ണമായ തീരുമാനമാണ്, പ്രവർത്തിക്കുന്ന IPv6 ഉള്ള ഒരു ക്ലയന്റ് നിങ്ങൾ ഒരിക്കലും പരിശോധിക്കാത്ത ഒരു പാതയിലൂടെ അതേ ആപ്ലിക്കേഷനിൽ എത്തും.
വിഭജിത ടണൽ: ഒരിക്കലും അകത്തേക്ക് വരാത്ത അഭ്യർത്ഥന
ഒരു വിഭജിത ടണൽ അതിന്റെ പട്ടികയിലുള്ള പ്രിഫിക്സുകൾ മാത്രം കൊണ്ടുപോകുന്നു. ഓഫീസിലെ ആന്തരിക സബ്നെറ്റുകൾ സാധാരണയായി ആ പട്ടികയിൽ വരും; പൊതു വെബ്സൈറ്റ് വരില്ല. ബ്രൗസർ പേര് പരിഹരിക്കുന്നു, തിരഞ്ഞെടുത്ത വിലാസം റൂട്ടിംഗ് പട്ടികയുമായി താരതമ്യപ്പെടുത്തുന്നു, എന്നിട്ടും മുൻപിൽ പ്രാദേശിക ഡിഫോൾട്ട് ഗേറ്റ്വേ കണ്ടെത്തുന്നു.
അങ്ങനെ അഭ്യർത്ഥന ഉപയോക്താവിന്റെ വീട്ടിലെ കണക്ഷനിൽ നിന്ന് വന്ന് നിരസിക്കപ്പെടുന്നു, റിപ്പോർട്ട് VPN തകർന്നു എന്ന് പറയുന്നു, എന്നാൽ ടണൽ അതിനായി കോൺഫിഗർ ചെയ്തത് കൃത്യമായി ചെയ്യുന്നു. രണ്ട് തിരുത്തലുകൾ സാധുവാണ്: ആ ലക്ഷ്യസ്ഥാനം ടണലിലൂടെ കടത്തിവിട്ട് അംഗീകൃത എഗ്രസ് അത് വഹിക്കട്ടെ, അല്ലെങ്കിൽ സൈറ്റ് നേരിട്ട് എത്തുന്നു എന്ന് സമ്മതിച്ച് ദൂരസ്ഥ ഉപയോക്താക്കൾക്ക് ആക്സസ് ഗേറ്റ്വേ പോലുള്ള മറ്റൊരു അംഗീകൃത പാത നൽകുക. വീട്ടിലെ വിലാസം യാദൃച്ഛികമായി ഉൾപ്പെടുന്നതുവരെ സൈറ്റിന്റെ പൊതു അനുമതി പട്ടിക വിശാലമാക്കുന്നത് രണ്ടുമല്ല, അത് രൂപകൽപ്പന നിർവ്വഹിക്കേണ്ട അതിർത്തി നീക്കം ചെയ്യുന്നു. ആദ്യത്തെ രണ്ട് മാട്രിക്സിനെ സത്യസന്ധമായി നിലനിർത്തുന്നു; മൂന്നാമത്തേത് അതിൽ നിന്ന് ഒരു വരി നിശ്ശബ്ദമായി മായ്ക്കുന്നു.
നിരാകരണം തെളിയിക്കുക, പിന്നീട് വീണ്ടെടുക്കൽ
പട്ടികയിലെ ഓരോ വരിയിലും നിൽക്കുന്ന ഒരു ക്ലയന്റിൽ നിന്ന് യഥാർത്ഥ തീരുമാനം പ്രയോഗിക്കുന്ന ഒരു അഭ്യർത്ഥനയോടെ പരീക്ഷിക്കുക. ബന്ധമില്ലാത്ത ഏതോ വിലാസം കാണിക്കുന്ന ഒരു പേജിനോടുള്ള എത്തിച്ചേരൽ പരിശോധന ഒന്നും തെളിയിക്കുന്നില്ല, കാരണം ആ ലക്ഷ്യസ്ഥാനം ആപ്ലിക്കേഷനിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു പാത പിന്തുടരാം.
curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'അതിർത്തിയിലെ ആക്സസ് രേഖ പട്ടിക പ്രവചിച്ചതുമായി താരതമ്യപ്പെടുത്തുക. പിന്നീട് ടണൽ താഴ്ത്തി നിരസിക്കപ്പെടേണ്ട ഒരു പുതിയ അഭ്യർത്ഥന നടത്തുക; മുൻപേ ലോഡ് ചെയ്ത പേജോ മുൻപേ തുറന്ന കണക്ഷനോ ഒന്നും പരിശോധിക്കുന്നില്ല. ഒരു നിരാകരണവും കാണുന്നില്ലെങ്കിൽ, നിർവ്വഹണ ബിന്ദു നിങ്ങൾ കരുതുന്നിടത്തല്ല.
നെറ്റ്വർക്ക് പ്രവേശനത്തിന് ശേഷവും ആപ്ലിക്കേഷൻ പ്രാമാണീകരണം നിലനിർത്തുക, കാരണം ഓഫീസ് എഗ്രസും VPN എഗ്രസും ഓരോന്നും ധാരാളം ആളുകളെ പ്രതിനിധീകരിക്കുന്നു, ഒന്നും ഒരു വ്യക്തിയെ തിരിച്ചറിയുന്നില്ല. ഉപയോക്താക്കൾക്കുള്ള നിർദ്ദേശം ചെറുതായി തുടരുന്നു: അംഗീകൃത ടണൽ ഉയർത്തുക, പിന്നീട് വീണ്ടും ശ്രമിക്കുക. സ്രോതസ്സ് നിയമം ഊഹമല്ലാതെ തീരുമാനമായി തുടരുമ്പോൾ ഒരു URL സൗകര്യപ്രദമായി നിലനിർത്തുന്നത് ഇതാണ്.