ഒരു ഹോസ്റ്റിൽ നിന്ന് TCP, UDP എന്നിവയിൽ OpenVPN നൽകുന്നത്
2.7-ന് മുമ്പ് ഒരു പ്രോസസ്സ് ഒരു ട്രാൻസ്പോർട്ട് മാത്രം ബൈൻഡ് ചെയ്യുന്നു. ബ്രിഡ്ജ് ചെയ്ത TAP ജോഡി, രണ്ട് TUN സബ്നെറ്റുകൾ, പങ്കിട്ട പൂൾ എന്നിവ താരതമ്യം ചെയ്ത്, ഓരോ പ്രൊഫൈലും അതിന്റെ ലിസണറുമായി ചേർക്കുക.
TCP 443 മാത്രം അനുവദിക്കുന്ന നെറ്റ്വർക്കുകൾ UDP തടസ്സമില്ലാതെ കടത്തിവിടുന്ന നെറ്റ്വർക്കുകൾക്കൊപ്പം നിലനിൽക്കുന്നു, ഒരു സെർവർ രണ്ടിനും സേവനം നൽകണം. proto udp ഉള്ള പ്രൊഫൈൽ രണ്ടാം ഗ്രൂപ്പിന് ഉത്തരം നൽകി ആദ്യത്തേതിൽ പരാജയപ്പെടുന്നു, അതേ കോൺഫിഗറേഷൻ proto tcp എന്ന് മാറ്റിയാലും രണ്ടാമത്തെ ലിസണർ സൃഷ്ടിക്കുന്നില്ല. ഈ നിർദ്ദേശം ഒരു പ്രോസസ്സിന് ഒരു ട്രാൻസ്പോർട്ട് തിരഞ്ഞെടുക്കുന്നു. ബാക്കിയെല്ലാം ഈ നിയന്ത്രണത്തിൽ നിന്നാണ് വരുന്നത്.
ഒന്നിലധികം പ്രോസസ്സുകൾ പ്രവർത്തിപ്പിക്കുക, അല്ലെങ്കിൽ ഒരേ സമയം പല സോക്കറ്റുകൾ ബൈൻഡ് ചെയ്യാൻ കഴിയുന്ന പതിപ്പ് പ്രവർത്തിപ്പിക്കുക.
2.7-ന് മുമ്പ് ഒരു പ്രോസസ്സ് ഒരു ട്രാൻസ്പോർട്ട് മാത്രം ബൈൻഡ് ചെയ്യുന്നു
കമ്മ്യൂണിറ്റി OpenVPN proto വിവരിക്കുന്ന സോക്കറ്റ് ബൈൻഡ് ചെയ്യുന്നു, ആ നിർദ്ദേശം ഇൻസ്റ്റൻസിന് ഒരു ട്രാൻസ്പോർട്ട് തിരഞ്ഞെടുക്കുന്നു. TCP, UDP വെവ്വേറെ സ്റ്റാക്കുകളാണ്, അതിനാൽ അതേ പോർട്ട് നമ്പർ രണ്ടും ഒരേ സമയം ഉപയോഗിക്കാം, പക്ഷേ ഒരു പ്രോസസ്സിന് രണ്ടും സാധ്യമല്ല. അതിനാൽ 2.6 ശ്രേണി ഓരോ ഡീമണിനും ഒരു ട്രാൻസ്പോർട്ട് നൽകുന്നു. OpenVPN 2.7 സെർവറുകൾക്ക് ഈ പരിമിതി നീക്കി; ഒരു പ്രോസസ്സിൽ പല --local പ്രസ്താവനകളിലൂടെ പല സോക്കറ്റുകൾ ബൈൻഡ് ചെയ്യാം.
ഏത് ഉത്തരത്തെ അടിസ്ഥാനമാക്കി രൂപകൽപ്പന ചെയ്യുന്നതിനും മുമ്പ് പതിപ്പ് പരിശോധിക്കുക, കാരണം 2.7 ക്രമീകരണം സ്വന്തം കോൺഫിഗറേഷൻ വാക്യഘടനയുള്ള മറ്റൊരു പ്രവർത്തന മാതൃകയാണ്. 2.6-നായി എഴുതിയ ഗൈഡ് അത് പറയാത്തപ്പോഴും രണ്ട് പ്രോസസ്സുകളെ വിവരിക്കുന്നു.
രണ്ട് ഇൻസ്റ്റൻസുകൾ പ്രവർത്തിപ്പിക്കാനുള്ള മൂന്ന് വഴികൾ
TAP ഇന്റർഫേസുകളിൽ, ഓരോ ട്രാൻസ്പോർട്ടിനും ഒരു ഇൻസ്റ്റൻസ് പ്രവർത്തിപ്പിച്ച് ഹോസ്റ്റിൽ രണ്ട് tap ഉപകരണങ്ങൾ ബ്രിഡ്ജ് ചെയ്യുക. രണ്ട് ക്ലയന്റ് ഗ്രൂപ്പുകളും ഒരേ ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്നിൽ എത്തുന്നു, ഇത് ഒരു വിലാസ പൂളിന് അവയെ ഉൾക്കൊള്ളാൻ അനുവദിക്കുകയും ബ്രോഡ്കാസ്റ്റിനെ ആശ്രയിക്കുന്ന പ്രോട്ടോക്കോളുകൾ പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നു. TUN-ൽ ബ്രിഡ്ജിംഗ് ലഭ്യമല്ല, അതിനാൽ ഏറ്റവും ലളിതമായ വിഭജനം ഓരോ ഇൻസ്റ്റൻസിനും സ്വന്തം സബ്നെറ്റ് നൽകുന്നു, റൂട്ടിംഗ് രണ്ട് ക്ലയന്റ് ഗ്രൂപ്പുകളെ വേർതിരിക്കുന്നു. മൂന്നാമത്തെ ഓപ്ഷൻ ഒരു പൂൾ നിലനിർത്തുന്നു: ഓരോ ഇൻസ്റ്റൻസും learn-address സ്ക്രിപ്റ്റ് വിളിക്കുന്നു, അത് ആ ഇൻസ്റ്റൻസിന്റെ ഉപകരണത്തിലൂടെ ക്ലയന്റിന് /32 റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്നു.
ആ മൂന്നാമത്തെ ക്രമീകരണമാണ് ആളുകൾ ആവശ്യപ്പെടുന്നതും ഏറ്റവും കൂടുതൽ ശ്രദ്ധ ആവശ്യമുള്ളതും, കാരണം സ്ക്രിപ്റ്റ് ഡാറ്റാ പാതയുടെ ഭാഗമാകുകയും ചേർക്കൽ, അപ്ഡേറ്റ്, ഇല്ലാതാക്കൽ ഇവന്റുകൾ ശരിയായി കൈകാര്യം ചെയ്യേണ്ടതുമാണ്.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
രണ്ട് ഇൻസ്റ്റൻസുകളും വേർതിരിച്ച് നിർത്തുക
ഓരോ ഇൻസ്റ്റൻസിനും വെവ്വേറെ പോർട്ടോ വിലാസമോ, വെവ്വേറെ സ്റ്റാറ്റസ് ഫയലും വെവ്വേറെ ലോഗ് ലക്ഷ്യവും വേണം. ഒരേ സ്റ്റാറ്റസ് ഫയലിൽ ചേർക്കുന്ന രണ്ട് ഡീമണുകൾ സംഭവസമയത്ത് വായിക്കാനാകാത്ത ഔട്ട്പുട്ട് ഉണ്ടാക്കുന്നു, അത് ആവശ്യമുള്ളത് അപ്പോഴാണ്. രണ്ടാമത്തെ ഇൻസ്റ്റൻസ് ഒരു നിർദ്ദിഷ്ട വിലാസം ബൈൻഡ് ചെയ്താൽ, പ്രോസസ്സ് ആരംഭിക്കുമ്പോൾ ആ വിലാസം ഹോസ്റ്റിൽ ഉണ്ടായിരിക്കണം; അല്ലെങ്കിൽ കീകളെക്കുറിച്ച് ഒന്നും പറയുന്നതിന് മുമ്പ് അത് ബൈൻഡ് പരാജയത്തോടെ പുറത്തുപോകുന്നു.
യൂണിറ്റുകൾക്കും പ്രൊഫൈലുകൾക്കും ഫയൽനാമത്തിൽ നിന്ന് തന്നെ ട്രാൻസ്പോർട്ട് വ്യക്തമാകുന്ന പേരുകൾ നൽകുക. ഏതാണ് TCP എന്ന് അറിയാൻ അടുത്ത ഓപ്പറേറ്റർ കോൺഫിഗറേഷൻ തുറക്കേണ്ടതില്ല.
പ്രൊഫൈൽ ലിസണറുമായി ചേർക്കുക
proto tcp പ്രവർത്തിപ്പിക്കുന്ന സെർവർ proto tcp-client ഉള്ള ക്ലയന്റ് പ്രൊഫൈൽ പ്രതീക്ഷിക്കുന്നു, ഇപ്പോഴും proto udp വഹിക്കുന്ന പ്രൊഫൈൽ ആ ലിസണറിനെതിരെ ഉപയോക്താവിന് നടപടിയെടുക്കാനാകുന്ന പിശകില്ലാതെ സമയം കഴിഞ്ഞ് നിലയ്ക്കുന്നു. വിന്യാസം രണ്ട് ട്രാൻസ്പോർട്ടുകളും നൽകുന്നെങ്കിൽ രണ്ട് പ്രൊഫൈലുകൾ സൂക്ഷിക്കുക, ഏതാണ് പരീക്ഷിച്ചതെന്ന് സപ്പോർട്ടിന് അറിയാൻ ലേബൽ ചെയ്യുക. പോർട്ട് നമ്പർ മാത്രം ട്രാൻസ്പോർട്ടിനെ വിവരിക്കുന്നില്ല.
ഫയർവാൾ നിയമങ്ങൾ അതേ വിഭജനം പിന്തുടരുന്നു: UDP 1194-നുള്ള നിയമം TCP 1194-നെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ഒരു വിലാസത്തിനുള്ള നിയമം മറ്റേ ലിസണറെ ഉൾക്കൊള്ളുന്നുമില്ല.
ആദ്യം സെർവറിന്റെ കാഴ്ച്ച വായിക്കുക
സെർവറിൽ ss -lntup ഉപയോഗിച്ച് തുടങ്ങി TCP, UDP ലിസണറുകൾ രണ്ടും പ്രത്യക്ഷപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക. തുടർന്ന് ഓരോ തരത്തിൽ നിന്നും ഒരു ക്ലയന്റ് ബന്ധിപ്പിച്ച് വ്യത്യസ്ത വിലാസങ്ങളുള്ള രണ്ട് എൻട്രികൾക്കായി സ്റ്റാറ്റസ് ഔട്ട്പുട്ട് പരിശോധിക്കുക. സോക്കറ്റുകൾ ഉണ്ടായിട്ടും ക്ലയന്റ് വരുന്നില്ലെങ്കിൽ, ഡീമൺ അവ കാണുന്നതിന് മുമ്പ് പാതയോ ഫയർവാളോ പാക്കറ്റുകൾ നിരസിക്കുന്നു.
ഒരിക്കലും പ്രത്യക്ഷപ്പെടാത്ത സോക്കറ്റ് കോൺഫിഗറേഷനോ ബൈൻഡിനോ ഉള്ള പ്രശ്നമാണ്, പ്രത്യക്ഷപ്പെട്ടിട്ടും ഒരിക്കലും കണക്ഷൻ രേഖപ്പെടുത്താത്ത സോക്കറ്റ് ഫിൽട്ടറിംഗ് പ്രശ്നമാണ്. ക്ലയന്റിൽ നിന്ന് രണ്ടും ഒരുപോലെ കാണപ്പെടുന്നു, അതുകൊണ്ടാണ് സെർവറിന്റെ സ്വന്തം കാഴ്ച്ച ആദ്യം വരുന്നത്. TCP ഹെഡ്-ഓഫ്-ലൈൻ ബ്ലോക്കിംഗ് വഹിക്കുന്നു എന്ന് ഓർക്കുക, അതിനാൽ അത് വാഗ്ദാനം ചെയ്യുന്നത് വ്യക്തമായ UDP പാതയുള്ള ക്ലയന്റുകൾക്ക് നവീകരണമല്ല, ലഭ്യതയുടെ നടപടിയാണ്.