TUN എന്തു ചെയ്യുന്നു, VPN പ്രോട്ടോക്കോൾ ഇനിയും എന്തു ചെയ്യണം

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

രണ്ട് ഘടകങ്ങൾ, ഒരു പാക്കറ്റ് പാത

കേർണൽ ഉപകരണത്തിലേക്ക് ഒരു IP പാക്കറ്റ് എഴുതുന്നു, പ്രോഗ്രാം അത് ഫയൽ ഡിസ്ക്രിപ്റ്ററിൽ നിന്ന് വായിക്കുന്നു. എതിർ ദിശയിൽ പ്രോഗ്രാം പാക്കറ്റ് തിരികെ എഴുതുന്നു, കേർണൽ അത് യഥാർത്ഥ ഇന്റർഫേസിൽ എത്തിയതുപോലെ റൂട്ട് ചെയ്യുന്നു. TUN IP വഹിക്കുന്നു, TAP ഈതർനെറ്റ് ഫ്രെയിമുകൾ വഹിക്കുന്നു. ആ അതിർത്തിയിൽ പാക്കറ്റ് വായിക്കുന്നത് ഫ്രെയിമിംഗ് കാണിക്കുന്നു, ഉപകരണം കൃത്യമായി അതിനുവേണ്ടിയാണ്.

ആ അതിർത്തിക്കപ്പുറമുള്ളതെല്ലാം പ്രോഗ്രാമിന്റെ കാര്യമാണ്. രണ്ട് പ്രോഗ്രാമുകൾക്ക് ഒരേ ഇന്റർഫേസ് ആശയം ഉപയോഗിച്ച് പാക്കറ്റുകളിൽ തികച്ചും വ്യത്യസ്ത കാര്യങ്ങൾ ചെയ്യാം. ഉപകരണത്തിന് തന്നെ അടുത്തതായി എന്ത് സംഭവിക്കും എന്നതിൽ അഭിപ്രായമില്ല. പ്രോഗ്രാമിന് കേർണൽ ഭാഗത്ത് ഉള്ള ഏക ഹാൻഡിൽ ഫയൽ ഡിസ്ക്രിപ്റ്ററാണ്.

ഉപകരണം സൃഷ്ടിക്കുക, പിന്നെ അതിർത്തി നിരീക്ഷിക്കുക

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

sudo ip tuntap add dev tun9 mode tun user alice
ip -d link show tun9

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

ഇന്റർഫേസ് നാമത്തിന് വാഗ്ദാനം ചെയ്യാനാകാത്തത്

ഇന്റർഫേസ് നാമം എൻക്രിപ്ഷനെയോ പ്രാമാണീകരണത്തെയോ കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഒരു പ്രോഗ്രാമിന് പാക്കറ്റുകൾ TLS-ലും സ്വന്തം പ്രോട്ടോക്കോളിലും IPsec-ലും ഒന്നിലും പൊതിയാം. TAP-ന് പകരം TUN തിരഞ്ഞെടുക്കുന്നത് അതിർത്തിയിലെ ഫ്രെയിമിംഗ് മാറ്റുന്നു, സുരക്ഷാ രൂപകൽപ്പനയല്ല. ഫ്രെയിമിംഗിന്റെ തിരഞ്ഞെടുപ്പ് യഥാർത്ഥമാണ്, അത് സുരക്ഷാ ചോദ്യത്തേക്കാൾ വളരെ ചെറുതാണ്.

കണ്ടെത്തലും അതേ രീതിയിൽ പ്രവർത്തിക്കുന്നു: നിരീക്ഷകൻ വയറിൽ പുറം പ്രോട്ടോക്കോൾ കാണുന്നു, ഏത് പ്രാദേശിക ഉപകരണം അത് നിർമ്മിച്ചു എന്ന് പറയുന്ന ലേബലല്ല. മറ്റെന്തോ പോലെ തോന്നുന്ന ടണൽ അത് ചെയ്യുന്നത് അതിന്റെ പുറം പ്രോട്ടോക്കോൾ കാരണമാണ്, ഇന്റർഫേസ് നാമം കാരണമല്ല. ഏത് പ്രാദേശിക ഉപകരണം പാക്കറ്റ് നിർമ്മിച്ചു എന്ന് നിരീക്ഷകന് കാണാനാകില്ല, പാക്കറ്റ് എങ്ങനെ കാണപ്പെടുന്നു എന്ന് മാത്രം കാണാം. ഉൽപ്പന്നങ്ങൾ താരതമ്യം ചെയ്യുമ്പോൾ ഈ രണ്ട് ചോദ്യങ്ങളും വേർതിരിച്ച് സൂക്ഷിക്കുക, കാരണം ഒരു ഉത്തരം മറ്റൊന്നിനെ ഒരിക്കലും സൂചിപ്പിക്കുന്നില്ല.

പരാജയപ്പെടുന്ന ഘട്ടത്തിന് പരിഹാരം യോജിപ്പിക്കുക

എന്തെങ്കിലും തകരുമ്പോൾ പരാജയ ഘട്ടങ്ങൾ വേർതിരിക്കുക. കാണാത്ത ഉപകരണം, അനുമതി പിശക്, നിരസിക്കപ്പെട്ട ലോഗിൻ എന്നിവ വ്യത്യസ്ത തെളിവുകളും വ്യത്യസ്ത പരിഹാരങ്ങളും നൽകുന്നു. ആദ്യം പ്രാദേശിക അവസ്ഥ വായിക്കുക, പിന്നെ പ്രോഗ്രാമിന്റെ സ്വന്തം ലോഗ്, പിന്നെ പങ്കാളിയുടെ കാഴ്ചപ്പാട്. എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് മൂന്നും വായിക്കുക.

ip -d link show tun0
journalctl -u openvpn-client@corp --since '10 min ago'

ഉപകരണം നിലവിലുണ്ടെങ്കിൽ, ഒരു പ്രക്രിയ അത് പിടിച്ചിരിക്കുന്നുവെങ്കിൽ, പ്രാദേശിക അതിർത്തി പ്രവർത്തിക്കുന്നു, പ്രശ്നം കൂടുതൽ അകലെയാണ്. ഉപകരണം ഇല്ലെങ്കിൽ, എത്ര ക്രെഡൻഷ്യൽ പരിശോധനയും സഹായിക്കില്ല. നിങ്ങൾക്ക് പേര് നൽകാവുന്ന ഘട്ടമാണ് പരീക്ഷിക്കാവുന്ന ഘട്ടം. TUN/TAP ഡോക്യുമെന്റേഷൻ അതിർത്തിയും ഉപകരണ മാതൃകയും വിവരിക്കുന്നു.