ഒരു Pi-യിൽ രണ്ട് VPN ഹോപ്പ്: ഏത് റൂട്ട് ഏത് പിയറിനെ വഹിക്കുന്നു
ഒരു Pi-യിൽ രണ്ട് ടണൽ വിലാസങ്ങൾ തകരാറല്ല. ഓരോ ലക്ഷ്യസ്ഥാനത്തിനും സ്വന്തം വാഹകനും സ്വന്തം തെളിവും പുറം ഹോപ്പ് മരിക്കുമ്പോൾ പ്രഖ്യാപിത ബാക്കപ്പും വേണം.
ഒരു ചെറിയ ബോർഡിൽ രണ്ട് ടണൽ വിലാസങ്ങൾ തെറ്റായി തോന്നുന്നു, പ്രതികരണം ഒന്ന് മായ്ക്കുക എന്നതാണ്. ആ പ്രതികരണം ക്രമീകരിക്കേണ്ടതിനെ തന്നെ തകർക്കുന്നു. രണ്ട് ഹോപ്പ് വഹിക്കുന്ന ഹോസ്റ്റ് ഓരോ കണക്ഷനും ഒരു വിലാസം സൂക്ഷിക്കുന്നു, ഓരോ വിലാസവും വ്യത്യസ്ത റൂട്ട് തിരഞ്ഞെടുക്കുന്നു. ചോദിക്കാൻ അർഹമായ ചോദ്യം ഏത് റൂട്ട് ഏത് ലക്ഷ്യസ്ഥാനത്തിന് ഏത് വാഹകനെ തിരഞ്ഞെടുക്കുന്നു എന്നതാണ്, എത്ര വിലാസങ്ങൾ ഉണ്ട് എന്നല്ല.
വ്യത്യസ്ത വാഹകർ ആവശ്യമുള്ള മൂന്ന് ലക്ഷ്യസ്ഥാനങ്ങൾ
രണ്ട് ഹോപ്പിന്റെ ശൃംഖല ഒന്നിനൊന്ന് മേൽ ക്രമീകരിച്ച മൂന്ന് ലക്ഷ്യ വർഗ്ഗങ്ങളാണ്, ഓരോന്നിനെയും വ്യത്യസ്ത കണക്ഷൻ വഹിക്കുന്നു. പുറം പിയറിൽ ഭൗതിക ലിങ്കിലൂടെ എത്തണം. അകം പിയറിൽ പുറം ടണലിലൂടെ എത്തണം. മറയ്ക്കപ്പെട്ട ആപ്ലിക്കേഷന്റെ ലക്ഷ്യസ്ഥാനത്ത് അകം ടണലിലൂടെ എത്തണം, അതിന്റെ സ്വന്തം ഗതാഗതം പുറം ടണൽ വഹിക്കുന്നു.
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
റൂട്ട് സ്പർശിക്കുന്നതിന് മുമ്പ് വരികൾ വായനക്കാരന്റെ യഥാർത്ഥ വിലാസങ്ങൾ കൊണ്ട് നിറയ്ക്കുക, കാരണം പട്ടിക കൃത്യമാകുമ്പോൾ മാത്രമേ ഉപകരിക്കൂ. പ്രവർത്തിക്കുന്ന ശൃംഖല നാല് വരികളെയും ഒരുമിച്ച് തൃപ്തിപ്പെടുത്തുന്നു, പകുതി പ്രവർത്തിക്കുന്ന ശൃംഖല സാധാരണയായി അവയിലൊന്നിനെ തെറ്റായ വാഹകനോടെ തൃപ്തിപ്പെടുത്തുന്നു. തെറ്റായ വരിയെ തകരാറായി വായിക്കുന്നതാണ് റൂട്ടിംഗ് പ്രശ്നത്തെ പൂർണ്ണ ഉച്ചയിലെ തിരുത്തലുകളാക്കി മാറ്റുന്നത്.
വിലാസങ്ങൾക്ക് എണ്ണമല്ല, പങ്കുകളാണുള്ളത്
ലിനക്സ് ഒരു ഇന്റർഫേസിൽ പല വിലാസങ്ങളും ഒരു ഹോസ്റ്റിൽ പല ടണലുകളും അനുവദിക്കുന്നു, അതിനാൽ എണ്ണം കൃത്യതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. പ്രധാനം ഏത് വിലാസം ഏത് കണക്ഷനുള്ളതാണ് എന്നതും, ഒരു നിർദ്ദിഷ്ട പിയറിനുള്ള റൂട്ട് നിങ്ങൾ ഉദ്ദേശിച്ച കണക്ഷൻ തിരഞ്ഞെടുക്കുന്നുണ്ടോ എന്നതുമാണ്. മൂന്ന് കാഴ്ചകൾ അതിന് മൂന്ന് ദിശകളിൽ നിന്ന് ഉത്തരം നൽകുന്നു, ഓരോ തവണയും അതേ ക്രമത്തിൽ അവ വായിക്കാൻ യോഗ്യമാണ്.
വിലാസ പട്ടിക എന്തുണ്ടെന്നും ഏത് കണക്ഷൻ അതിന്റെ ഉടമയാണെന്നും കാണിക്കുന്നു. റൂട്ട് പട്ടിക സാധാരണ ലക്ഷ്യ ഗതാഗതത്തിന് വാഹക ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. നയ കാഴ്ച ഉറവിടമോ അടയാളമോ അനുസരിച്ച് തിരഞ്ഞെടുത്ത ഗതാഗതത്തിന് വീണ്ടും ഉത്തരം നൽകുന്നു, രണ്ട് ക്ലയന്റുകൾ ഒരു ഹോസ്റ്റ് പങ്കിടുമ്പോൾ ഇതാണ് സാധാരണ ക്രമീകരണം.
ip -4 addr show
ip -4 route show table all
ip rule showപട്ടിക നീളമുള്ളതായി തോന്നിയതിനാൽ വിലാസം മായ്ക്കുന്നത് പാതയുടെ ഒരു ഭാഗം നീക്കം ചെയ്യാം, അധികമായി തോന്നിയതിനാൽ റൂട്ട് മായ്ക്കുന്നത് അതേ കാര്യം കൂടുതൽ നിശബ്ദമായി ചെയ്യുന്നു. രണ്ടും പിശക് ഉണ്ടാക്കുന്നില്ല; പിയർ നിങ്ങൾ ഉദ്ദേശിച്ച പാതയിൽ ഉത്തരം നൽകുന്നത് നിർത്തുന്നു, പക്ഷേ മറ്റൊരു പാതയിലൂടെ എത്താവുന്നതായി തുടരുന്നു. അകം പിയറിന്റെ പുറത്തേക്കുള്ള വിലാസം റിപ്പോർട്ട് ചെയ്യുന്ന ആപ്ലിക്കേഷൻ ഗതാഗതം പുറം ടണൽ കടന്നു എന്ന് തെളിയിക്കുന്നില്ല, കാരണം നേരിട്ടുള്ള പ്രവേശനം അതേ നിരീക്ഷണം നൽകുന്നു. നിരീക്ഷണവും തെളിവും തമ്മിലുള്ള ഈ വിടവാണ് റൂട്ടിംഗ് പാളിയിൽ വാഹകനെ പരിശോധിക്കുന്നതിന്റെ കാരണം.
സജീവമാക്കൽ ക്രമം സ്ഥിരമായ ഉറക്കത്തെ തോൽപ്പിക്കുന്നു
അകം ക്ലയന്റ് പുറം ക്ലയന്റ് നൽകുന്ന വിലാസത്തെയോ റൂട്ടിനെയോ ആശ്രയിക്കുന്നുവെങ്കിൽ, സജീവമാക്കൽ കാലതാമസത്തിനല്ല, ആ വിഭവത്തിനായി കാത്തിരിക്കണം. ഉറക്കം പുറം ടണൽ മന്ദഗതിയിലാകുന്ന ദിവസം വരെ പ്രവർത്തിക്കുന്നു, പിന്നീട് ആർക്കും പുനരാവിഷ്കരിക്കാനാകാത്ത രീതിയിൽ ഇടവിട്ട് പരാജയപ്പെടുന്നു. ആശ്രിതത്വങ്ങളെ അടിസ്ഥാനമാക്കിയ ക്രമം ഊഹം നീക്കുന്നു, ആശ്രിതത്വം ഒരിക്കൽ വിവരിക്കുന്നതല്ലാതെ മറ്റൊന്നും ചെലവാക്കുന്നില്ല. ഇന്റർഫേസ് പേരുകളും ക്രമത്തിന്റെ സംവിധാനമല്ല.
കേർണൽ tun0, tun1 പോലുള്ള പേരുകൾ സൃഷ്ടി ക്രമത്തിൽ നൽകുന്നു, ആ ക്രമം പുനരാരംഭങ്ങൾക്കോ വീണ്ടും കണക്ട് ചെയ്യലുകൾക്കോ ഇടയിൽ മാറാം. കോൺഫിഗറേഷൻ ടൂൾ നൽകുന്ന ഐഡന്റിറ്റിയിലേക്കോ നിങ്ങൾ ബോധപൂർവം നൽകുന്ന പേരിലേക്കോ ബന്ധിപ്പിക്കുക. നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന പേര് കരാർ; കേർണൽ തിരഞ്ഞെടുക്കുന്ന പേര് യാദൃച്ഛികത.
ഓരോ ക്ലയന്റിന്റെയും ഗതാഗതം മറ്റേതിന്റെ ആപ്ലിക്കേഷൻ റൂട്ടിൽ നിന്ന് പുറത്ത് നിർത്തുക, OpenVPN 2.6 റൂട്ടിംഗ് ഓപ്ഷനുകൾ യഥാർത്ഥത്തിൽ എന്ത് വാഗ്ദാനം ചെയ്യുന്നു എന്നതിൽ കൃത്യമായിരിക്കുക. രേഖപ്പെടുത്തിയ സ്ഥിരസ്ഥിതി റീഡയറക്ഷൻ സംവിധാനം ക്ലയന്റിന് നിലവിലുള്ള ഗേറ്റ്വേയിലൂടെ സ്വന്തം വിദൂര പിയറിൽ എത്താൻ കഴിയുന്നതായി നിലനിർത്തുന്നു, ഇത് ഒരു നിർദ്ദിഷ്ട ആവർത്തന ലൂപ്പ് മുറിക്കുന്നു. അത് ഒരു ക്ലയന്റിനെ മറ്റൊന്നിന്റെ വാഹകനാക്കുന്നില്ല, അതിനാൽ ശൃംഖലയുടെ ബാക്കി നിങ്ങളുടെ രൂപകൽപ്പനയായി തുടരുന്നു. ശൃംഖലയ്ക്ക് റൂട്ടിന് പകരം നയം വേണ്ടിടത്ത് വ്യക്തമായ ഉറവിട അല്ലെങ്കിൽ അടയാള നിയമം എഴുതി അത് പൊരുത്തപ്പെടേണ്ട ഗതാഗതത്തോടൊപ്പം പരീക്ഷിക്കുക.
പുറം ഹോപ്പ് മരിക്കുമ്പോൾ എന്ത് സംഭവിക്കുന്നു
ശൃംഖല പൂർണ്ണമെന്ന് കണക്കാക്കുന്നതിന് മുമ്പ്, പുറം ഹോപ്പ് അപ്രത്യക്ഷമാകുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുക. അകം ക്ലയന്റിന്റെ ഗതാഗതം അതിനൊപ്പം മരിക്കുന്നു, അടുത്ത നീക്കം സാങ്കേതികമല്ല, നയപരമായ ചോദ്യമാണ്: പരാജയപ്പെടുക, വീണ്ടും ശ്രമിക്കുക, അല്ലെങ്കിൽ ഭൗതിക ലിങ്കിലൂടെ നേരിട്ട് വീണ്ടും കണക്ട് ചെയ്യുക. മൂന്നാമത്തെ ഫലമാണ് ചിന്തിക്കാൻ യോഗ്യമായത്. ഉപയോക്താവ് കവറേജ് ഇപ്പോഴും കേടുകൂടാത്തതാണെന്ന് വിശ്വസിക്കുന്ന നിമിഷത്തിൽ അത് രണ്ട് ഹോപ്പ് രൂപകൽപ്പനയെ ഒരു ഹോപ്പ് രൂപകൽപ്പനയാക്കി നിശബ്ദമായി മാറ്റുന്നു.
രണ്ട് ഹോപ്പ് നിർബന്ധമാണെങ്കിൽ, പുറത്തുള്ളത് പോയാൽ അകം ക്ലയന്റിന് നേരിട്ടുള്ള പാത സ്ഥാപിക്കാൻ കഴിയരുത്, അത് അറിയാനുള്ള വഴി പുറം ഹോപ്പ് തകർത്ത് അകത്തുള്ളത് എന്ത് ചെയ്യുന്നു എന്ന് നിരീക്ഷിക്കുകയാണ്. അംഗീകരിച്ച ബാക്കപ്പ് സാധുവായ ഉത്തരമാണ്, പക്ഷേ അത് എഴുതുകയും പരീക്ഷിക്കുകയും അറിയിക്കുകയും വേണം. ആരും രേഖപ്പെടുത്താത്ത ബാക്കപ്പ് സംഭവ പരിശോധനയിൽ ചോർച്ചയിൽ നിന്ന് വേർതിരിച്ചറിയാനാവില്ല.
DNS-ഉം മറ്റേ വിലാസ കുടുംബവും ഒരേ തീരുമാനത്തിൽ പെടുന്നു. പ്രാദേശികമായി സൃഷ്ടിച്ച അന്വേഷണം ഫോർവേഡ് ചെയ്ത ക്ലയന്റിന്റേതല്ല, ഹോസ്റ്റിന്റെ സ്വന്തം നയം പിന്തുടരുന്നു, അതിനാൽ ഫോർവേഡ് ചെയ്ത ഗതാഗതത്തിന് പ്രവർത്തിക്കുന്ന റെസോൾവർ ഹോസ്റ്റ് തന്നെ ഉപയോഗിക്കുന്നതായിരിക്കണമെന്നില്ല.
ഓരോ പാളിയും നിങ്ങൾ നിർമ്മിച്ച ക്രമത്തിൽ സ്വീകരിക്കുക
ശൃംഖല നിർമ്മിച്ച ക്രമത്തിൽ പരീക്ഷിക്കുക: ആദ്യം പുറം ടണൽ മാത്രം, പിന്നെ പുറം ടണലിലൂടെ അകം ക്ലയന്റിന്റെ ഗതാഗതം, പിന്നെ അകം ടണലിലൂടെ ആപ്ലിക്കേഷൻ. ഓരോ സ്വീകരണവും മുമ്പേ തുറന്നിരുന്ന പേജല്ല, പുതിയ കണക്ഷനായിരിക്കണം. പിന്നെ ഓരോ പാളിയും വെവ്വേറെ തകർത്ത് പുനഃസ്ഥാപിച്ച് അടുത്തത് എന്ത് ചെയ്യുന്നു എന്ന് നിരീക്ഷിക്കുക.
ബാക്കപ്പിന്റെ ഫലം ഇവിടെ ഏറ്റവും വിലപ്പെട്ട നിരീക്ഷണമാണ്, പൊതു IP പേജ് ഒരിക്കലും കാണിക്കാത്തത്. പിയറുകളുടെ പാതകൾ, അവ ഉപയോഗിക്കുന്ന വിലാസങ്ങൾ, ആ ഫലം എന്നിവ കോൺഫിഗറേഷനൊപ്പം സൂക്ഷിക്കുക, കാരണം സുഖകരമായ പാത പിന്നീട് ചോദ്യം ചെയ്യപ്പെടുന്ന ഭാഗമല്ല.