MULTI: ക്ലൈന്റിൽ നിന്നുള്ള തെറ്റായ ഉറവിട വിലാസം: അത് ആരുടെ വിലാസമായിരുന്നു?
ആന്തരിക ഉറവിടം അത് എത്തിച്ച ക്ലൈന്റുമായി ഒത്തുപോകുന്നില്ല. അതിനെ ഒരു ടണൽ അനുവദനം, ക്ലൈന്റിന് പിന്നിലുള്ള LAN, അല്ലെങ്കിൽ ഇരട്ടി ഐഡന്റിറ്റി എന്നിവയുമായി ഒത്തുനോക്കുക.
സർവർ ലോഗ് MULTI: bad source address from client അച്ചടിക്കുന്നു, പാക്കറ്റ് ഉപേക്ഷിക്കുന്നു, സെഷൻ ബന്ധിപ്പിച്ചിരിക്കുന്നു. ഈ കൂട്ടിക്കെട്ട് സന്ദേശത്തെ പ്രാമാണീകരണ പരാജയമായി വായിക്കുന്നവരെ ആശയക്കുഴപ്പത്തിലാക്കുന്നു. അങ്ങനെയല്ല: ക്ലൈന്റ് പ്രാമാണീകരിച്ചിട്ടുണ്ട്, എത്തിയ പാക്കറ്റ് സർവറിന് ആ ക്ലൈന്റ് പതിപ്പുമായി ബന്ധിപ്പിക്കാൻ കഴിയാത്ത ആന്തരിക ഉറവിട വിലാസം വഹിച്ചിരുന്നു. പരിശോധന എത്തിക്കുന്നതിന് മുമ്പ് നടക്കുന്നു, അതിനാൽ ടണൽ ആരോഗ്യകരമായി കാണുന്നു, പക്ഷേ അതിലൂടെ ഉപയോഗപ്രദമായ ഒന്നും കടക്കുന്നില്ല.
എത്തിക്കുന്നതിന് മുമ്പ് സർവർ എന്താണ് താരതമ്യം ചെയ്യുന്നത്
ക്ലൈന്റിൽ നിന്ന് വരുന്ന ഓരോ പാക്കറ്റിനും, ഉപയോക്തൃ ഇടത്തിലുള്ള സർവർ ടണലിനുള്ളിലെ ഉറവിട വിലാസം നോക്കി, ആ വിലാസം ഏത് ക്ലൈന്റിന്റേതാണെന്ന് തന്റെ ആന്തരിക റൂട്ടിംഗ് അവസ്ഥയോട് ചോദിക്കുന്നു. ഉടമ മറ്റൊരു പതിപ്പാണെങ്കിൽ, അല്ലെങ്കിൽ ഉടമയേ ഇല്ലെങ്കിൽ, പാക്കറ്റ് ഒഴിവാക്കപ്പെടുന്നു, മുന്നറിയിപ്പ് പുറപ്പെടുവിക്കുന്നു.
ടണൽ ഇന്റർഫേസിലൂടെയുള്ള സാധാരണ എത്തിക്കൽ ഒരിക്കലും സംഭവിക്കുന്നില്ല.
ആ ക്രമമാണ് ആളുകളെ അമ്പരപ്പിക്കുന്ന ഒരു വിശദാംശം വിശദീകരിക്കുന്നത്: ഹോസ്റ്റ് ഫയർവാളിന്റെ കൗണ്ടറുകൾ അനങ്ങുന്നില്ല, കാരണം പാക്കറ്റ് ഫയർവാളിൽ എത്തിയിട്ടേയില്ല. ഹോസ്റ്റിൽ റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗ് ക്രമീകരിക്കുന്നത് ഇവിടെ ഒന്നും മാറ്റുന്നില്ല, കാരണം നിരസിക്കൽ ഡീമണിന്റെ സ്വന്തം അസോസിയേഷൻ പരിശോധനയിലാണ് സംഭവിച്ചത്. സന്ദേശത്തെ ഉടമസ്ഥതയെക്കുറിച്ചുള്ള ഒരു പ്രസ്താവനയായി വായിക്കുക, തുടർന്ന് മൂന്ന് സാഹചര്യങ്ങളിൽ ഏതാണ് അത് സൃഷ്ടിച്ചതെന്ന് കണ്ടെത്തുക.
ഒത്തുപോകാത്ത ആന്തരിക വിലാസത്തിന്റെ മൂന്ന് ഉറവിടങ്ങൾ
ക്ലൈന്റ് തനിക്ക് അനുവദിക്കപ്പെടാത്ത വിലാസത്തിൽ നിന്നോ, ആരും തന്റേതെന്ന് പ്രഖ്യാപിക്കാത്ത ഒരു നെറ്റ്വർക്കിൽ നിന്നോ, ഇതിനകം ഉടമയുള്ള ഒരു ഐഡന്റിറ്റിയുടെ പകർപ്പിൽ നിന്നോ അയയ്ക്കുന്നതാകാം. മൂന്നും ഒരേ ലോഗ് വരി സൃഷ്ടിക്കുന്നു. അവ വ്യത്യസ്തമാകുന്നത് നിങ്ങൾ എന്ത് മാറ്റണം എന്നതിലാണ്. വിലാസത്തിൽ നിന്നും നിലവിലെ അനുവദന പട്ടികയിൽ നിന്നും തുടങ്ങുക, ആ രണ്ട് വസ്തുതകൾക്ക് കേസ് തിരഞ്ഞെടുക്കാൻ അനുവദിക്കുക.
അവയെ വേർതിരിക്കാൻ രണ്ട് വസ്തുതകൾ വേണം: ലോഗിലെ നിരസിക്കപ്പെട്ട വിലാസം, സർവർ നിലവിലേതായി കണക്കാക്കുന്ന അനുവദനകൾ. രണ്ടാമത്തത് പ്രവർത്തിക്കുന്ന പതിപ്പിന്റെ സ്റ്റാറ്റസ് അല്ലെങ്കിൽ മാനേജ്മെന്റ് കാഴ്ചയിൽ ലഭ്യമാണ്, കൂടാതെ കോൺഫിഗറേഷൻ ഫയൽ നിലവിലെ അവസ്ഥയല്ല, ഉദ്ദേശ്യങ്ങളാണ് രേഖപ്പെടുത്തുന്നത്, അതിനാൽ അതാണ് കൂടിയാലോചിക്കാൻ യോഗ്യമായ ഏക അധികാരം.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് രണ്ടും രേഖപ്പെടുത്തുക, തുടർന്ന് വർഗ്ഗീകരിക്കുക. പിന്നീട് എടുത്ത സ്ക്രീൻഷോട്ട് മുന്നറിയിപ്പ് സൃഷ്ടിച്ച അവസ്ഥയുടെ രേഖയല്ല. അനുവദനകൾ സെഷനുകൾക്കിടയിൽ നീങ്ങുന്നതിനാൽ സമയ മുദ്രയും സൂക്ഷിക്കുക.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
ക്ലൈന്റിന് പിന്നിലുള്ള LAN-ഉം iroute-ഉം
ഒരു സൈറ്റ് ക്ലൈന്റ് സ്വന്തം സ്വകാര്യ നെറ്റ്വർക്ക് റൂട്ട് ചെയ്യുമ്പോൾ, ആ നെറ്റ്വർക്ക് ക്ലൈന്റിന്റേതാണെന്ന് പ്രഖ്യാപിക്കണം. iroute എൻട്രിയുള്ള ക്ലൈന്റ്-നിർദ്ദിഷ്ട ഫയൽ അത് ചെയ്യുന്നു, എൻട്രി ക്ലൈന്റിന് വഹിക്കാൻ അനുവാദമുള്ള പ്രിഫിക്സ് പേരിടുന്നു.
അതേ പ്രിഫിക്സ് ടണലിലേക്ക് ചൂണ്ടുന്ന കെർണൽ റൂട്ട് വേറിട്ട ആവശ്യകതയാണ്, അത് ചേർക്കുന്നത് ഡീമണിന്റെ ആന്തരിക ഉടമസ്ഥതയിൽ ഒന്നും മാറ്റുന്നില്ല.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0ഫലപ്രദമായ ഐഡന്റിറ്റി ഫയൽ നാമവുമായി ഒത്തുപോകുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം പൊരുത്തക്കേട് എന്നാൽ ഫയൽ ഒരിക്കലും ലോഡ് ചെയ്യപ്പെടുന്നില്ല എന്നാണ്, ലക്ഷണം കാണാത്ത എൻട്രിയുടേതിന് സമാനമാണ്. മുന്നറിയിപ്പ് ശാന്തമാക്കാൻ വീതിയുള്ള iroute ചേർക്കരുത്, കാരണം അത് അപ്രതീക്ഷിതമായ ഉറവിടത്തെ അനുവദിച്ചതാക്കി മാറ്റുന്നു, ക്ലൈന്റ് അത് എന്തിന് അയച്ചു എന്നതിന് ഉത്തരം നൽകാതെ. OpenVPN 2.6 കൈപ്പുസ്തകം iroute, duplicate-cn, ഐഡന്റിറ്റി മാപ്പിംഗ് എന്നിവ വേറിട്ട നിയന്ത്രണങ്ങളായി രേഖപ്പെടുത്തുന്നു.
രണ്ട് യന്ത്രങ്ങളിൽ ഒരേ ഐഡന്റിറ്റി
രണ്ടാമത്തെ ലാപ്ടോപ്പിലേക്ക് പകർത്തിയ പ്രൊഫൈൽ അതേ സർട്ടിഫിക്കറ്റും അതേ പൊതു നാമവും വഹിക്കുന്നു. സർവർ ക്രമീകരണങ്ങളെ ആശ്രയിച്ച്, പുതിയ കണക്ഷൻ പഴയതിനെ മാറ്റിസ്ഥാപിക്കാം, ഉടമസ്ഥതയുള്ള പതിപ്പാണ് അസോസിയേഷൻ പരിശോധനയിൽ വിജയിക്കുന്നത്.
അത് തകരാറിനെ ഇടയ്ക്കിടെയുള്ളതായി കാണിക്കുന്നു, രണ്ട് ഉപകരണങ്ങളും ഉണർന്നിരിക്കുമ്പോൾ മാത്രമാണ് അത് പ്രത്യക്ഷപ്പെടുന്നത്.
ഇരട്ടി പൊതു നാമങ്ങൾ അനുവദിക്കുന്നത് രണ്ടിനെയും ബന്ധിപ്പിക്കാൻ അനുവദിക്കുന്നു, പക്ഷേ സ്വതന്ത്ര സ്ഥിര വിലാസങ്ങളോ സ്വതന്ത്ര ഉടമസ്ഥതയോ നൽകുന്നില്ല. രണ്ട് ഉപകരണങ്ങൾ ഒരുമിച്ച് നിലനിൽക്കണമെങ്കിൽ, ഓരോന്നിനും സ്വന്തം ഐഡന്റിറ്റിയും സ്വന്തം അനുവദനയും ഉണ്ടാകാൻ അവ വെവ്വേറെ രജിസ്റ്റർ ചെയ്യുക. ഇരട്ടി ക്രമീകരണത്തെ ഈ മുന്നറിയിപ്പിന്റെ പരിഹാരമായി കാണുന്നത് രഹസ്യം അതേ സ്ഥലത്ത് നിർത്തി മറ്റൊന്ന് കൂട്ടിച്ചേർക്കുന്നു.
അസോസിയേഷൻ മാറിയെന്ന് തെളിയിക്കുക
കോൺഫിഗറേഷന്റെ ഉടമയിലൂടെ തിരുത്തൽ പ്രയോഗിക്കുക, തുടർന്ന് പുതിയ നയം ലോഡ് ചെയ്യാൻ ബാധിത ക്ലൈന്റ് വീണ്ടും ബന്ധിപ്പിക്കുക.
അതേ ഒഴുക്ക് ആവർത്തിച്ച് മൂന്ന് കാര്യങ്ങൾ ഉറപ്പാക്കുക: പാക്കറ്റിന്റെ ആന്തരിക ഉറവിടം, സർവർ അതിനെ ബന്ധിപ്പിക്കുന്ന ക്ലൈന്റ് പതിപ്പ്, തുടർന്ന് ലക്ഷ്യസ്ഥാനത്തിന്റെ പെരുമാറ്റം.
മുന്നറിയിപ്പ് നിലച്ചാലും അപ്ലിക്കേഷൻ ഇപ്പോഴും പരാജയപ്പെടുന്നുവെങ്കിൽ, പ്രശ്നം അപ്രത്യക്ഷമായല്ല, സ്ഥലം മാറിയതാണ്. ഫോർവേഡിംഗ്, ഫയർവാൾ നിയമങ്ങൾ, തിരിച്ചുള്ള പാത എന്നിവ വേറിട്ട ഘട്ടങ്ങളാണ്, അസോസിയേഷൻ പരിശോധന കടന്നുപോകുന്നു എന്നത് പാക്കറ്റിന് ടണൽ വിടാൻ അനുമതി ലഭിച്ചു എന്ന് മാത്രമാണ് അർത്ഥമാക്കുന്നത്.