പങ്കിട്ട TAP VPN-ന് പോർട്ടലിൽ ഇപ്പോഴും HTTPS എന്തിന് വേണം
TAP VPN പിയറെ സാക്ഷ്യപ്പെടുത്തുന്നു, അതിന് പിന്നിലുള്ള സേവനത്തെയല്ല. പോർട്ടലിൽ ഹോസ്റ്റ്നാം സ്ഥിരീകരണം നിലനിർത്തി നിങ്ങൾ വിശ്വസിക്കാത്ത അയൽക്കാരെ ഒറ്റപ്പെടുത്തുക.
രണ്ട് ഉപകരണങ്ങൾക്ക് സാധുവായ VPN ക്രെഡൻഷ്യലുകൾ ഉണ്ട്, അവ ഒരു ബ്രിഡ്ജ് ചെയ്ത Ethernet സെഗ്മെന്റ് പങ്കിടുന്നു. അവയിൽ ഒന്ന് മാത്രമാണ് ഓഫീസ് പോർട്ടലിനായി മറുപടി നൽകേണ്ടത്, മറ്റൊന്നിന് ഇപ്പോഴും ആ സെഗ്മെന്റിൽ പോർട്ടലിന്റെ വിലാസം അവകാശപ്പെടാനാകും. ടണൽ അതിന്റെ ജോലി ചെയ്തു: അത് രണ്ട് പിയറുകളെയും സാക്ഷ്യപ്പെടുത്തി സർവറിലേക്കുള്ള ഓരോ പാതയും എൻക്രിപ്റ്റ് ചെയ്തു. ചെയ്യാതിരുന്നത് അവരിൽ ആർക്കാണ് സേവനനാമം ഉള്ളതെന്ന് സാക്ഷ്യപ്പെടുത്തുകയാണ്, ആ വിടവാണ് പോർട്ടലിന് ഇപ്പോഴും സാധുവായ സർട്ടിഫിക്കറ്റ് വേണ്ടതിന്റെ കാരണം.
VPN യഥാർത്ഥത്തിൽ എന്താണ് സാക്ഷ്യപ്പെടുത്തുന്നത്
VPN ഹാൻഡ്ഷേക്ക് ഒരു ചോദ്യത്തിന് മറുപടി നൽകുന്നു: ഏത് പിയർ ഏത് കീ മെറ്റീരിയലുമായി ഈ ടണൽ പൂർത്തിയാക്കി. ആ മറുപടി ഓരോ പിയറിനും ഓരോ കണക്ഷനും ബാധകമാണ്, ആ പിയർ പിന്നീട് നൽകുന്ന സേവനങ്ങളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. TAP സെഗ്മെന്റിൽ പിയർ ഒരു വിലാസം പോലുമല്ല, കാരണം ബ്രിഡ്ജ് പഠിക്കാൻ തയ്യാറായ ഏത് MAC യും ഏത് IP യും അത് അവതരിപ്പിക്കാം. സാക്ഷ്യപ്പെടുത്തൽ ടണലിന്റെ അറ്റത്ത് നിലയ്ക്കുന്നു, ആപ്ലിക്കേഷനിൽ അല്ല.
മൂന്ന് ചോദ്യങ്ങളെ ഒന്നായി ചേർക്കുന്നതിന് പകരം വേർതിരിക്കുക. ഓരോന്നിനും സ്വന്തം സംവിധാനവും സ്വന്തം പരാജയരീതിയും ഉണ്ട്.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
ഒരു വിന്യാസത്തിൽ തികച്ചും സാക്ഷ്യപ്പെടുത്തിയ ടണലും അതിന് പിന്നിൽ പൂർണ്ണമായും സാക്ഷ്യപ്പെടുത്താത്ത സേവനവും ഉണ്ടാകാം. രണ്ടാം പാളിയിലെ വിലാസം മറ്റൊരു പിയർ അവകാശപ്പെടുന്ന ഹോസ്റ്റിൽ സ്ഥിരീകരിച്ച സർട്ടിഫിക്കറ്റുമുണ്ടാകാം, അതിനാൽ രൂപകൽപ്പനയിൽ ഒന്ന് മറ്റൊന്നിനെ മാറ്റിസ്ഥാപിക്കുന്നതിന് പകരം രണ്ട് നിയന്ത്രണങ്ങളും ഉണ്ടായിരിക്കണം. പട്ടിക മൂന്ന് വരികളിൽ മുഴുവൻ വാദമാണ്.
പങ്കിട്ട സെഗ്മെന്റിൽ ARP ഒരു ഡയറക്ടറിയല്ല
ARP ലോക്കൽ ലിങ്കിൽ ഒരു IPv4 വിലാസത്തെ MAC ലേക്ക് മാപ്പ് ചെയ്യുന്നു, ആ ലിങ്കിലുള്ള ആരിൽ നിന്നും മറുപടികൾ സ്വീകരിക്കുന്നു. അനുവദനീയമായ ബ്രിഡ്ജ് ചെയ്ത സെഗ്മെന്റിൽ ഒരു പിയറിന് മറ്റൊരു ഉപകരണത്തിനുള്ള വിലാസം അവകാശപ്പെടാം, ബ്രിഡ്ജ് ഫ്രെയിമുകൾ അവസാനം മറുപടി നൽകിയവർക്ക് അയയ്ക്കുന്നു. സർവറിലേക്കുള്ള ഓരോ ക്ലയന്റ് പാതയും എൻക്രിപ്റ്റ് ചെയ്യുന്നത് അത് മാറ്റുന്നില്ല, കാരണം ഫ്രെയിമുകൾ ബ്രിഡ്ജിൽ എത്തുന്നതിന് മുമ്പ് ഡീക്രിപ്റ്റ് ചെയ്യുന്നു. ARP-യുടെ വിശ്വാസ അതിർത്തി ടണലല്ല, സെഗ്മെന്റാണ്.
ഹോസ്റ്റ് യഥാർത്ഥത്തിൽ എന്താണ് പഠിച്ചതെന്ന് നോക്കുക: ip neigh show നിലവിലെ മാപ്പിംഗുകളും അവയുടെ അവസ്ഥയും പട്ടികപ്പെടുത്തുന്നു, സാധാരണ പ്രവർത്തനത്തിൽ രണ്ട് MAC വിലാസങ്ങൾക്കിടയിൽ മാറുന്ന എൻട്രി അവഗണിക്കുന്നതിന് പകരം അന്വേഷിക്കേണ്ട ലക്ഷണമാണ്. ആരോഗ്യകരമായ ചെറിയ സെഗ്മെന്റിൽ അത്തരം എൻട്രികൾ വളരെക്കാലം സ്ഥിരമായി നിലനിൽക്കും.
പിയർ ഒറ്റപ്പെടുത്തലും ബ്രിഡ്ജ് നയവും കൃത്യമായി ഈ സാഹചര്യത്തിനാണ്. സേവനം IP മാത്രവും ഉപകരണങ്ങൾക്ക് പരസ്പരം ഫ്രെയിമുകൾ കാണാൻ യാതൊരു കാരണവുമില്ലാത്തതുമായ സാഹചര്യത്തിൽ റൂട്ട് ചെയ്ത രൂപകൽപ്പനയാണ് സാധാരണയായി മികച്ച മറുപടി.
സർട്ടിഫിക്കറ്റ് സ്ഥിരീകരണം സേവനം ഉള്ളിടത്ത് നിലനിർത്തുക
ആപ്ലിക്കേഷന്റെ TLS ടണലിന് നൽകാനാകാത്ത ചോദ്യത്തിന് മറുപടി നൽകുന്നു: ഞാൻ എത്തിച്ചേരാൻ ഉദ്ദേശിച്ച സേവനം ഇതാണോ. ബ്രൗസർ ഹോസ്റ്റ്നാം സർട്ടിഫിക്കറ്റുമായി പരിശോധിക്കുന്നു, ആ പരിശോധന മാത്രമാണ് ചങ്ങലയിൽ പിയറിനെയല്ല പോർട്ടലിനെ പേരിടുന്ന ഭാഗം.
മുന്നറിയിപ്പ് വെറും പുറംമോടിയാണെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് സർവർ എന്താണ് അവതരിപ്പിക്കുന്നതെന്ന് പരിശോധിക്കുക. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal ചങ്ങലയും വിഷയത്തിന്റെ ഇതരനാമങ്ങളും പ്രിന്റ് ചെയ്യുന്നു. നിങ്ങൾ ടൈപ്പ് ചെയ്ത പേര് ആ പട്ടികയിലില്ലെങ്കിൽ മുന്നറിയിപ്പ് ശരിയാണ്, ശരിയാക്കേണ്ടത് സർട്ടിഫിക്കറ്റാണ്. ഉപയോക്താക്കളെ അത് മറികടക്കാൻ പഠിപ്പിക്കുന്നത് പ്രവർത്തിക്കുന്ന ഒരു നിയന്ത്രണത്തെ അലങ്കാരമാക്കി മാറ്റുന്നു.
OpenVPN ബ്രിഡ്ജിംഗ് ഗൈഡ് Ethernet മാതൃകയും അതിന് ചുറ്റുമുള്ള നയ ഓപ്ഷനുകളും വിവരിക്കുന്നു, സെഗ്മെന്റ് എന്ത് അനുവദിക്കണം എന്നതിനുള്ള ശരിയായ റഫറൻസ് അതാണ്. ബ്രിഡ്ജ് നിയമം അയച്ചുവിടുന്നതിന് മുമ്പ് അത് വായിക്കുക, കാരണം അത് വിവരിക്കുന്ന മാതൃകയാണ് മുകളിലെ ഓരോ പരിശോധനയും അനുമാനിക്കുന്നത്.
ആ പിയറുകൾ ഒരു സെഗ്മെന്റ് പങ്കിടണോ എന്ന് തീരുമാനിക്കുക
ആവശ്യകത IP എത്തിച്ചേരൽ മാത്രമായിരിക്കുമ്പോൾ രണ്ടാം പാളി പങ്കിടുന്നത് നിർത്തുന്നതാണ് സാധാരണയായി ഏറ്റവും വിലകുറഞ്ഞ പരിഹാരം. റൂട്ട് ചെയ്ത VPN ഓരോ ക്ലയന്റിനും സ്വന്തം വിലാസം നൽകുന്നു, പങ്കിട്ട ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ നീക്കം ചെയ്യുന്നു, പിയറുകൾക്കിടയിലുള്ള ട്രാഫിക്കിനെ സ്ഥിരമായ മൂല്യത്തിന് പകരം നയ തീരുമാനമാക്കി മാറ്റുന്നു. അപ്പോൾ പോർട്ടലിന് സംരക്ഷിക്കാൻ ഒരു വിലാസം മാത്രം, അത് അവകാശപ്പെടാവുന്ന അയൽക്കാരുമില്ല.
സെഗ്മെന്റ് നിലനിൽക്കണമെങ്കിൽ, ക്ലയന്റുകൾ പരസ്പരം എത്താൻ അനുവദിക്കുന്ന സർവർ-സൈഡ് ക്രമീകരണം പരിശോധിക്കുക: grep -n client-to-client /etc/openvpn/server.conf. അത് പ്രവർത്തനരഹിതമാകുമ്പോൾ ക്ലയന്റ് ട്രാഫിക് സർവറിലൂടെ കടന്നുപോകുന്നു, അവിടെ ഫിൽട്ടർ ചെയ്യാം. അത് പ്രവർത്തനക്ഷമമാകുമ്പോൾ പിയറുകൾ ബ്രിഡ്ജിലൂടെ നേരിട്ട് ഫ്രെയിമുകൾ കൈമാറുന്നു, നിങ്ങളുടെ ഫിൽട്ടറിംഗ് പോയിന്റുകൾ ബ്രിഡ്ജും ഹോസ്റ്റ് ഫയർവാളുമാണ്.
ഓരോ ഹോസ്റ്റും യഥാർത്ഥത്തിൽ ഏത് സംരക്ഷണങ്ങളെ ആശ്രയിക്കുന്നു എന്ന് എഴുതുക: ടണൽ സാക്ഷ്യപ്പെടുത്തൽ, സെഗ്മെന്റ് ഒറ്റപ്പെടുത്തൽ അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ TLS. മൂന്നിനെയും ആശ്രയിക്കുന്ന ഹോസ്റ്റ് കുഴപ്പമില്ല. ആദ്യത്തേതിനെ ആശ്രയിച്ച് ബാക്കിയുള്ള രണ്ടും അതിനൊപ്പം വന്നുവെന്ന് അനുമാനിക്കുന്ന ഹോസ്റ്റാണ് ഒടുവിൽ തെറ്റായ ഉള്ളടക്കം നൽകുന്നത്.