ഒരേ ഹോസ്റ്റിൽ OpenVPN സെർവറും ക്ലയന്റും: ക്ലയന്റുകൾ എന്തുകൊണ്ട് പൊഴിയുന്നു

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

ഒരു യന്ത്രം, രണ്ട് റോളുകൾ, മറുപടികൾ എങ്ങോട്ട് പോകണം എന്നതിനെക്കുറിച്ച് പരസ്പരവിരുദ്ധമായ രണ്ട് ഉത്തരങ്ങൾ.

അതേ പൂൾ, രണ്ട് സെർവറുകൾ: ആരു ജയിക്കും

ഓരോ സെർവർ ഇൻസ്റ്റൻസിനും സ്വന്തമായ ടണൽ സബ്നെറ്റ് വേണം. server 10.8.0.0 255.255.255.0 പോലുള്ള ഒരു വരി രണ്ടാം കോൺഫിഗറേഷനിലേക്ക് പകർത്തിയാൽ രണ്ട് ഇൻസ്റ്റൻസുകൾക്കും ഒരേ പ്രിഫിക്സ് ലഭിക്കും, ഫലം ആരംഭിക്കാൻ വിസമ്മതം അല്ലെങ്കിൽ ഒരു സെർവറിലെ ക്ലയന്റുകൾ മറ്റേതും തന്റേതെന്ന് വിശ്വസിക്കുന്ന വിലാസങ്ങൾ സ്വീകരിക്കുന്ന നിശബ്ദ മൽസരം. വ്യത്യസ്ത UDP പോർട്ടുകളും വ്യത്യസ്ത ഉപകരണനാമങ്ങളും സഹായിക്കുന്നില്ല, കാരണം രണ്ടും വിലാസമേഖലയെ തൊടുന്നില്ല. രണ്ടാം പൂൾ മാറ്റുക, റൂട്ടുകൾ അതിനെ പരാമർശിക്കുന്ന എല്ലായിടത്തും മാറ്റുക.

തിരുത്തുന്നതിന് മുമ്പ് എന്താണ് സജീവമെന്ന് പട്ടികപ്പെടുത്തുക: ip -4 addr show ടണൽ ഉപകരണങ്ങൾ പട്ടികപ്പെടുത്തുന്നു, ss -lunp കേൾവിക്കാരെ പട്ടികപ്പെടുത്തുന്നു, systemctl list-units യൂണിറ്റുകളുടെ പേരുകൾ നൽകുന്നു. ടണൽ വിലാസങ്ങളിലേക്ക് ഒരു നോട്ടം പൂളുകൾ കൂട്ടിയിടുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു.

ക്ലയന്റ് പ്രൊഫൈൽ പട്ടികയിൽ എന്ത് ചേർക്കുന്നു

ക്ലയന്റ് പകുതി ബന്ധിപ്പിക്കുന്ന ഉടൻ റൂട്ടുകൾ എഴുതുന്നു. redirect-gateway def1 ഡിഫോൾട്ട് റൂട്ടിനെ 0.0.0.0/1 പ്ലസ് 128.0.0.0/1 ആയി വിഭജിക്കുന്നു, രണ്ടും പുതിയ ഉപകരണത്തിലൂടെ റൂട്ട് ചെയ്യുന്നു, ദൂരെയുള്ള സെർവറിലേക്കുള്ള ഒരു ഹോസ്റ്റ് റൂട്ടിനൊപ്പം അത് ബോധപൂർവം ഭൗതിക ഇന്റർഫേസിൽ പിൻ ചെയ്തിരിക്കുന്നു. ടണലിന് സ്വന്തം ഗതാഗതത്തിന് ഒരു വഴി സൂക്ഷിക്കാനാണ് ഈ പിൻ. ബാക്കിയെല്ലാം, പ്രാദേശിക സെർവർ സ്വന്തം ക്ലയന്റുകൾക്ക് നൽകേണ്ട മറുപടികളും ഉൾപ്പെടെ, ഇപ്പോൾ പുതിയ ഡിഫോൾട്ട് പിന്തുടർന്ന് ദൂരെയുള്ള ലിങ്കിലൂടെ പുറത്തുപോകുന്നു.

അതിനാൽ രണ്ടാം കൂട്ടിയിടി പൊട്ടിയ ടണൽ അല്ല. പട്ടികയിലെ തെറ്റായ സ്ഥലത്ത് പ്രവർത്തിക്കുന്ന ടണലാണ്.

റോളുകൾ വേർതിരിച്ചു നിർത്താനുള്ള മൂന്ന് വഴികൾ

ഏറ്റവും കുറഞ്ഞ ഇടപെടലുള്ള പരിഹാരം ഡിഫോൾട്ട് റൂട്ടിനെ ക്ലയന്റ് പ്രൊഫൈലിൽ നിന്ന് പുറത്തു നിർത്തുന്നു: ദൂരെയുള്ള പ്രിഫിക്സുകൾക്കായി route-nopull പ്ലസ് വ്യക്തമായ route വരികൾ, അതുവഴി പ്രാദേശിക പട്ടിക നിങ്ങൾ ആവശ്യപ്പെട്ടിടത്ത് മാത്രം മാറും. അടുത്ത ഘട്ടം പ്രാദേശിക ടണൽ സബ്നെറ്റിനെ ഒഴിവാക്കുന്ന ഒരു നയനിയമമാണ്, ഡിഫോൾട്ട് റൂട്ട് ഉണ്ടായാലും പ്രാദേശിക ക്ലയന്റുകൾക്കുള്ള മറുപടികൾ വന്ന ഇന്റർഫേസിലൂടെ പുറത്തുപോകാൻ അത് അനുവദിക്കുന്നു. ഏറ്റവും സമഗ്രമായത് ക്ലയന്റ് റോളിനുള്ള പ്രത്യേക നെറ്റ്വർക്ക് നെയിംസ്പേസ് ആണ്, അത് പങ്കിട്ട പട്ടിക പൂർണ്ണമായി നീക്കം ചെയ്യുന്നു, പക്ഷേ രണ്ടാം റൂട്ടിംഗ് സന്ദർഭം പരിപാലിക്കേണ്ടതുണ്ട്.

ഏത് വഴി തിരഞ്ഞെടുത്താലും, ഒഴിവാക്കൽ LAN അല്ല, പ്രാദേശിക ടണൽ സബ്നെറ്റിനെ പേരെടുത്ത് പറയണം. പ്രാദേശിക സെർവർ അയയ്ക്കുന്ന മറുപടിയുടെ ലക്ഷ്യം ഒരു ടണൽ വിലാസമാണ്, അതിനാൽ LAN ആകൃതിയിലുള്ള ഒഴിവാക്കൽ അതിനോട് ഒരിക്കലും ഒത്തുപോകുന്നില്ല.

രണ്ട് ഇൻസ്റ്റൻസുകളിൽ കുറ്റക്കാരൻ ഏതാണ്

ക്ലയന്റ് ഇൻസ്റ്റൻസ് നിർത്തി മൂല ക്ലയന്റുകൾ വീണ്ടും പരിശോധിക്കുക. ഉടനടി വീണ്ടെടുക്കൽ അർത്ഥമാക്കുന്നത് റൂട്ടിംഗ് ആണ്, സെർവർ അല്ല. ക്ലയന്റ് തിരികെ കൊണ്ടുവന്ന്, സ്രോതസ്സും ലക്ഷ്യവും രണ്ട് വിലാസങ്ങളും നൽകിയ ip route get ഉപയോഗിച്ച് ഒരു മറുപടി ട്രേസ് ചെയ്യുക, കേർണൽ തിരഞ്ഞെടുക്കുന്ന പാത അത് കാണിക്കുന്നു, തുടർന്ന് tcpdump -ni any port 1194 ഉപയോഗിച്ച് പാക്കറ്റുകൾ യഥാർത്ഥത്തിൽ ഏത് ഇന്റർഫേസ് ഉപയോഗിക്കുന്നു എന്ന് നിരീക്ഷിക്കുക. സെർവറിന്റെ സ്റ്റാറ്റസ് ഫയൽ, കുറച്ച് സെക്കൻഡുകൾ കൂടുമ്പോൾ status നിർദ്ദേശത്തിലൂടെ എഴുതപ്പെടുന്നു, ബന്ധിപ്പിച്ച ക്ലയന്റ് പട്ടികയും ഇരു ദിശകളിലെയും ബൈറ്റ് കൗണ്ടറുകളും ഉൾക്കൊള്ളുന്നു.

ആ കൗണ്ടറുകൾ പരസ്പരം നോക്കി വായിക്കുക. പുറത്തുപോയി ഒരിക്കലും തിരികെ വരാത്ത ട്രാഫിക് ഹാൻഡ്ഷേക്ക് പ്രശ്നമല്ല, റൂട്ടിംഗിന്റെ ഉത്തരമാണ്.