OpenVPN-ൽ SSM: ഒരു ഉറവിടവും ഗ്രൂപ്പും തുടക്കം മുതൽ അവസാനം വരെ പിന്തുടരൽ

ഒരു സ്ട്രീമും ഒരു സ്വീകർത്താവും തിരഞ്ഞെടുത്ത്, മൾട്ടികാസ്റ്റ് ഒരു വിഭാഗമായി പരീക്ഷിക്കുന്നതിന് പകരം ആ ജോഡിയെ ഓരോ ഹോപ്പിലൂടെയും കൊണ്ടുപോകുക. ഉറവിട-നിർദ്ദിഷ്ട രൂപകൽപ്പന കൃത്യമായി നാലിൽ ഒരു സ്ഥലത്ത് പരാജയപ്പെടുന്നു: സ്വീകർത്താവ് ഒരിക്കലും ചേർന്നില്ല, റൗട്ടർ പാക്കറ്റ് അതിന്റെ മടക്കപ്പാതയിൽ നിരസിച്ചു, കേർണലിന് അവസ്ഥയില്ല, അല്ലെങ്കിൽ ടണൽ ഒരിക്കലും പകർപ്പ് എത്തിച്ചില്ല. ആ ക്രമത്തിൽ പ്രവർത്തിക്കുന്നത് ഓരോ ഹോപ്പിനും കുറച്ച് മിനിറ്റുകൾ എടുക്കും, നാലിൽ ഏതാണ് യഥാർത്ഥത്തിൽ ഉള്ളതെന്ന് പറയും.

ആദ്യം ഉറവിടം, ഗ്രൂപ്പ്, സ്വീകർത്താവ് എന്നിവ ഉറപ്പിക്കുക

ഏതെങ്കിലും ഉപകരണം സ്പർശിക്കുന്നതിന് മുൻപ് മൂന്ന് മൂല്യങ്ങൾ എഴുതുക: അയയ്ക്കുന്ന ഉറവിട വിലാസം, സ്വീകർത്താവ് ചേരുന്ന ഗ്രൂപ്പ് വിലാസം, സ്വീകർത്താവ് ഉള്ള സബ്നെറ്റ്. ഒരു ഉദാഹരണ IPv4 സ്ട്രീമിന്, 10.50.0.10 ഉറവിടവും 232.20.30.40 ഗ്രൂപ്പും ഉറവിട-നിർദ്ദിഷ്ട രൂപകൽപ്പനയ്ക്ക് യോജിക്കുന്ന ജോഡിയാണ്. ഈ മൂന്ന് മൂല്യങ്ങളെക്കാൾ അവ്യക്തമായത് പരീക്ഷിക്കാൻ കഴിയില്ല.

232/8 ശ്രേണി ഉറവിട-നിർദ്ദിഷ്ട മൾട്ടികാസ്റ്റിനായി നീക്കിവച്ചിരിക്കുന്നു, മാതൃക RFC 4607 ൽ വിവരിച്ചിരിക്കുന്നു. നിങ്ങൾ SSM പ്രവർത്തിപ്പിക്കുന്നു എന്ന് വിശ്വസിക്കുമ്പോൾ ഗ്രൂപ്പ് ആ ശ്രേണിക്ക് പുറത്താണെങ്കിൽ, നിർത്തി വിന്യാസം യഥാർത്ഥത്തിൽ എന്താണ് ഉദ്ദേശിക്കുന്നതെന്ന് സ്ഥിരീകരിക്കുക, കാരണം സ്വീകർത്താവിന്റെ ചേരൽ, റൗട്ടറിന്റെ ഫോർവേഡിംഗ് തീരുമാനം എന്നിവ രണ്ടും മാതൃക സ്ഥിരതയുള്ളതായിരിക്കുന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

സ്വീകർത്താവ് ഉറവിടത്തിൽ ചേർന്നോ എന്ന് പരിശോധിക്കുക

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

Linux സ്വീകർത്താവിൽ, സോക്കറ്റ് യഥാർത്ഥത്തിൽ എന്തിലാണ് സബ്സ്ക്രൈബ് ചെയ്തതെന്നും കേർണൽ എന്താണ് രേഖപ്പെടുത്തിയതെന്നും പരിശോധിക്കുക. അപ്ലിക്കേഷന്റെ കോൺഫിഗറേഷൻ ഫയൽ തെളിവല്ല; അംഗത്വ പട്ടികയാണ് തെളിവ്. സ്വീകർത്താവ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുമ്പോൾ അത് വായിക്കുക, കാരണം അത് സൃഷ്ടിച്ച പ്രോസസ് പുറത്തുപോയ ശേഷവും എൻട്രി കുറച്ച് സമയം നിലനിൽക്കാം. മുൻ പരീക്ഷണത്തിൽ നിന്നുള്ള പഴയ എൻട്രി തെറ്റായ ആത്മവിശ്വാസത്തിന്റെ വിശ്വസനീയ ഉറവിടമാണ്.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

പ്രതീക്ഷിച്ച ഉറവിടത്തോടെ ചേരൽ ഉണ്ടെങ്കിൽ, റൗട്ടറുകളിലേക്ക് പോകുക. ഇല്ലെങ്കിൽ, ഒരു ടണൽ കോൺഫിഗറേഷനും സഹായിക്കില്ല, കാരണം ഫോർവേഡ് ചെയ്യാൻ ഒന്നുമില്ല.

ടണൽ നോക്കുന്നതിന് മുൻപ് മടക്കപ്പാത പരിശോധിക്കുക

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

ഉറവിടത്തിലേക്ക് അഭിമുഖമായ റൗട്ടറിൽ, ഉറവിടത്തിലേക്കുള്ള റൂട്ടിനെ പാക്കറ്റുകൾ യഥാർത്ഥത്തിൽ എത്തുന്ന ഇന്റർഫേസുമായി താരതമ്യം ചെയ്യുക. സ്വീകർത്താവിലേക്ക് അഭിമുഖമായ റൗട്ടറിൽ, സ്വീകർത്താവിന്റെ സ്വന്തം സബ്നെറ്റിന് അതേ കാര്യം ചെയ്ത്, പുറത്തേക്കുള്ള ഇന്റർഫേസ് പട്ടികയിൽ അതിലേക്കുള്ള ലിങ്ക് ഉണ്ടെന്ന് സ്ഥിരീകരിക്കുക. ഏത് ദിശയിലും പൊരുത്തക്കേട് RPF പരാജയമാണ്, അംഗത്വ പരാജയമല്ല.

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

കോൺഫിഗറേഷനെക്കാൾ കേർണലിന്റെ മൾട്ടികാസ്റ്റ് അവസ്ഥ വായിക്കുക

കോൺഫിഗറേഷൻ നിങ്ങൾ എന്താണ് ആവശ്യപ്പെട്ടതെന്ന് പറയുന്നു; കേർണൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് പറയുന്നു. ഓരോ Linux ഹോപ്പിലും മൾട്ടികാസ്റ്റ് റൗട്ടിംഗ് എൻട്രികൾ വായിച്ച്, കൃത്യമായ ഉറവിട-ഗ്രൂപ്പ് ജോഡിക്ക് ഇൻപുട്ട്, ഔട്ട്പുട്ട് ഇന്റർഫേസ് പട്ടിക ഉണ്ടെന്ന് സ്ഥിരീകരിക്കുക. വൈൽഡ്കാർഡ് ഉറവിടമുള്ള ഗ്രൂപ്പിനുള്ള എൻട്രി വേറെ ഒബ്ജക്ടാണ്, അത് ഉറവിട-നിർദ്ദിഷ്ട ഫ്ലോ വിശദീകരിക്കില്ല.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

റൗട്ടിംഗ് ഡീമണുകൾ ആ അവസ്ഥയ്ക്ക് മുകളിൽ സ്വന്തം കാഴ്ചപ്പാട് സൂക്ഷിക്കുന്നു, അത് പ്രിന്റ് ചെയ്യുന്ന കമാൻഡ് ഏത് ഇംപ്ലിമെന്റേഷൻ ഇൻസ്റ്റാൾ ചെയ്തിരിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. തത്വം സ്ഥിരമാണ്: ജോഡിക്ക് ഡീമണിനോട് അതിന്റെ അപ്സ്ട്രീം എൻട്രി ചോദിക്കുക, പിന്നീട് ഫോർവേഡിംഗ് എൻട്രി ഉണ്ടോ എന്ന് കേർണലിനോട് ചോദിക്കുക. കേർണലിന് എൻട്രി ഇല്ലാതിരിക്കെ ഫോർവേഡ് ചെയ്യുന്നു എന്ന് കരുതുന്ന ഡീമൺ ആ ഹോസ്റ്റിലെ കോൺഫിഗറേഷൻ പരിധിയുടെ പ്രശ്നമാണ്.

രണ്ടും യോജിക്കാത്തപ്പോൾ, VPN അല്ല ഹോസ്റ്റ് ശരിയാക്കുക. നിങ്ങൾ ചോദിച്ച ഫ്ലോ ഫോർവേഡ് ചെയ്യാത്ത ഹോപ്പിന് താഴെയുള്ള ഒന്നിനും പകരം വയ്ക്കാനാവില്ല. സ്ട്രീം പ്രവർത്തിക്കുമ്പോൾ ഓരോ ഹോപ്പിനും ജോഡി, ഇൻപുട്ട് ഇന്റർഫേസ്, ഔട്ട്പുട്ട് പട്ടിക എന്നിവ രേഖപ്പെടുത്തുക. ആ രേഖ അടുത്ത പരാജയത്തെ പുതിയ അന്വേഷണത്തിന് പകരം താരതമ്യമാക്കി മാറ്റുന്നു.

ടണൽ യഥാർത്ഥത്തിൽ എങ്ങനെ പകർപ്പെടുക്കുന്നു എന്ന് തീരുമാനിക്കുക

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

ഒന്നിലധികം സ്വീകർത്താക്കൾക്ക് മൾട്ടിപോയിന്റ് സർവറിലൂടെ, പകർപ്പെടുക്കൽ വ്യക്തമായി രൂപകൽപ്പന ചെയ്യണം. ഗേറ്റ്വേയിൽ മൾട്ടികാസ്റ്റ് റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ഏത് പിയറുകൾ പകർപ്പ് സ്വീകരിക്കണം എന്ന് VPN സർവറിനെ പഠിപ്പിക്കുന്നില്ല, ക്ലയന്റ് ഭാഗത്തുള്ള ഒരു റൂട്ടും ആ തീരുമാനം അതിന് പകരം എടുക്കുന്നില്ല. ആവശ്യകത പല സ്വീകർത്താക്കളാകുമ്പോൾ, പിന്തുണയുള്ള പകർപ്പെടുക്കലോ ബോധപൂർവം തിരഞ്ഞെടുത്ത ബദലോ ഉപയോഗിക്കുക, ഏതാണ് തിരഞ്ഞെടുത്തതെന്ന് എഴുതുക.

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