VPN ഏത് എൻക്രിപ്ഷൻ ഉപയോഗിക്കുന്നു എന്ന് ചോദിച്ചാൽ ഉത്തരം സാധാരണയായി ഒരു വാക്കിൽ വരും: AES-256, അല്ലെങ്കിൽ ChaCha20, അല്ലെങ്കിൽ ഒരുപക്ഷേ WireGuard. ആ ഉത്തരം ഒരു പാളിയുടെ ഒരു ഘടകത്തെ പേരെടുത്ത് പറയുന്നു, എന്നാൽ ബന്ധത്തെ യഥാർത്ഥത്തിൽ സംരക്ഷിക്കുന്നത് നാല് വ്യത്യസ്ത പങ്കുകൾ വഹിക്കുന്ന അൽഗോരിതങ്ങളുടെ ഒരു കൂട്ടമാണ്. ഘടകത്തെ ക്രമീകരണവുമായി കൂട്ടിക്കലർത്തുന്നതാണ് ഈ സംഭാഷണങ്ങളിലെ ഏറ്റവും സാധാരണ തെറ്റ്, അത് തീർപ്പാക്കാനാകാത്ത താരതമ്യങ്ങൾ സൃഷ്ടിക്കുന്നു.

ഒരു ബന്ധത്തിനുള്ളിൽ നാല് ജോലികൾ

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

ചില രൂപകൽപ്പനകൾ രണ്ട് പങ്കുകൾ ഒന്നാക്കി ചേർക്കുന്നു. AES-GCM, ChaCha20-Poly1305 എന്നിവ പ്രാമാണീകരിച്ച എൻക്രിപ്ഷൻ നിർമ്മാണങ്ങളാണ്, അതിനാൽ രഹസ്യസ്വഭാവവും സമഗ്രതയും ഒരുമിച്ച് വരുന്നു; AES-CBC അങ്ങനെയല്ല, അതിന് സ്വന്തം കീയുള്ള വേറിട്ട സന്ദേശ പ്രാമാണീകരണ കോഡ് ആവശ്യമാണ്. അതിനാൽ നിർദ്ദേശത്തെ സ്വതന്ത്ര സംഖ്യകളുടെ സഞ്ചിയായി വായിക്കുന്നത് ജോടികളായി രൂപകൽപ്പന ചെയ്തവയെ തെറ്റായി വായിക്കുന്നു.

പങ്കുകൾ വ്യത്യസ്ത പാളികളിലുമാണ്, അതിനാൽ ഒരേ വാക്ക് രണ്ട് ഉൽപ്പന്നങ്ങളിൽ വ്യത്യസ്ത അർത്ഥം നൽകാം. ESP-യ്ക്കുള്ളിലെ ബ്ലോക്ക് സൈഫറും TLS-നുള്ളിലെ ബ്ലോക്ക് സൈഫറും വ്യത്യസ്ത ആവശ്യകതകളുള്ള വ്യത്യസ്ത ചർച്ചകളിലെ ഒരേ അടിസ്ഥാന ഘടകമാണ്. അതിനാൽ രീതിയും പാളിയും കൂടാതെ അടിസ്ഥാന ഘടകം ഉദ്ധരിക്കുന്നത് ഒന്നും ഉദ്ധരിക്കാതിരിക്കുന്നതിനേക്കാൾ മോശമായേക്കാം.

സൈഫർ നാമം ഏതാണ്ട് ഒന്നും പറയാത്തത് എന്തുകൊണ്ട്

AES-256 എന്ന പദപ്രയോഗം ഒരു നിമിഷം ഗൗരവത്തോടെ എടുക്കുക: അത് ഒരു ബ്ലോക്ക് സൈഫറും കീ വലുപ്പവും സൂചിപ്പിക്കുന്നു. പ്രവർത്തന രീതി, സമഗ്രത നൽകുന്നുണ്ടോ, കീകൾ എങ്ങനെ സ്ഥാപിച്ചു അല്ലെങ്കിൽ എതിർകക്ഷിയെ എങ്ങനെ പ്രാമാണീകരിച്ചു എന്നിവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. രണ്ട് ഉൽപ്പന്നങ്ങൾക്കും AES-256 പരസ്യപ്പെടുത്താം, ബാക്കിയെല്ലാം വ്യത്യസ്തമാകാം, പ്രാമാണീകരിക്കാത്ത രീതിയുമായി ചേർക്കുന്നതും ആധുനിക കീ കൈമാറ്റത്തോടുകൂടിയ AEAD രീതി ഉപയോഗിക്കുന്നതും ഉൾപ്പെടെ.

TLS 1.3 ഈ വേർതിരിവ് മാനദണ്ഡത്തിലേക്ക് കൊണ്ടുവന്നു, പഴയ പദാവലി പഠിച്ചവർക്ക് ഇത് ഉപയോഗപ്രദമായ തിരുത്താണ്. അതിന്റെ സൈഫർ സ്യൂട്ടുകൾ AEAD-യും ഹാഷും മാത്രം പേരെടുത്ത് പറയുന്നു, അതേസമയം കീ കൈമാറ്റ ഗ്രൂപ്പുകളും ഒപ്പ് അൽഗോരിതങ്ങളും വേറിട്ട പരാമീറ്ററുകളായി ചർച്ച ചെയ്യുന്നു. അതിനാൽ TLS 1.3 സ്യൂട്ട് നാമം TLS 1.2 സ്യൂട്ട് നാമവുമായി തുല്യ അടിസ്ഥാനത്തിൽ താരതമ്യം ചെയ്യാനാവില്ല, രണ്ടും ഒരേ കോൺഫിഗറേഷൻ ഫയലിന്റെ ഒരേ ഫീൽഡിൽ പ്രത്യക്ഷപ്പെട്ടാലും. രണ്ട് സ്ട്രിംഗുകൾ നേരിട്ട് താരതമ്യം ചെയ്യുന്ന ഓഡിറ്റർ പ്രോട്ടോക്കോൾ പിന്തുണയ്ക്കാത്ത നിഗമനത്തിൽ എത്തുന്നു. ചർച്ച ചെയ്ത ഗ്രൂപ്പും ഒപ്പ് പരാമീറ്ററുകളും കൂടി വായിക്കുക, അല്ലെങ്കിൽ താരതമ്യം അപൂർണമാണ്.

WireGuard വിപരീത വഴി തിരഞ്ഞെടുത്ത് ചർച്ച ഏതാണ്ട് പൂർണമായി നീക്കം ചെയ്യുന്നു: പ്രോട്ടോക്കോൾ ഒരു നിശ്ചിത അൽഗോരിതം കൂട്ടം നിർവചിക്കുന്നു, അതിനാൽ രണ്ട് നടപ്പാക്കലുകൾ ഒരുമിച്ച് പ്രവർത്തിക്കുന്നു അല്ലെങ്കിൽ ഇല്ല. ഇത് നിയമാനുസൃത രൂപകൽപ്പന തിരഞ്ഞെടുപ്പാണ്, WireGuard ഏത് സ്യൂട്ട് ചർച്ച ചെയ്യുന്നു എന്ന ചോദ്യത്തിന് താരതമ്യത്തിന് യോഗ്യമായ ഉത്തരമില്ല എന്നും ഇത് അർത്ഥമാക്കുന്നു. നിങ്ങൾ ഇത് ഓഡിറ്റ് ചെയ്യുന്നുവെങ്കിൽ, സ്പെസിഫിക്കേഷൻ ഒരിക്കൽ വായിച്ച് പിന്നീട് അതിന് ചുറ്റുമുള്ള കീ കൈകാര്യം ഓഡിറ്റ് ചെയ്യുക, ചർച്ചയ്ക്ക് പകരം.

പാളിയാണ് പദാവലി തീരുമാനിക്കുന്നത്

IPsec വിന്യാസം രണ്ട് തവണ ചർച്ച ചെയ്യുന്നു: നിയന്ത്രണ ചാനലിനായി IKE നിർദ്ദേശവും ഡാറ്റയ്ക്കായി ESP രൂപാന്തരവും, രണ്ടും നിയമാനുസൃതമായി വ്യത്യാസപ്പെടാം. ആദ്യത്തേത് വായിച്ച് രണ്ടാമത്തേതിനെ വിവരിക്കുന്നു എന്ന് അനുമാനിക്കുന്നത് ഓഡിറ്റിനിടയിലെ സാധാരണ ആശയക്കുഴപ്പത്തിന്റെ ഉറവിടമാണ്, കാരണം കോൺഫിഗറേഷൻ ഫയൽ രണ്ടും പരാമർശിക്കുന്നു, താൽപ്പര്യമുള്ളത് രണ്ടാമത്തേതാണ്.

LayerWhat is negotiated thereWhat it does not cover
IKE proposalAlgorithms and groups for the control channel that builds the tunnelThe algorithms protecting the data itself
ESP transformEncryption and integrity for tunneled packetsPeer identity, which authentication already settled
TLS handshakeAEAD and hash, plus separately negotiated groups and signaturesRouting, authorization or retention policy
WireGuardNothing; the algorithm set is fixed by the protocolEverything above the cryptographic arrangement

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

TLS 1.3 സ്പെസിഫിക്കേഷൻ ഈ വേർതിരിവിന്റെ ഏറ്റവും വ്യക്തമായ പ്രസിദ്ധീകരിച്ച ഉദാഹരണമാണ്, കാരണം അത് സ്യൂട്ടിനെ ഒരു ജോടിയായി നിർവചിച്ച് ബാക്കിയുള്ളത് അതിന്റെ സ്വന്തം ചർച്ചയിലേക്ക് മാറ്റുന്നു. ആ രൂപം പരിചിതമാകുമ്പോൾ IPsec നിർദ്ദേശവും WireGuard-ന്റെ ഒരേയൊരു നിശ്ചിത കൂട്ടവും ഒരേ ആശയത്തിന്റെ ഭേദങ്ങളായി വായിക്കപ്പെടുന്നു.

ചർച്ച ചെയ്ത ഫലം വായിച്ച് പിന്നെ നിർത്തുക

കോൺഫിഗർ ചെയ്ത നിർദ്ദേശം രണ്ട് കക്ഷികൾ എന്ത് തിരഞ്ഞെടുത്തു എന്നതിന്റെ തെളിവല്ല. ജീവനുള്ള സെഷൻ ഉത്തരം വഹിക്കുന്നു, ഏത് പ്രധാന നടപ്പാക്കലിനും പാക്കറ്റുകൾ പിടിക്കാതെ അത് റിപ്പോർട്ട് ചെയ്യാം.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

ഔട്ട്പുട്ടിൽ നൽകിയ പട്ടികയ്ക്ക് പകരം തിരഞ്ഞെടുത്ത അൽഗോരിതങ്ങൾ വായിക്കുക. ഉത്തരം നയം ഉദ്ദേശിച്ചതിലും ദുർബലമാണെങ്കിൽ, തിരുത്ത് ഒരു വശത്തെ നിർദ്ദേശ കോൺഫിഗറേഷനിലാണ്, ആധുനിക നടപ്പാക്കലുകളിൽ പൊരുത്തക്കേട് സാധാരണയായി നിശബ്ദ തരംതാഴ്ത്തലല്ല, പരാജയപ്പെട്ട ചർച്ചയായി പ്രത്യക്ഷപ്പെടുന്നു.

പിന്നെ സ്യൂട്ട് എന്ത് ഉൾക്കൊള്ളുന്നില്ല എന്ന് ഓർക്കുക. റൂട്ടുകൾ, ആപ്പ് അനുമതികൾ, ലോഗിംഗ്, സൂക്ഷിക്കൽ എന്നിവ സ്വന്തം അവലോകനമുള്ള വേറിട്ട തീരുമാനങ്ങളാണ്, അനുയോജ്യമായ ക്രിപ്റ്റോഗ്രാഫിക് ക്രമീകരണം അവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. സൈഫർ ചർച്ച വിലപ്പെട്ടതാണ്, പക്ഷേ മിക്ക ആളുകളും യഥാർത്ഥത്തിൽ ചോദിക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.

പദാവലി കൃത്യമായി നിലനിർത്തുക, വാദം ചുരുങ്ങും. സ്യൂട്ട് എന്നത് ഒരു പാളിയിലെ പങ്കുകളുടെ കൂട്ടമാണ്, സൈഫർ ഒരു ഘടകമാണ്, ചർച്ച ചെയ്ത ഫലം മാത്രമാണ് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഉള്ള ബന്ധത്തെ വിവരിക്കുന്നത്. താരതമ്യത്തിലെ ബാക്കിയെല്ലാം അലങ്കാരമാണ്.

അനുബന്ധ ലേഖനങ്ങൾ