Squid വഴി ഒരു VPN എൻഡ്‌പോയിന്റ്: ഇടുങ്ങിയ CONNECT ഒഴിവാക്കൽ

Squid ഒരു CONNECT അഭ്യർത്ഥനയ്ക്ക് പൊരുത്തപ്പെടുന്ന ആദ്യ http_access വരിയിൽ ഉത്തരം നൽകുന്നു, ആ വരി നിരസിക്കലും ആകാം. ഈ ഒരു വസ്തുതയാണ് VPN എൻഡ്‌പോയിന്റിനുള്ള ഒഴിവാക്കൽ സാധാരണയായി ആദ്യ ശ്രമത്തിൽത്തന്നെ പരാജയപ്പെടുന്നതിന്റെ കാരണം വിശദീകരിക്കുന്നത്, കാരണം അഭ്യർത്ഥന താഴെ ആരോ ചേർത്ത അനുമതിയിൽ എത്തുന്നില്ല. ഇടുങ്ങിയ പരിഹാരം നിലവിലുള്ള പോർട്ട് ഗാർഡുകൾ നിലനിർത്തുകയും അവയ്ക്ക് ഒരു പരിശോധിച്ച ഉറവിടവും ലക്ഷ്യവും പോർട്ടും പഠിപ്പിക്കുകയും ചെയ്യുന്നു. പ്രോക്സിയിലെ മറ്റെല്ലാം മുമ്പത്തേതുപോലെത്തന്നെ പെരുമാറുന്നു.

Squid ഒരു CONNECT അഭ്യർത്ഥന എങ്ങനെ തീരുമാനിക്കുന്നു

CONNECT അഭ്യർത്ഥന ഒരു ഹോസ്റ്റും പോർട്ടും പേരിടുന്നു, Squid http_access വരികൾ ക്രമത്തിൽ സഞ്ചരിച്ച് അവയിലൊന്ന് പൊരുത്തപ്പെടുന്നതുവരെ തുടരുന്നു. പൊരുത്തപ്പെടുന്ന നിരസിക്കൽ വിലയിരുത്തൽ ഉടൻ അവസാനിപ്പിക്കുന്നു, ക്ലയന്റ് പ്രോക്സിയിൽ നിന്ന് 403 സ്വീകരിക്കുന്നു. അതുകൊണ്ടാണ് ഒരു നിയമത്തിന്റെ സ്ഥാനം അതിന്റെ രൂപത്തെക്കാൾ പ്രധാനമാകുന്നത്. അതേ വരി ഒരു പടി മുകളിലേക്ക് നീക്കുന്നത് ഫലം പൂർണമായി മാറ്റാം.

പരമ്പരാഗത ഗാർഡുകൾ Safe_ports-ന് പുറത്തുള്ള എല്ലാം നിരസിക്കുന്നു, SSL_ports-ന് പുറത്തുള്ള CONNECT നിരസിക്കുന്നു. ആ പേരുകൾ നിങ്ങളുടെ സ്വന്തം കോൺഫിഗറേഷനിൽ നിർവചിച്ച ACL-കളാണ്, അതിനാൽ അവയുടെ ഉള്ളടക്കം പ്രോട്ടോക്കോളിന്റതല്ല, നിങ്ങളുടേതാണ്. ഒരു വിതരണം Safe_ports ആയി വിശാലമായ പോർട്ട് ശ്രേണി അനുവദിച്ച് CONNECT പ്രത്യേകം പരിമിതപ്പെടുത്തിയേക്കാം. ഒരു പോർട്ട് രൂപകൽപന പ്രകാരം തടഞ്ഞിരിക്കുന്നു എന്ന് കരുതുന്നതിന് മുമ്പ് ജീവനുള്ള മൂല്യങ്ങൾ വായിക്കുക.

അഭ്യർത്ഥന നിരസിക്കുന്ന ഘടകം പ്രോക്സിയാണെന്ന് ഉറപ്പാക്കുക. Squid സൃഷ്ടിക്കുന്ന 403, VPN സെർവറിന്റെ TLS മുന്നറിയിപ്പിനോട് ഒട്ടും സാമ്യമുള്ളതല്ല, രണ്ടും ഒരു പ്രശ്നമാക്കി ചേർക്കുന്നത് ആദ്യ മണിക്കൂർ എടുക്കും. അഭ്യർത്ഥനയുടെ ആക്സസ് ലോഗ് വരി പരിശോധിക്കുക, കാരണം അത് പ്രവർത്തിയും അത് സൃഷ്ടിച്ച നിയമവും രേഖപ്പെടുത്തുന്നു.

മൂന്ന് വേർതിരിഞ്ഞ ACL-കൾക്ക് പകരം ഒരു സംയോജിത പൊരുത്തം നിർമ്മിക്കുക

ഒഴിവാക്കൽ മൂന്ന് വസ്തുതകളിൽ നിന്ന് നിർമ്മിക്കുക: അനുവദിച്ച ഉറവിട ശ്രേണി, ഒരു അനുവദിച്ച ലക്ഷ്യ വിലാസം, എൻഡ്‌പോയിന്റ് കേൾക്കുന്ന ഏക പോർട്ട്. രണ്ട് വേർതിരിഞ്ഞ ACL-കളും ഒരു സംയോജിത പൊരുത്തവും വളരെ വ്യത്യസ്ത നയം നൽകുന്നു, കാരണം വിലയിരുത്തുന്നത് സംയോജനമാണ്. സംയോജിത ACL-ന് അത് അനുവദിക്കുന്നതിന്റെ പേര് നൽകുക, അത് വഹിക്കുന്ന രീതിയുടെ പേരല്ല.

താഴെയുള്ള രൂപം പരിശോധിച്ച മൂല്യങ്ങളാൽ മാറ്റേണ്ട ഡോക്യുമെന്റേഷൻ ശ്രേണികൾ ഉപയോഗിക്കുന്നു. Squid ഈ പേരുകളൊന്നും സ്വയം സംവരണം ചെയ്യുന്നില്ല, അതിനാൽ അവ തിരഞ്ഞെടുക്കുന്നതും സ്ഥിരതയോടെ നിലനിർത്തുന്നതും നിങ്ങളുടെ ജോലിയാണ്. ഈ പാചകക്കുറിപ്പ് all-of ഗ്രൂപ്പ് പിന്തുണയ്ക്കുന്ന ഡോക്യുമെന്റഡ് കോൺഫിഗറേഷനുള്ള Squid 6, 7 എന്നിവയിൽ മാത്രം ഒതുങ്ങുന്നു. നിലവിലെ റഫറൻസ് ആ നിർദ്ദേശങ്ങളെ Squid 8-ൽ ലഭ്യമല്ലെന്ന് അടയാളപ്പെടുത്തുന്നു, അതിനാൽ ഇതിനെ കുടിയേറ്റ പാതയല്ലാതെ പതിപ്പ്-ബദ്ധമായ പാചകക്കുറിപ്പായി കാണുക, പ്രയോഗിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ സ്വന്തം പതിപ്പിന്റെ റഫറൻസിൽ നിർദ്ദേശം പരിശോധിക്കുക.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

ഓരോ അംഗവും പൊരുത്തപ്പെടുമ്പോൾ മാത്രമേ all-of ഗ്രൂപ്പ് പൊരുത്തപ്പെടുന്നുള്ളൂ, അതായത് ഉറവിടവും ലക്ഷ്യവും പോർട്ടും ഒരൊറ്റ വരിയിൽ പരിശോധിക്കപ്പെടുന്നു. ഗ്രൂപ്പ് സ്വയം ഒന്നും നൽകുന്നില്ല, മൂന്ന് വസ്തുതകളിൽ രണ്ടുമായി മാത്രം പൊരുത്തപ്പെടുന്ന അഭ്യർത്ഥന അതിനെ തൃപ്തിപ്പെടുത്താനാവില്ല. ഈ സ്വഭാവം പിന്നീട് ആരെങ്കിലും രണ്ടാമതൊരു ഗേറ്റ്‌വേ ചേർക്കുമ്പോൾ ഒഴിവാക്കൽ ഇടുങ്ങിയതായി നിലനിർത്തുന്നു. ഒന്നുകിൽ പുതിയ ലക്ഷ്യം ഉദ്ദേശ്യപൂർവം ചേർക്കുന്നു, അല്ലെങ്കിൽ അഭ്യർത്ഥന യഥാർത്ഥ ഗാർഡുകളിലേക്ക് തിരികെ വരുന്നു.

പോർട്ട് ഗാർഡുകൾ നീക്കം ചെയ്യാതെ അവയെ വളയ്ക്കുക

അവയുടെ നിലവിലെ സ്ഥാനങ്ങളിൽ, രണ്ട് പരമ്പരാഗത ഗാർഡ് വരികൾ ഇങ്ങനെ കാണപ്പെടുന്നു. അവ സാധാരണയായി പ്രാമാണീകരണത്തിന് ശേഷവും എല്ലാം അനുവദിക്കുന്ന നയ വരികൾക്ക് മുമ്പും സ്ഥിതി ചെയ്യുന്നു.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

ഓരോന്നിനും നിഷേധിച്ച സംയോജിത പൊരുത്തം ചേർക്കുക, അങ്ങനെ പൊരുത്തപ്പെടുന്ന ഒഴിവാക്കൽ അല്ലാത്തപക്ഷം അതിനെ നിരസിക്കുമായിരുന്ന ഗാർഡിനെ അതിജീവിക്കുന്നു. ഗാർഡ് വരികൾ മാത്രം മാറുന്നു, ഓരോന്നിനും ഒരു അധിക വ്യവസ്ഥ മാത്രം ചേർക്കുന്നു.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

ഒരു ആക്സസ് വരിയിലെ വ്യവസ്ഥകൾ സംയോജിക്കുന്നു, അതിനാൽ ഇപ്പോൾ യഥാർത്ഥ പരിശോധനയിലും ഒഴിവാക്കലിലും ഒരുപോലെ പരാജയപ്പെടുന്ന അഭ്യർത്ഥനകൾ മാത്രമേ വരി നിരസിക്കുന്നുള്ളൂ. അനുവദിച്ച എൻഡ്‌പോയിന്റിലേക്കുള്ള അഭ്യർത്ഥന കടന്നുപോകുന്നു, മറ്റെല്ലാ അഭ്യർത്ഥനകളും പഴയ പോർട്ട് പെരുമാറ്റം നിലനിർത്തുന്നു. ഇത് പോർട്ട് ആഗോള SSL_ports പട്ടികയിൽ ചേർക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയതാണ്, അത് ആ പോർട്ട് എല്ലാ ലക്ഷ്യത്തിനും അനുവദിക്കുമായിരുന്നു. പോർട്ട് ആ പട്ടികയിൽ ഇതിനകം ഉണ്ടെങ്കിൽ, ഈ ACL ഒന്നും ഇടുങ്ങിയതാക്കുന്നില്ല, പഴയതും വിശാലവുമായ അനുമതി മറ്റ് ലക്ഷ്യങ്ങൾക്ക് ഇപ്പോഴും ബാധകമാണ്, അതിനാൽ ഒഴിവാക്കൽ പോർട്ട് തുറന്നു എന്ന് അവകാശപ്പെടുന്നതിന് മുമ്പ് ജീവനുള്ള പട്ടിക വായിക്കുക. ഇത് പഴയപടിയാക്കാനും കഴിയും, കാരണം രണ്ട് വരികൾ അവയുടെ മുൻ രൂപത്തിലേക്ക് മടങ്ങുന്നു. ആക്സസ് നിയന്ത്രണ റഫറൻസ് ഈ മാറ്റം ആശ്രയിക്കുന്ന ക്രമവും പരമ്പരാഗത ഗാർഡുകളും രേഖപ്പെടുത്തുന്നു.

ഒഴിവാക്കൽ എവിടെ സ്ഥാപിക്കാൻ പാടില്ല

ഗാർഡുകൾക്ക് മുകളിൽ ഒരു അനുമതി വച്ച് തീർക്കാനാണ് പ്രലോഭനം. ആ സ്ഥാനം പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷന്റെ മുകൾഭാഗത്തിന് സമീപം സ്ഥിതി ചെയ്യുന്ന പ്രാമാണീകരണ, പ്രാദേശിക ലക്ഷ്യ സംരക്ഷണങ്ങളും ഒഴിവാക്കുന്നു. ഫലം ഇടുങ്ങിയ ഒഴിവാക്കലല്ല, മുകളിൽ ഒരു കുറിപ്പുള്ള ദ്വാരമാണ്. കേന്ദ്രീകൃത നയത്തിന്റെ ബാക്കി ഭാഗത്തിന്റെ അതേ പരിശോധിച്ച ഘട്ടത്തിൽ ഏത് പുതിയ അനുമതിയും നിലനിർത്തുക.

പോർട്ട് ഗാർഡുകൾക്ക് ശേഷം അഭ്യർത്ഥനയ്ക്ക് ഇനിയും എന്ത് വേണമെന്ന് പരിശോധിക്കുക. പ്രാമാണീകരിച്ച അക്കൗണ്ട്, അനുവദിച്ച ക്ലയന്റ് വിലാസം, ലക്ഷ്യ നയം എന്നിവയെല്ലാം ഇപ്പോഴും ബാധകമാണ്, ഒഴിവാക്കൽ അവയൊന്നും മാറ്റുന്നില്ല. നിങ്ങളുടെ പ്രോക്സി അനുവദിച്ച അക്കൗണ്ടിനെ ഇതിനകം ഏകപക്ഷീയ ലക്ഷ്യങ്ങളിൽ എത്താൻ അനുവദിക്കുന്നുണ്ടെങ്കിൽ, പോർട്ട് ഗാർഡ് ഒരിക്കലും യഥാർത്ഥ നിയന്ത്രണമായിരുന്നില്ല.

എൻഡ്‌പോയിന്റ് ഒട്ടും TCP ആണോ എന്ന് ചിന്തിക്കുക. CONNECT ഒഴിവാക്കൽ TCP സ്ട്രീമുകൾ വഹിക്കുന്നു, UDP ഉപയോഗിക്കുന്ന OpenVPN പ്രൊഫൈൽ അതിലൂടെ ലഭ്യമാകില്ല. സെർവർ അങ്ങനെ കേൾക്കുന്നുവെങ്കിലും ഓപ്പറേറ്റർ പെരുമാറ്റ വ്യത്യാസം അംഗീകരിക്കുന്നുവെങ്കിലും മാത്രം പ്രൊഫൈൽ TCP-യിലേക്ക് മാറ്റുക.

പാർസറും യഥാർത്ഥ അഭ്യർത്ഥനയും കൊണ്ട് അതിർത്തി പരിശോധിക്കുക

വീണ്ടും ലോഡ് ചെയ്യുന്നതിന് മുമ്പ് കോൺഫിഗറേഷൻ പാർസ് ചെയ്യുക, അത് ചെയ്യുമ്പോൾ രണ്ടാമതൊരു സെഷൻ തുറന്നിടുക. വീണ്ടും ലോഡ് ചെയ്യുമ്പോഴുള്ള വാക്യഘടനാ പിശക് പ്രോക്സിയെ പഴയ കോൺഫിഗറേഷനിൽ വിടാം അല്ലെങ്കിൽ പുതിയത് പൂർണമായി നിരസിക്കാം. പാർസർ നിരസിച്ച വരി റിപ്പോർട്ട് ചെയ്യുന്നു, ക്ലയന്റ് പിശക് പറയുന്നതിനേക്കാൾ അധികം.

തുടർന്ന് വീണ്ടും ലോഡ് ചെയ്ത് അനുവദിച്ച ഉറവിടത്തിൽ നിന്ന് പ്രോക്സി വഴി ഒരു യഥാർത്ഥ CONNECT അയയ്ക്കുക. പാർസർ ഓടിക്കുന്നത് ആദ്യം വരുന്നു, കാരണം ടൈപ്പിംഗ് പിശകോടെയുള്ള വീണ്ടും ലോഡ് നയത്തെക്കുറിച്ച് ഒന്നും പഠിപ്പിക്കുന്നില്ല.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

മൂന്ന് സന്ദർഭങ്ങൾ പരീക്ഷിക്കുക: അനുവദിച്ച ഉറവിടവും അക്കൗണ്ടും, അനുവദിക്കാത്ത ഉറവിടം, അതേ പോർട്ടിലെ വ്യത്യസ്ത ലക്ഷ്യം. ഒഴിവാക്കൽ ഇടുങ്ങിയതാണെന്ന് തെളിയിക്കുന്നത് മൂന്നാമത്തെ സന്ദർഭമാണ്, കാരണം അത് ലക്ഷ്യ പൊരുത്തമില്ലാതെ പോർട്ട് പരീക്ഷിക്കുന്നു. ക്ലയന്റ് സന്ദേശത്തെ വിശ്വസിക്കുന്നതിന് പകരം മൂന്നിനും ആക്സസ് ലോഗ് വായിക്കുക. വിജയകരമായ CONNECT ഒരു TCP സ്ട്രീം മാത്രം സ്ഥാപിക്കുന്നു, അതിൽ കൂടുതലില്ല, അതിനാൽ VPN ഹാൻഡ്‌ഷേക്ക് വേറിട്ട പരീക്ഷണമായി തുടരുന്നു.