രണ്ട് DNS നാമങ്ങൾ, ഒരു OpenVPN പോർട്ട്: യഥാർത്ഥത്തിൽ എന്താണ് തിരഞ്ഞെടുക്കുന്നത്

രണ്ട് A റെക്കോർഡുകൾ, ഒരു വിലാസം, ഒരു ഡീമൺ: ഉപയോക്താവ് ഏത് നാമം ടൈപ്പ് ചെയ്താലും എത്തുന്ന പാക്കറ്റ് ഒരുപോലെയാണ്, 1194 പോർട്ടിലേക്ക് ബന്ധിച്ച പ്രോസസ്സിന് രണ്ടിനെയും വേർതിരിക്കാൻ ഒന്നുമില്ല. ഇത് പരിഹാരത്തിനായി കാത്തിരിക്കുന്ന തെറ്റായ കൺഫിഗറേഷനല്ല; ഇത് നാമ-തിരയൽ പ്രകടിപ്പിക്കാൻ കഴിയുന്നതിന്റെ പരിധിയാണ്. രണ്ട് OpenVPN ഇൻസ്റ്റൻസുകൾക്കിടയിൽ തിരഞ്ഞെടുക്കുന്ന എന്തും ക്ലയന്റ് കണക്ഷനിൽ ഇടുന്നതും മുൻഭാഗം തിരികെ വായിക്കാൻ കഴിയുന്നതുമായ ഒരു മൂല്യമായിരിക്കണം, സാധാരണ OpenVPN ക്ലയന്റ് അത്തരം മൂല്യം തുറന്ന് ഇടുന്നില്ല. തുടർന്ന് വരുന്നത് ഇത് നിങ്ങളെ എവിടെ നിർത്തുന്നു, ഏത് ക്രമീകരണങ്ങൾ ട്രാഫിക് യഥാർത്ഥത്തിൽ വേർതിരിക്കുന്നു എന്നതാണ്.

റിസോൾവർ തിരികെ നൽകുന്നതിൽ നിന്ന് തുടങ്ങുക

ക്ലയന്റ് vpn-a.example ചോദിച്ച് ഒരു വിലാസം നേടുന്നു; ആ വിലാസവും ഒരു പോർട്ടും ചേർന്നതാണ് അത് ഡയൽ ചെയ്യുന്നത് മുഴുവൻ. നാമം തിരയലിനിടയിൽ പ്രാദേശികമായി ചെലവഴിക്കപ്പെടുന്നു, ഒരിക്കലും വയറിൽ ഒരു ഫീൽഡായി മാറുന്നില്ല, അതിനാൽ മറുവശത്തെ ശ്രോതാവിന് ഏത് ലേബൽ ഉപയോഗിച്ചു എന്ന് കാണാൻ കഴിയില്ല. vpn-a.example ഉം vpn-b.example ഉം ഒരേ ഹോസ്റ്റിലേക്ക് ചൂണ്ടിക്കാണിക്കുക, രണ്ട് തിരയലുകളും ഒരേ ലക്ഷ്യം നൽകും, അതുകൊണ്ടാണ് ഡീമൺ ഒരു വ്യത്യാസവും രേഖപ്പെടുത്താതെ രണ്ട് കണക്ഷനുകളെയും ഒരു ഇൻസ്റ്റൻസിലേക്ക് വലിച്ചെടുക്കുന്നത്. വിലാസാധിഷ്ഠിത പ്രൊഫൈലുകൾ അതേ കാരണത്താൽ നാമാധിഷ്ഠിത പ്രൊഫൈലുകളെപ്പോലെ പ്രവർത്തിക്കുന്നു.

ഇത് പ്രലോഭനീയമായ വഴിത്തിരിവുകളുടെ ഒരു കുടുംബത്തെയും അടയ്ക്കുന്നു: അധിക ഓമനപ്പേരുകൾ, ഒരു സോക്കറ്റിൽ ഓരോ നാമത്തിനും സർട്ടിഫിക്കറ്റ് തിരഞ്ഞെടുക്കൽ, അല്ലെങ്കിൽ ചോദിച്ച നാമത്തിൽ ബന്ധിപ്പിച്ച ഫയർവാൾ നിയമം. ആദ്യ പാക്കറ്റ് ക്ലയന്റ് വിടുന്നതിന് മുൻപ് ഉപേക്ഷിക്കപ്പെട്ട വിവരത്തിൽ ഇവയൊന്നും പ്രവർത്തിക്കാൻ കഴിയില്ല. രണ്ട് സെർവറുകൾ വേർതിരിഞ്ഞു തന്നെ നിൽക്കണമെങ്കിൽ, വിഭജനം കണക്ഷനോടൊപ്പം തന്നെ സഞ്ചരിക്കണം, അതായത് ഒരു വിലാസം, ഒരു പോർട്ട്, അല്ലെങ്കിൽ പ്രോട്ടോക്കോൾ നിർവചിക്കുന്ന പേലോഡ് ഫീൽഡ്.

എണ്ണത്തിൽ വരുന്ന ഏക തിരഞ്ഞെടുക്കൽ പാക്കറ്റിനുള്ളിലൂടെ സഞ്ചരിക്കുന്നു

HTTP ഇത് Host ഹെഡർ കൊണ്ട് കൈകാര്യം ചെയ്യുന്നു, TLS ClientHello-ലെ സെർവർ നാമ വിപുലീകരണം കൊണ്ട്, അങ്ങനെ ഒരു വിലാസം ഒരു ശ്രോതാവിന്റെ പിന്നിൽ നിരവധി സൈറ്റുകൾക്ക് സേവനം നൽകുന്നു. രണ്ടും പ്രവർത്തിക്കുന്നത് വയറിലെ പ്രോട്ടോക്കോൾ ഒരു നിർദ്ദിഷ്ട സേവനത്തിനുള്ള അഭ്യർത്ഥന വഹിക്കുന്നതുകൊണ്ടാണ്. OpenVPN-നെക്കുറിച്ചുള്ള പ്രസക്തമായ വസ്തുത, ഇടനില പെട്ടി പരിശോധിക്കുന്ന പാളിയിൽ ഈ രണ്ട് ഫീൽഡുകളിൽ ഒന്നും ഇല്ല എന്നതാണ്.

സാധാരണ ക്രമീകരണത്തിൽ നിയന്ത്രണ ചാനൽ സംരക്ഷിക്കുന്ന TLS ഹാൻഡ്ഷേക്ക് പുറം സെഷൻ സ്ഥാപിച്ചതിന് ശേഷം സംഭവിക്കുന്നു, അതിനുള്ളിൽ വഹിക്കപ്പെടുന്നു, അതിനാൽ ആ സെഷൻ അവസാനിപ്പിക്കാത്ത ശ്രോതാവിന് അതാര്യമായ ഒരു സ്ട്രീം കാണാം. ഇത് ഇപ്പോഴും OpenVPN ആണെന്ന് പറയാൻ കഴിയും, കാരണം തുടക്ക ബൈറ്റുകളിലെ ഓപ്കോഡും ഫ്രെയിമിംഗും തിരിച്ചറിയാവുന്നതാണ്, പക്ഷേ സെർവർ നാമം ഉണ്ടെങ്കിൽ അത് എൻക്രിപ്റ്റ് ചെയ്ത ഭാഗത്ത് ഇരിക്കുന്നു. പുറം പാക്കറ്റിൽ നിന്ന് വെർച്വൽ ഹോസ്റ്റ് വായിക്കാൻ പ്രതീക്ഷിക്കുന്ന രൂപകൽപ്പന പ്രോട്ടോക്കോൾ ഒരിക്കലും അവിടെ എഴുതാത്ത ഒരു ഫീൽഡ് വായിക്കുന്നു. ഇത് ടണൽ എങ്ങനെ നിർമ്മിച്ചു എന്നതിൽ നിന്ന് വരുന്നു, മികച്ച പാറ്റേൺ പൊരുത്തപ്പെടുത്തൽ അടയ്ക്കാൻ കഴിയുന്ന വിടവിൽ നിന്നല്ല.

പ്രോട്ടോക്കോൾ വിഭജകൻ എവിടെ നിൽക്കുന്നു

sslh പ്രോജക്റ്റ് രേഖപ്പെടുത്തുന്ന തരത്തിലുള്ള മൾട്ടിപ്ലക്സർ ഒരു പോർട്ടിൽ കേൾക്കുന്നു, തുടക്ക ബൈറ്റുകൾ പരിശോധിക്കുന്നു, തിരിച്ചറിഞ്ഞ പ്രോട്ടോക്കോൾ സംസാരിക്കുന്ന ഏത് ബാക്കെൻഡിനും കണക്ഷൻ കൈമാറുന്നു. ഒരു പോർട്ട് SSH, HTTPS, OpenVPN എന്നിവയ്ക്ക് ഒരുമിച്ച് സേവനം നൽകേണ്ടിവരുമ്പോൾ ഇത് യഥാർത്ഥ മൂല്യമാണ്.

sslh ഓരോ പ്രോട്ടോക്കോളിനും വെവ്വേറെ പ്രോബ് സൂക്ഷിക്കുന്നു, അതിന്റെ TLS പ്രോബിന് യഥാർത്ഥ ClientHello-ൽ നിന്ന് സെർവർ നാമമോ ALPN മൂല്യമോ വലിച്ചെടുക്കാൻ കഴിയും. സാധാരണ OpenVPN തിരിച്ചറിയുന്നത് TLS വിപുലീകരണം വായിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ വർഗ്ഗീകരണമാണ്, രണ്ടും ഒരുമിച്ചു ചേരുന്നില്ല, കാരണം കേൾക്കുന്ന സോക്കറ്റിലേക്ക് ഒരിക്കലും ClientHello അയയ്ക്കാത്ത ക്ലയന്റ് പ്രോബിനെ വായിക്കാൻ ഒന്നുമില്ലാതെ വിടുന്നു. അതിനാൽ OpenVPN-മായി പൊരുത്തപ്പെടുന്ന നിയമം “ഇത് ഒരു OpenVPN ക്ലയന്റാണ്” എന്ന് ഉത്തരം നൽകി മുന്നോട്ട് പോകുന്നില്ല. ആ നിയമത്തിന് പിന്നിലെ രണ്ട് OpenVPN ബാക്കെൻഡുകളെ വേർതിരിക്കാൻ കഴിയില്ല, മുൻഭാഗത്തിന് തിരഞ്ഞെടുപ്പിന് അടിസ്ഥാനമില്ല, ഓരോ സെഷനും ഒരേ സ്ഥലത്ത് ഇറങ്ങുന്നു. മൾട്ടിപ്ലക്സിംഗ് ഒരു പോർട്ട് വിവിധ സേവനങ്ങൾക്കിടയിൽ പങ്കിടുന്നു; അത് ഒരു സേവനത്തിനുള്ളിൽ വെർച്വൽ ഹോസ്റ്റിംഗ് ചെയ്യുന്നില്ല.

രണ്ട് സെർവറുകളെ യഥാർത്ഥത്തിൽ വേർതിരിക്കുന്ന ക്രമീകരണങ്ങൾ

ഏറ്റവും വിലകുറഞ്ഞ സത്യസന്ധമായ വിഭജനം രണ്ടാമതൊരു പൊതു വിലാസമാണ്, ഓരോ ഇൻസ്റ്റൻസിനും ഒന്ന്, നിലവിലുള്ള പ്രൊഫൈലുകൾ ആവശ്യമായത് ഇതിനകം വഹിക്കുന്നു, കാരണം അവ വ്യത്യസ്ത വിലാസങ്ങളിലേക്ക് ചൂണ്ടുന്നു. അടുത്തത് അതേ വിലാസത്തിൽ വ്യത്യസ്ത പോർട്ടാണ്, അത് ഓരോ പ്രൊഫൈലിലും ഒരു സംഖ്യയല്ലാതെ മറ്റൊന്നും ചെലവാക്കുന്നില്ല. TCP-യും UDP-യും വെവ്വേറെ പോർട്ട് പട്ടികകൾ സൂക്ഷിക്കുന്നു, അതിനാൽ 1194/tcp ഉം 1194/udp ഉം ബന്ധമില്ലാത്ത സോക്കറ്റുകളാണ്, ഓരോന്നിൽ നിന്നും ഒന്ന് ഒരേ ഹോസ്റ്റിൽ ഒരുമിച്ച് നിൽക്കാം; ഇത് ഗതാഗത വിഭജനമാണ്, നാമാധിഷ്ഠിത റൂട്ടിംഗല്ല, പലപ്പോഴും അതുമായി തെറ്റിദ്ധരിക്കപ്പെടുന്നു. രണ്ട് ഓപ്ഷനുകളും ഫയർവാൾ അവലോകനം കടക്കുന്നു, കാരണം നിയമം പാക്കറ്റിൽ യഥാർത്ഥത്തിൽ ഉള്ളതുമായി പൊരുത്തപ്പെടുന്നു.

നിങ്ങൾക്ക് ആവശ്യമായ അതിർത്തി രണ്ട് നടപ്പാക്കലുകൾക്കിടയിലല്ല, ഉപയോക്തൃ ഗ്രൂപ്പുകൾക്കിടയിലാണ് കടക്കുന്നതെങ്കിൽ, വ്യത്യസ്ത ക്ലയന്റ് കോൺഫിഗറേഷനുകളും സ്വന്തം സർട്ടിഫിക്കറ്റ് കൈകാര്യവും വ്യക്തമായ ആക്സസ് നയവുമുള്ള ഒരു ഇൻസ്റ്റൻസിന് അത് മൂടാനാകും. അത് വാങ്ങുന്നത് സെർവറിനുള്ളിലെ നയമാണ്, സെർവറുകൾക്കിടയിലെ ഒറ്റപ്പെടുത്തലല്ല, രണ്ടും വ്യത്യസ്ത ആവശ്യകതകളാണ്. വിട്ടുവീഴ്ചയ്ക്കിടയിലും നിൽക്കേണ്ട ഒറ്റപ്പെടുത്തലിന് ഇപ്പോഴും വിലാസമോ ഫയർവാൾ അതിരോ വേണം.

OpenVPN-ന്റെ മുന്നിൽ വയ്ക്കുന്ന TLS ടെർമിനേറ്റർക്ക് കഴിവുള്ള മുൻഭാഗത്തിന് യഥാർത്ഥ സെർവർ നാമം വെളിപ്പെടുത്താൻ കഴിയും, പക്ഷേ ക്ലയന്റ് ഭാഗവും ആ അധിക പാളിക്കായി കോൺഫിഗർ ചെയ്തിട്ടുണ്ടെങ്കിൽ മാത്രം. നിലവിലുള്ള പ്രൊഫൈലുകൾ അതേ വിലാസത്തിലേക്ക് ചൂണ്ടിക്കാണിച്ചാൽ മാത്രം ആ സ്വഭാവം നേടുന്നില്ല.

നിർമ്മിക്കുന്നതിന് മുൻപ് തിരഞ്ഞെടുക്കൽ തെളിയിക്കുക

ബാക്കെൻഡിനെ തിരിച്ചറിയുന്ന ഫീൽഡിന് പേര് നൽകുക, തുടർന്ന് ക്ലയന്റ് അത് യഥാർത്ഥത്തിൽ അയയ്ക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക; ഉത്തരം വിലാസമാണെങ്കിൽ പദ്ധതി നിൽക്കും, അത് ശ്രോതാവിനെ ഒരിക്കലും എത്താത്ത ഹാൻഡ്ഷേക്കിനുള്ളിലെ സെർവർ നാമമാണെങ്കിൽ ഏത് DNS ജോലിയും അതിനെ രക്ഷിക്കില്ല. മൂന്ന് കമാൻഡുകൾ കേൾക്കുന്ന വശം വേഗത്തിൽ തീർപ്പാക്കുന്നു.

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

openssl വരി സർട്ടിഫിക്കറ്റ് നൽകുന്നത് ആ വിലാസത്തിൽ എന്തെങ്കിലും TLS അവസാനിപ്പിക്കുന്നിടത്ത് മാത്രമാണ്; സാധാരണ OpenVPN ശ്രോതാവിനെതിരെ അത് കുരുങ്ങുകയോ പരാജയപ്പെടുകയോ ചെയ്യുന്നു, അത് തന്നെ പുറം പാളി എന്ത് വെളിപ്പെടുത്തുന്നു എന്നതിനുള്ള ഉത്തരമാണ്. journal വരി, ഓരോ ബാക്കെൻഡിലും വായിച്ചാൽ, ഏത് ഇൻസ്റ്റൻസ് സെഷൻ സ്വീകരിച്ചു എന്ന് കാണിക്കുന്നു. മുൻഭാഗ ലോഗുകൾ വർഗ്ഗീകരിച്ചത് രേഖപ്പെടുത്തുന്നു, ഉദ്ദേശിച്ചത് ഒരിക്കലും രേഖപ്പെടുത്തുന്നില്ല, അതിനാൽ ഉപയോക്താവ് എവിടെ ഇറങ്ങി എന്നതിൽ ബാക്കെൻഡ് തന്നെ ഏക അധികാരിയായി തുടരുന്നു.

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