സെർവറിൽ ലോക്ക് ചെയ്ത പ്രൊഫൈൽ TLS പ്രോക്സിക്ക് പിന്നിൽ പരാജയപ്പെടുന്നു: ഏത് തലമുറ?
Access Server 2.8-ഉം 2.9-ഉം സെർവറിൽ ലോക്ക് ചെയ്ത പ്രൊഫൈലുകൾ വ്യത്യസ്തമായി നിർമ്മിക്കുന്നു. ഫ്രണ്ട് എൻഡ് മാറ്റുന്നതിന് മുമ്പ് നിങ്ങളുടെ പ്രോക്സി ഏത് പാതയാണ് തകർക്കുന്നതെന്ന് തീരുമാനിക്കുക.
ഒരു ഉപയോക്താവിന് കണക്റ്റ് ചെയ്യാം, മറ്റൊരാൾക്ക് കഴിയില്ല, ഒരേ പോർട്ടലിലൂടെ, ഒരേ ദിവസം. ഇരുവർക്കും സെർവറിൽ ലോക്ക് ചെയ്ത പ്രൊഫൈലുകളുണ്ട്, ഇരുവരും ഒരേ Access Server ബിൽഡിലാണ്, ഏക വ്യത്യാസം അവരുടെ പ്രൊഫൈൽ എപ്പോൾ നിർമ്മിച്ചു എന്നതാണ്. ഇത് തിരിച്ചറിയേണ്ട മാതൃകയാണ്, കാരണം "സെർവറിൽ ലോക്ക് ചെയ്തത്" എന്നത് കണക്ഷൻ ക്രമമല്ല, നയമാണ് സൂചിപ്പിക്കുന്നത്. Access Server ആ വസ്തുവിന്റെ രണ്ട് തലമുറകൾ പുറത്തിറക്കി, TLS റിവേഴ്സ് പ്രോക്സി അവയുടെ ഒരു പാതയുടെ മുന്നിൽ മാത്രമാണ് നിൽക്കുന്നത്. നിങ്ങൾ ഏത് ശാഖയിലാണെന്ന് മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു.
രണ്ട് തലമുറകൾ, രണ്ട് കണക്ഷൻ ക്രമങ്ങൾ
2.8 വരെ നിലവിലുള്ള പഴയ രൂപകൽപ്പനയിൽ, ഇമ്പോർട്ട് ചെയ്ത ഫയൽ ഒരു സ്യൂഡോ പ്രൊഫൈലാണ്. HTTPS വഴി Access Server-ന്റെ വെബ് API-യിൽ വേണ്ടി പ്രാമാണീകരിക്കാൻ OpenVPN Connect ഇത് ഉപയോഗിക്കുന്നു, താൽക്കാലിക ഉപയോക്തൃ-ലോക്ക് പ്രൊഫൈലും സെഷൻ ടോക്കണും സ്വീകരിക്കുന്നു, അതിനുശേഷം മാത്രം VPN സ്ഥാപിക്കുന്നു. രണ്ട് ട്രാൻസ്പോർട്ടുകൾ ക്രമത്തിൽ പ്രവർത്തിക്കുന്നു, ആദ്യത്തേത് ഒരു സാധാരണ വെബ് അഭ്യർത്ഥനയാണ്.
2.9-നൊപ്പം അവതരിപ്പിച്ച ഫോർമാറ്റ് ആ ഓരോ-കണക്ഷൻ ബൂട്ട്സ്ട്രാപ്പ് ചെയ്യുന്നില്ല. ഇത് ഒരു നേറ്റീവ് പ്രൊഫൈലാണ്, അനുയോജ്യമായ OpenVPN ക്ലയന്റുകൾക്ക് ഉപയോഗിക്കാം, OpenVPN Connect മാത്രമല്ല. ഇത് ഡൗൺലോഡ് ചെയ്യുന്നതോ URL വഴി ഇമ്പോർട്ട് ചെയ്യുന്നതോ ഇപ്പോഴും HTTPS ഉൾക്കൊള്ളാം — അത് പ്രസിദ്ധീകരണ ഘട്ടമാണ്, ഓരോ കണക്ഷനും താൽക്കാലിക പ്രൊഫൈൽ വലിച്ചെടുക്കലല്ല.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
അപ്ഗ്രേഡ് ഇതിനകം നൽകിയ പ്രൊഫൈലുകൾ നിർബന്ധമായും വീണ്ടും എഴുതുന്നില്ല, അതിനാൽ നിലവിലെ സെർവർ പതിപ്പ് ഇപ്പോഴും പഴയ വസ്തു വിതരണം ചെയ്തേക്കാം. സെർവർ ബിൽഡ് എന്ത് സാധ്യമാണെന്ന് പറയുന്നു, ഈ ഉപയോക്താവ് എന്ത് ഇമ്പോർട്ട് ചെയ്തു എന്നല്ല.
നിങ്ങളുടെ ശാഖ തിരഞ്ഞെടുക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ
ആദ്യ വ്യവസ്ഥ വസ്തുവിന്റെ തലമുറയാണ്. ഫയൽ ആവശ്യപ്പെടുക, അത് എങ്ങനെ നിർമ്മിച്ചു എന്ന് നോക്കുക, അത് ഇമ്പോർട്ട് ചെയ്ത ക്ലയന്റ് പതിപ്പ് കുറിക്കുക. ഫയലിൽ നിന്ന് തലമുറ നിർണ്ണയിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, ടെസ്റ്റ് അക്കൗണ്ടിനായി നൽകിയ പുതിയ പ്രൊഫൈൽ സെർവർ ഇന്ന് എന്ത് നിർമ്മിക്കുന്നു എന്ന് പറയും, അത് പരാജയപ്പെടുന്ന ഉപയോക്താവിനുള്ള വിവരത്തിൽ നിന്ന് വ്യത്യസ്തമാണ്.
രണ്ടാമത്തേത് നിങ്ങളുടെ ഫ്രണ്ട് എൻഡ് യഥാർത്ഥത്തിൽ എന്ത് അവസാനിപ്പിക്കുന്നു എന്നതാണ്. TLS ഇറക്കിവിടുന്ന ഏഴാം പാളിയിലെ HTTP റിവേഴ്സ് പ്രോക്സി നാലാം പാളിയിലെ TCP ഫോർവാർഡറിന് തുല്യമായ വസ്തുവല്ല, UDP ഫോർവാർഡറും അല്ല. പോർട്ട് 443-ൽ Access Server-ന്റെ സാധാരണ ക്രമീകരണം OpenVPN TCP ഡീമണിനെ ബ്രൗസർ ട്രാഫിക് തിരിച്ചറിഞ്ഞ് വെബ് സേവനങ്ങൾക്ക് കൈമാറാൻ പ്രേരിപ്പിക്കുന്നു, അതിനാൽ മുന്നിൽ ബന്ധമില്ലാത്ത ഒരു HTTPS ടെർമിനേറ്റർ ചേർക്കുന്നത് ആ ഡീമണിന്റെ പ്രോട്ടോക്കോൾ കൈകാര്യം സംരക്ഷിക്കുന്നില്ല. 443 എന്ന സംഖ്യ പങ്കിടുന്നത് രണ്ട് രൂപകൽപ്പനകളെ തുല്യമാക്കുന്നില്ല.
മൂന്നാമത്തേത് പരാജയം എവിടെ വീഴുന്നു എന്നതാണ്. VPN-ന് മുമ്പുള്ള പരാജയവും കൺട്രോൾ ചാനൽ പരാജയവും "കണക്റ്റ് ചെയ്യുന്നു" മാത്രം പറയുന്ന ക്ലയന്റിൽ സമാനമായി തോന്നാം, പക്ഷേ അവ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ തെളിവ് വിടുന്നു. പഴയ ഫോർമാറ്റ് ഉപയോഗത്തിലുണ്ടെങ്കിൽ ബൂട്ട്സ്ട്രാപ്പ് സ്ഥാനാർത്ഥിയാണ്. പുതിയ ഫോർമാറ്റ് ഉപയോഗത്തിലുണ്ടെങ്കിൽ ശൂന്യമായ വെബ് ആക്സസ് ലോഗ് പ്രതീക്ഷിതമാണ്, ഏത് ദിശയിലും ഒന്നും തെളിയിക്കുന്നില്ല.
വസ്തു പഴയതാകുമ്പോൾ: ബൂട്ട്സ്ട്രാപ്പ് ആദ്യം പരാജയപ്പെടുന്നു
ക്ലയന്റിന്റെ അവസാന അവസ്ഥയ്ക്ക് പകരം അതിന്റെ യഥാർത്ഥ പിശക് വായിക്കുക. താൽപ്പര്യമുള്ള ഫീൽഡുകൾ HTTPS പിശക്, ക്ലയന്റ് പ്രതീക്ഷിച്ച സെർവർ ഐഡന്റിറ്റി, അഭ്യർത്ഥന പോയ ലക്ഷ്യസ്ഥാനം, സർട്ടിഫിക്കറ്റ് സാധുത പരിശോധന പൂർത്തിയായോ എന്നിവയാണ്. തുടർന്ന് അവയെ സെർവർ വശത്തെ വെബ് സേവന, പ്രോക്സി ലോഗുകളുമായി ഒത്തുനോക്കുക.
ബ്രൗസർ ലോഗിൻ പേജിൽ എത്തുന്നത് ഈ ക്ലയന്റിന്റെ API പ്രാമാണീകരണം വിജയിച്ചു എന്നതിന് തെളിവല്ല. അവ വ്യത്യസ്ത അഭ്യർത്ഥനകളാണ്, വ്യത്യസ്ത സർട്ടിഫിക്കറ്റ് പ്രതീക്ഷകളും പലപ്പോഴും വ്യത്യസ്ത ഹോസ്റ്റ്നാമങ്ങളും ഉള്ളവ. പോർട്ടൽ ശരിയായി സേവിക്കപ്പെട്ടാലും ക്ലയന്റ് പരാജയപ്പെട്ടാൽ, വിയോജിപ്പ് ബൂട്ട്സ്ട്രാപ്പ് പാതയിലാണ്, ഉപയോക്താവിന്റെ പാസ്വേഡിലല്ല.
TLS പരിശോധന പ്രവർത്തനരഹിതമാക്കിയോ പ്രാമാണീകരണ നയം അയച്ചോ താരതമ്യം വിജയിപ്പിക്കരുത്. അത് രോഗനിർണ്ണയം ചെയ്യാവുന്ന കോൺഫിഗറേഷൻ പൊരുത്തക്കേടിനെ പ്രവർത്തിക്കുന്നെങ്കിലും സ്ഥിരീകരിക്കാത്ത ഒരു പാതയാക്കി മാറ്റുന്നു, ആ മാറ്റമാണ് താൽക്കാലിക പരീക്ഷണത്തെ സ്ഥിരമായ ദ്വാരമാക്കുന്നത്. Access Server-ന്റെ കണക്ഷൻ പ്രൊഫൈൽ ഡോക്യുമെന്റേഷൻ രണ്ട് തലമുറകളെയും താൽക്കാലിക പ്രൊഫൈൽ പ്രവാഹത്തെയും വിവരിക്കുന്നു, പ്രോക്സിയെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് പരിശോധിക്കേണ്ട റഫറൻസ് അതാണ്.
വസ്തു പുതിയതാകുമ്പോൾ: പകരം കൺട്രോൾ ചാനൽ വായിക്കുക
2.9 ശൈലിയിലുള്ള പ്രൊഫൈലിൽ ക്ലയന്റ് നേരിട്ട് നേറ്റീവ് VPN എൻഡ്പോയിന്റിലേക്ക് പോകുന്നു. പ്രൊഫൈലിലെ എൻഡ്പോയിന്റുകൾ, ഉപയോഗിക്കുന്ന ട്രാൻസ്പോർട്ട്, കൺട്രോൾ ചാനൽ പിശക് എന്നിവ അന്വേഷിക്കുക. ക്ലയന്റ് ഒരിക്കലും HTTP അഭ്യർത്ഥന നൽകുന്നില്ലെങ്കിൽ, അത് രൂപകൽപ്പനയോട് യോജിക്കുന്നു, ലക്ഷണമല്ല.
ഇവിടെ പ്രോക്സി ചോദ്യവും രൂപം മാറുന്നു. HTTPS ഇറക്കിവിടൽ ഒരിക്കലും കാണാത്ത TCP മാത്രം സ്ട്രീം തകർക്കാൻ കഴിയില്ല, പക്ഷേ പ്രൊഫൈൽ പ്രസിദ്ധീകരിക്കുന്ന ഡൗൺലോഡ് ഇപ്പോഴും തകർക്കാം, TCP മാത്രം ഫോർവാർഡർ UDP ഒട്ടും കൊണ്ടുപോകില്ല. ഫ്രണ്ട് എൻഡ് അപ്രസക്തമാണെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് പ്രൊഫൈൽ ഏത് ട്രാൻസ്പോർട്ട് ആവശ്യപ്പെടുന്നു എന്ന് പരിശോധിക്കുക.
ഒരു സ്ട്രീമിനുള്ള TLS പാസ്ത്രൂ സങ്കുചിതമായ ക്രമീകരണമാണ്. അത് UDP ഫോർവാർഡിംഗ് നൽകുന്നില്ല, 443-ലെ ഡീമണിന്റെ സ്വന്തം സേവന-ഫോർവാർഡിംഗ് സ്വഭാവം പുനർനിർമ്മിക്കുന്നുമില്ല. നിങ്ങളുടെ ഫ്രണ്ട് എൻഡ് അവയിലൊന്ന് ചെയ്യുന്നുണ്ടെങ്കിൽ ഏതെന്ന് പറയുക, കാരണം പരിഹാരം വ്യത്യസ്തമാണ്.
സങ്കുചിതമായി തുടരുന്ന പരിഹാരങ്ങൾ
ഏറ്റവും കുറഞ്ഞ ഇടപെടലുള്ള പരിശോധന ടെസ്റ്റ് അക്കൗണ്ടിനായി പുതിയ പിന്തുണയുള്ള പ്രൊഫൈൽ നിർമ്മിച്ച് അതേ പ്രാമാണീകരണ ആവശ്യകതകളോടെ ഉദ്ദേശിച്ച നേറ്റീവ് എൻഡ്പോയിന്റിലൂടെ കണക്റ്റ് ചെയ്യുകയാണ്. അത് പ്രവർത്തിക്കുകയും സൂക്ഷിച്ച പഴയ പ്രൊഫൈൽ പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്താൽ, ഒരു ഘട്ടത്തിൽ വസ്തുവിനെ സെർവറിൽ നിന്നും പ്രോക്സിയിൽ നിന്നും വേർതിരിച്ചു.
ഉപയോക്തൃ-ലോക്ക് പ്രൊഫൈലിന്റെ വിതരണം പരാജയപ്പെടാവുന്ന താൽക്കാലിക പ്രൊഫൈൽ കൈമാറ്റം ഇല്ലാത്തതിനാൽ പഴയ ബൂട്ട്സ്ട്രാപ്പ് ആശ്രിതത്വം പൂർണ്ണമായി നീക്കുന്നു. ഉദ്ദേശിച്ച ഉപയോക്താവിന് നൽകണം, ഒരിക്കലും അഡ്മിനിസ്ട്രേറ്ററിൽ നിന്ന് പകർത്തരുത്, ക്ലയന്റിന് അനുവദനീയമായത് ഇത് മാറ്റുന്നു, അതിനാൽ ഇതിനെ പ്രവർത്തന പരിഹാരമല്ല, നയ തീരുമാനമായി കാണുക.
തുടർന്ന് പ്രസിദ്ധീകരണ ക്രമീകരണം ഓരോ ആവശ്യമായ പാതയും ഉണ്ടാകുന്ന വിധത്തിൽ ശരിയാക്കുക: ഡൗൺലോഡുകൾക്കും പോർട്ടൽ ഉപയോഗത്തിനും വെബ് പാത, പ്രൊഫൈലുകൾ പ്രതീക്ഷിക്കുന്ന ട്രാൻസ്പോർട്ടിൽ നേറ്റീവ് VPN പാത. പ്രോക്സിയുടെ ജോലി ഒരു പാളിയിൽ നിർത്തുക. പ്രവർത്തിക്കുന്ന ഉപയോക്തൃ-ലോക്ക് ടണൽ ആ പാത പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു; എല്ലാ പ്രോക്സി ക്രമീകരണവും എല്ലാ തലമുറയെയും പിന്തുണയ്ക്കുന്നു എന്ന് തെളിയിക്കുന്നില്ല, പഴയ ബൂട്ട്സ്ട്രാപ്പ് പരാജയം പുതിയ ഫോർമാറ്റിനെ അപലപിക്കുന്നുമില്ല.
- പ്രോക്സിയെ സ്പർശിക്കുന്നതിന് മുമ്പ് വസ്തുവിന്റെ തലമുറ തിരിച്ചറിയുക.
- പരാജയം ടണലിന് മുമ്പോ അതിനുള്ളിലോ സംഭവിക്കുന്നു എന്ന് നിർണ്ണയിക്കുക.
- ഫ്രണ്ട് എൻഡ് എന്ത് അവസാനിപ്പിക്കുന്നു എന്ന് സ്ഥിരീകരിക്കുക: HTTP, TCP സ്ട്രീം, അല്ലെങ്കിൽ UDP.
- നയം മാറ്റാതെ പുതുതായി നൽകിയ പ്രൊഫൈൽ നേറ്റീവ് എൻഡ്പോയിന്റിനെതിരെ പരീക്ഷിക്കുക.