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

മൂന്ന് വാഗ്ദാനങ്ങൾ, ഒന്നിന് മാത്രം പങ്കാളി വേണം

ഫെയിൽഓവർ ഇഷ്ടപ്പെട്ട ലിങ്ക് അപ്രത്യക്ഷമാകുമ്പോഴും ഒരു പാത ലഭ്യമായി നിലനിർത്തുന്നു. പ്രവാഹ ഹാഷ് ബാലൻസിംഗ് സ്വതന്ത്ര പ്രവാഹങ്ങളെ രണ്ട് അപ്‌ലിങ്കുകളിലും വ്യാപിപ്പിക്കുന്നു. ഒരു പ്രവാഹത്തിന്റെ ഏകീകരണം ഒരു കൈമാറ്റത്തിന് രണ്ട് ലിങ്കുകളും ഒരേസമയം ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു. ഇവ വ്യത്യസ്ത ആവശ്യകതകളുള്ള വ്യത്യസ്ത ഉൽപ്പന്നങ്ങളാണ്, അവസാനത്തേതിന് മാത്രം നിങ്ങളുടെ റൂട്ടറിന് പുറത്തുള്ള എന്തിന്റെയെങ്കിലും സഹകരണം വേണം.

MechanismFar-end requirementEffect on one transferWhat breaks under a link loss
Packet-spraying overlayA cooperating endpoint that reassembles the streamPackets can spread across both linksReordering and buffering on the surviving path; its own recovery logic decides what continues
MPTCP subflowsA peer or proxy that accepts subflowsSubflows can share one connectionSurviving subflows continue if the peer keeps them alive
Flow-hash balancingNothing new; the existing tunnel endpoint is enoughOne outer flow still follows one linkFlows hashed onto the dead link move; established sessions break
Link failoverNothing newOne path at a time; the second link sits idleThe session stalls or restarts on the other link

ആ പട്ടികയിൽ രണ്ടാം ലൈൻ വാങ്ങാനുള്ള കാരണമായി ഒന്നുമില്ല. അത് ചെയ്യുന്നത് ഇതാണ്: ഫെയിൽഓവർ രൂപകൽപ്പനയെ ബോണ്ടിംഗ് എന്ന് വിലയിരുത്തുന്നത് തടയുന്നു.

റൂട്ടറിന് ടണൽ ഒരു പ്രവാഹമായി തോന്നുന്നത് എന്തുകൊണ്ട്

ലോഡ് ബാലൻസ് ചെയ്യുന്ന റൂട്ടർ ഉറവിട, ലക്ഷ്യ വിലാസങ്ങൾ പോർട്ടുകളോടൊപ്പം ഹാഷ് ചെയ്ത്, പിന്നീട് മുഴുവൻ പ്രവാഹവും ഹാഷ് ചൂണ്ടുന്നിടത്തേക്ക് അയയ്ക്കുന്നു. റൂട്ടറിന്റെ കാഴ്ചപ്പാടിൽ VPN ടണൽ അത്തരം ഒരു പ്രവാഹമാണ്, അതിനുള്ളിൽ എന്ത് പ്രവർത്തിച്ചാലും. ആന്തരിക കണക്ഷനുകൾ ഒരിക്കലും ഹാഷ് തീരുമാനത്തിലെത്തുന്നില്ല, കാരണം പുറം ഹെഡർ ഇതിനകം പാത തീരുമാനിച്ചു. അതുകൊണ്ടാണ് രണ്ടാം അപ്‌ലിങ്ക് പല ഉപയോക്താക്കൾക്കും ആകെ ശേഷി ഇരട്ടിയാക്കാനും ഒരു ഉപയോക്താവിന്റെ വലിയ കൈമാറ്റത്തിൽ ഒന്നും മാറ്റാനും കഴിയാത്തത്.

രണ്ട് വേറിട്ട ടണലുകൾ നിങ്ങൾക്ക് രണ്ട് സ്ഥാനാർത്ഥികളെ തരാം, പക്ഷേ അവയ്ക്ക് ഇപ്പോഴും ട്രാഫിക് അനുവദിക്കുകയും അഭ്യർത്ഥന കൊണ്ടുപോയ പാതയിൽ തന്നെ മറുപടികൾ നിർത്തുകയും ചെയ്യുന്ന ബോധപൂർവമായ ഒരു നയം വേണം. ആ ഘട്ടം ഒഴിവാക്കുന്നതിന്റെ സാധാരണ ഫലമാണ് അസമമായ റൂട്ടിംഗ്. കുറഞ്ഞത് പ്രവാഹം, ഇഷ്ടപ്പെട്ട ലിങ്ക്, ബാക്കപ്പ് ലിങ്ക് എന്നിവ പേരിടുന്ന നയമാണ്.

ഇഥർനെറ്റ് ബോണ്ടിംഗ് ബന്ധമില്ലാത്ത ദാതാക്കളെ മറികടക്കുന്നില്ല, കാരണം ദൂരെ അറ്റം ഏകീകരണ പ്രോട്ടോക്കോളിൽ പങ്കെടുക്കണം. സഹകരിക്കുന്ന ഒരു അന്ത്യബിന്ദു ഇല്ലെങ്കിൽ രണ്ട് ISP-കൾക്കിടയിലുള്ള ബോണ്ടിംഗ് ഒരു ഗവേഷണ പദ്ധതിയാണ്.

മൾട്ടിപാത്ത് TCP-യ്ക്ക് രണ്ടറ്റത്തും വേണ്ടത്

Linux-ന്റെ Multipath TCP രേഖകൾ ഒരു കണക്ഷനിൽ ഉൾപ്പെടുന്ന നിരവധി ഉപപ്രവാഹങ്ങൾ വിവരിക്കുന്നു. ഒരറ്റത്ത് കേർണൽ പിന്തുണ മാത്രം ഒന്നും മാറ്റുന്നില്ല, കാരണം എതിർകക്ഷിയും ആ ഉപപ്രവാഹങ്ങൾ സ്വീകരിക്കണം. ദൂരെ വശത്ത് പ്രോക്സി മറ്റൊരു സാധാരണ ക്രമീകരണമാണ്, അത് സ്വന്തം ശേഷിയും ലഭ്യതയുമുള്ള ഘടകമായി മാറുന്നു, അവ ആസൂത്രണം ചെയ്യണം. അതേ യുക്തി WireGuard-ന് എളുപ്പവഴി നിഷേധിക്കുന്നു, അതിന്റെ ഗതാഗതം UDP ആണ്: MPTCP TCP ഉപപ്രവാഹങ്ങൾ വളർത്തുന്നു, രൂപകൽപ്പനയിൽ മറ്റൊന്നും ഇല്ലാതെ ആ ടണൽ ഏകീകരിക്കാനാവില്ല.

കേർണൽ സവിശേഷത സജീവമാണോ എന്ന് അതിനെ ആശ്രയിച്ച് രൂപകൽപ്പന ചെയ്യുന്നതിന് മുൻപ് പരിശോധിക്കുക, കാരണം പല വിതരണങ്ങളും അത് ഓഫാക്കിയാണ് നൽകുന്നത്. ഈ മൂന്ന് കമാൻഡുകൾ ഒരു മിനിറ്റിൽ അതിന് ഉത്തരം നൽകും.

sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits show

ബ്രോഷറല്ല, ജോലിഭാരം നോക്കി തിരഞ്ഞെടുക്കുക

ജോലിഭാരം നിരവധി സ്വതന്ത്ര സെഷനുകളാണെങ്കിൽ, പ്രവാഹ ഹാഷ് ബാലൻസിംഗിന് ദൂരെ അറ്റത്തിന്റെ സഹകരണമില്ലാതെ ശേഷി കൂട്ടാം. ഒരു വലിയ കൈമാറ്റമാണെങ്കിൽ, ഏകീകരണ രൂപകൽപ്പന മാത്രമേ സഹായിക്കൂ, ആ രൂപകൽപ്പനയ്ക്ക് സഹകരിക്കുന്ന പങ്കാളി വേണം. ലിങ്ക് മരിക്കുമ്പോഴും ജോലി തുടരണം എന്നതാണ് ആവശ്യമെങ്കിൽ, ഉത്തരം ഫെയിൽഓവറാണ്, ഒരു കൈമാറ്റത്തിന്റെ ത്രൂപുട്ട് പ്രസക്തമല്ല.

ആവശ്യകത ഒരു ക്രിയയുള്ള ഒറ്റ വാക്യത്തിൽ എഴുതുക: ഒരു ബാക്കപ്പ് ഇരട്ടി വേഗത്തിൽ തീരുന്നു, അല്ലെങ്കിൽ വീണ ലിങ്ക് ഒരു സെഷൻ അവസാനിപ്പിക്കുന്നില്ല. അവ്യക്തമായ ലക്ഷ്യങ്ങൾ ആർക്കും സ്വീകരിക്കാനോ നിരസിക്കാനോ കഴിയാത്ത രൂപകൽപ്പനകൾ സൃഷ്ടിക്കുന്നു. പിന്നീട് ദൂരെ അറ്റം എന്താകാം എന്ന് തീരുമാനിക്കുക, കാരണം ഏറ്റവും വിലകുറഞ്ഞ ഓപ്ഷൻ പലപ്പോഴും അവിടെ പുതിയതായി ഒന്നും ആവശ്യപ്പെടാത്തതാണ്. ആ നിയന്ത്രണം ആദ്യ യോഗത്തിന് മുൻപ് തന്നെ ബ്രോഷറിലെ മിക്ക അവകാശവാദങ്ങളും ഒഴിവാക്കുന്നു.

ആവശ്യകതാ രേഖയിൽ മൂന്ന് വാഗ്ദാനങ്ങളും വേർതിരിച്ച് സൂക്ഷിക്കുക. മൂന്നും അവകാശപ്പെടുന്ന ഒരു രൂപകൽപ്പന സാധാരണയായി ഒന്ന് നൽകി ബാക്കിയുള്ളവ നിശബ്ദമായി അനുമാനിക്കുന്നു. അടുത്ത ഭാഗം യഥാർത്ഥത്തിൽ ഏതാണ് നൽകുന്നതെന്ന് പരിശോധിക്കുന്നു.

ഒരു കൈമാറ്റവും പലതും പരിശോധിച്ച്, പിന്നീട് ഒരു ലിങ്ക് വലിച്ചെടുക്കുക

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

ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5

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

അനുബന്ധ ലേഖനങ്ങൾ