proto udp അതോ tcp-client: നിങ്ങളുടെ സെർവർ ഏതാണ് കേൾക്കുന്നത്?

കഴിഞ്ഞ മാസം പ്രവർത്തിച്ചിരുന്ന ഒരു പ്രൊഫൈൽ ഇപ്പോൾ സമയപരിധി കഴിയുന്നു, ആരോ proto udp എന്നത് proto tcp-client ആക്കി മാറ്റാൻ നിർദ്ദേശിക്കുന്നു. ചിലപ്പോൾ അത് ശരിയായ നീക്കമാണ്, ചിലപ്പോൾ ഒന്നും കേൾക്കാത്ത ഒരു പോർട്ടിലേക്ക് ബന്ധിപ്പിക്കുന്ന ക്ലയന്റ് ഉണ്ടാകുന്നു, കാരണം സെർവർ ഒരിക്കലും മറ്റേ ഗതാഗതത്തിനായി ക്രമീകരിച്ചിട്ടില്ല. ഈ നിർദ്ദേശം നിങ്ങളുടെ ഭാഗം എങ്ങനെ സംസാരിക്കുന്നു എന്ന് വിവരിക്കുന്നു; അതിന് എതിർഭാഗത്ത് ശ്രോതാവിനെ സൃഷ്ടിക്കാനാവില്ല. ഇവയിലൊന്നും മാറ്റുന്നതിന് മുമ്പ് പ്രൊഫൈലും സെർവറും ഒരുമിച്ച് വായിക്കുക.

തിരഞ്ഞെടുത്ത കണക്ഷൻ ഉപയോഗിക്കുന്ന ഗതാഗതം വായിക്കുക

ഒരു പ്രൊഫൈലിൽ നിരവധി remote എൻട്രികൾ ഉണ്ടാകാം, ഓരോന്നും സ്വന്തം ഗതാഗതം പറയാം. ക്ലയന്റ് അവ ക്രമത്തിൽ കൈകാര്യം ചെയ്യുന്നു, അതിനാൽ ആദ്യം കാണുന്ന വരി ബാധകമായ വരിയായിരിക്കണമെന്നില്ല.

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

ഫയലിൽ മുകളിൽ ഒരു proto വരിയും താഴെ നിരവധി remote എൻട്രികളും ഉണ്ടെങ്കിൽ, ആ വരി അതിനെ മറികടക്കാത്ത ഏത് remote-നുമുള്ള സ്ഥിരമായ മൂല്യമാണ്. സ്ഥിരമായ മൂല്യത്തിലുള്ള പ്രാദേശിക മാറ്റം സ്വന്തം ഗതാഗതം പറയുന്ന remote എൻട്രിക്ക് ഒന്നും ചെയ്യുന്നില്ല.

grep -nE '^(remote|proto)\b' client.ovpn

UDP-യും TCP-യും വേഗതയുടെ ക്രമീകരണമല്ല

UDP ക്രമമുള്ള സ്ട്രീം നിർമ്മിക്കാതെ ഡാറ്റാഗ്രാമുകൾ അയയ്ക്കുന്നു, അതിനാൽ ടണലിന്റെ സ്വന്തം ട്രാഫിക് രണ്ടാമത്തെ വിശ്വസനീയ ഗതാഗതത്തിൽ പൊതിയുന്നില്ല. UDP ഉപേക്ഷിക്കുന്നതോ തടയുന്നതോ ആയ നെറ്റ്വർക്കുകളിലൂടെ TCP നിങ്ങൾക്ക് ഒരു വഴി നൽകുന്നു, പക്ഷേ അതിന്റെ വില നഷ്ടമുള്ള ലിങ്കിനെ കൂടുതൽ മോശമായി അനുഭവപ്പെടുത്താനാകുന്ന ഉൾക്കൊള്ളുന്ന പുനർസംപ്രേഷണമാണ്.

ഇത് എത്തിച്ചേരാനുള്ള കൈമാറ്റമാണ്, സാർവത്രിക റാങ്കിംഗല്ല. ശരിയായ തിരഞ്ഞെടുപ്പ് ക്ലയന്റിന് മുന്നിലുള്ള നെറ്റ്വർക്ക് അനുവദിക്കുന്നതാണ്. VPN പോർട്ടിൽ UDP ഉപേക്ഷിക്കുന്ന വഴി എത്ര നന്നായി പ്രൊഫൈൽ എഴുതിയാലും ഒരിക്കലും ചർച്ച നടത്തില്ല. വഴി പരീക്ഷിച്ച ശേഷം ഗതാഗതം തിരഞ്ഞെടുക്കുക.

അവയ്ക്കിടയിൽ വെറും അളവിന്റെ അടിസ്ഥാനത്തിൽ തിരഞ്ഞെടുക്കുന്നത് തെറ്റാണ്, കാരണം ഉത്തരം നിങ്ങൾക്ക് മുന്നിലുള്ള നെറ്റ്വർക്ക് എന്ത് അനുവദിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ഒരു ഹോട്ടലിനോ കോർപ്പറേറ്റ് പ്രോക്സിക്കോ 443-ൽ പുറത്തേക്കുള്ള TCP മാത്രം അനുവദിക്കാം, അതുകൊണ്ടാണ് ദാതാക്കൾ ആ വകഭേദം വാഗ്ദാനം ചെയ്യുന്നത്. പോർട്ട് നമ്പർ പരിചിതമാണെങ്കിലും അത് ആ പോർട്ടിലെ OpenVPN കണക്ഷനാണ്, HTTPS സെഷനല്ല.

tcp-client യഥാർത്ഥത്തിൽ എന്താണ് അർത്ഥമാക്കുന്നത്

ക്ലയന്റ് ഭാഗത്തെ നിർദ്ദേശം TCP കണക്ഷൻ ആരംഭിക്കുന്ന അറ്റത്തെ പേരിടുന്നു. സെർവർ ഭാഗം സ്വന്തം ശ്രവണരൂപം ഉപയോഗിക്കുന്നു, ക്ലയന്റിന്റെ വാക്ക് സെർവർ കോൺഫിഗറേഷനിലേക്ക് പകർത്തുന്നത് വിളിക്കപ്പെടാൻ പ്രതീക്ഷിക്കുന്ന ശ്രോതാവിനെ സൃഷ്ടിക്കുന്നു, സ്വീകരിക്കുന്നതിനെയല്ല.

പൊരുത്തപ്പെടൽ എന്നാൽ രണ്ട് അറ്റങ്ങളും ഗതാഗതത്തിൽ യോജിക്കുന്നു എന്നാണ്, ഒരേ സ്ട്രിംഗ് പങ്കിടുന്നു എന്നല്ല.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

പ്രൊഫൈൽ തെറ്റാണെന്ന് അനുമാനിക്കുന്നതിന് മുമ്പ് സെർവറിനോട് എന്താണ് കേൾക്കുന്നതെന്ന് ചോദിക്കുക. UDP ശ്രോതാവ് TCP സോക്കറ്റ് പട്ടികയിൽ പ്രത്യക്ഷപ്പെടുന്നില്ല, തിരിച്ചും ശരിയാണ്, അതിനാൽ പൊതുവായ കാഴ്ചയ്ക്ക് പകരം പ്രോട്ടോക്കോൾ-നിർദ്ദിഷ്ട കാഴ്ച നോക്കുക.

പ്രൊഫൈൽ ഇമ്പോർട്ട് ചെയ്യുമ്പോൾ ഒരിക്കലും ബന്ധിപ്പിക്കുന്നില്ലെങ്കിൽ

ഉടൻ സമയപരിധി കഴിയുന്ന ഇമ്പോർട്ട് ചെയ്ത പ്രൊഫൈൽ സാധാരണയായി ഏതെങ്കിലും പ്രാമാണീകരണത്തിന് മുമ്പ് പരാജയപ്പെടുന്നു. പാക്കറ്റ് ശ്രോതാവില്ലാത്ത പോർട്ടിലേക്ക് പോകുന്നു, അല്ലെങ്കിൽ നെറ്റ്വർക്ക് അത് നിശബ്ദമായി ഉപേക്ഷിക്കുന്നു.

വഴി കഴിയുന്നത്ര ലളിതമായി പരീക്ഷിക്കുക: പരാജയപ്പെടുന്ന ക്ലയന്റിന്റെ അതേ നെറ്റ്വർക്കിൽ നിന്ന്, പ്രൊഫൈൽ അവകാശപ്പെടുന്ന ഗതാഗതത്തോടെ അതേ ഹോസ്റ്റിലേക്കും പോർട്ടിലേക്കും ബന്ധിപ്പിക്കുക.

UDP പരിശോധനയ്ക്ക് ഒന്നും കിട്ടാതെ TCP പരിശോധന ബന്ധിപ്പിക്കുന്നുവെങ്കിൽ, സെർവർ മറ്റേ ഗതാഗതം വാഗ്ദാനം ചെയ്യുന്നു, പ്രൊഫൈൽ കേവലം പഴയതാണ്. രണ്ടും പ്രതികരിക്കുന്നില്ലെങ്കിൽ, പ്രശ്നം ഗതാഗത തിരഞ്ഞെടുപ്പിന് മുകളിലാണ്, പ്രൊഫൈലിലെ ഏത് തിരുത്തും അത് ശരിയാക്കില്ല. ഈ രണ്ട് സാഹചര്യങ്ങൾ വേർതിരിച്ചറിയാൻ ഒരു മിനിറ്റ് എടുക്കും, ഒരിക്കലും പ്രസക്തമല്ലാത്ത സർട്ടിഫിക്കറ്റ് ഡീബഗ്ഗിംഗിന്റെ ഒരു മണിക്കൂർ ലാഭിക്കും.

പ്രവർത്തിക്കുന്ന ഗതാഗതം രേഖപ്പെടുത്തുക

ഒരു സംയോജനം പ്രവർത്തിക്കുമ്പോൾ, അത് സെർവർ, പോർട്ട്, പ്രോട്ടോക്കോൾ എന്നിവയോടൊപ്പം എഴുതി, ഏത് നെറ്റ്വർക്കിൽ നിന്നാണ് പരീക്ഷിച്ചതെന്ന് രേഖപ്പെടുത്തുക.

അല്ലെങ്കിൽ സമയപരിധി നേരിടുന്ന അടുത്ത വ്യക്തി അതേ പരീക്ഷണം എതിർദിശയിൽ ആവർത്തിക്കും, ഒരുപക്ഷേ കുഴപ്പമില്ലാതിരുന്ന സെർവർ മാറ്റും.

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