മൾട്ടി-റൗട്ടർ Pi VPN: തീരുമാനിക്കുന്ന ഉപകരണത്തിൽ ഓരോ റൂട്ടും വയ്ക്കുക
താഴെയുള്ള റൗട്ടർ രണ്ടാമതൊരു ക്ലയന്റ് സബ്നെറ്റ് ചേർക്കുന്നു, നാല് ഉപകരണങ്ങളിൽ ഓരോന്നിനും ഓരോ തീരുമാനമുണ്ട്. റൂട്ടുകൾ വയ്ക്കുക, ഉറവിടം പരിശോധിക്കുക, പിന്നെ യഥാർത്ഥ ക്ലയന്റിൽ നിന്ന് പരീക്ഷിക്കുക.
Piയുടെ പിന്നിൽ ഒരു Wi-Fi ബോക്സ് വയ്ക്കുന്നത് ഒരു റൗട്ടിംഗ് തീരുമാനത്തെ നാലാക്കി മാറ്റുന്നു, നാലും ഒരേ ഉപകരണത്തിൽ എടുക്കുമ്പോൾ പ്ലാൻ തകരുന്നു. ആദ്യ ചോദ്യം ഏത് റൂട്ട് ചേർക്കണം എന്നതല്ല. പുതിയ ബോക്സ് ബ്രിഡ്ജ് ചെയ്യുന്നുണ്ടോ റൗട്ട് ചെയ്യുന്നുണ്ടോ എന്നതാണ്, കാരണം ആ ഉത്തരം എത്ര സബ്നെറ്റുകളുണ്ട്, ഏത് ഉപകരണങ്ങൾ അവയെക്കുറിച്ച് പഠിക്കണം എന്നത് നിർണ്ണയിക്കുന്നു. ആദ്യം അറ്റാച്ച്മെന്റ് മോഡൽ തിരഞ്ഞെടുക്കുക; ഓരോ റൂട്ടും അതിൽ നിന്ന് വരുന്നു.
ബ്രിഡ്ജോ റൗട്ടോ: എണ്ണം നിർണ്ണയിക്കുന്ന തിരഞ്ഞെടുപ്പ്
ബ്രിഡ്ജ് പുതിയ ക്ലയന്റുകളെ Pi ഇതിനകം സേവിക്കുന്ന അതേ സബ്നെറ്റിൽ വയ്ക്കുന്നു. ഒരു സബ്നെറ്റ്, ഒരു DHCP അധികാരം, റൗട്ട് ചെയ്യാൻ ഒരു കൈമാറ്റവുമില്ല. ഇത് ലളിതമായ ക്രമീകരണവും പ്രത്യേക ക്ലയന്റ് നെറ്റ്വർക്ക് ഒരിക്കലും ആവശ്യകതയല്ലാതിരുന്നപ്പോൾ ശരിയായതുമാണ്. റൗട്ട് ചെയ്ത ലിങ്ക് വേറെ രൂപകൽപ്പനയാണ്: ബോക്സ് സ്വന്തം സബ്നെറ്റ് നിലനിർത്തുന്നു, ആ പ്രിഫിക്സ് ട്രാഫിക് പോകുന്ന എല്ലായിടത്തും കൊണ്ടുപോകണം.
ഈ പ്ലാനിന്റെ ബാക്കി താഴെയുള്ള റൗട്ടർ നിലനിർത്തുകയും ക്ലയന്റ് ഉറവിട വിലാസങ്ങൾ സംരക്ഷിക്കുകയും ചെയ്യുന്നു. ലക്ഷ്യം ഒരു സ്വകാര്യ VPN നെറ്റ്വർക്കാണ്, പൂർണ്ണ ഇന്റർനെറ്റ് എക്സിറ്റല്ല. വിലാസങ്ങൾക്ക് മുമ്പ് മോഡൽ എഴുതിവയ്ക്കുക, കാരണം താഴെയുള്ള പട്ടിക റൗട്ട് ചെയ്ത അറ്റാച്ച്മെന്റിന്റെ ഒരു ഉദാഹരണം മാത്രമാണ്.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24ആർ എന്ത് തീരുമാനിക്കുന്നു
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
ഓരോ ഉപകരണവും ഒരു തീരുമാനം എടുക്കുന്നു, മറ്റൊന്നിന്റെ തീരുമാനം അതിനുവേണ്ടി എടുക്കാൻ ആർക്കും കഴിയില്ല. Piക്ക് ഒന്നല്ല, രണ്ട് എൻട്രികൾ വേണം, തിരിച്ചുവരവ് പാതയാണ് ആളുകൾ മറക്കുന്നത്. ഫോർവേഡ് ചെയ്ത ട്രാഫിക് സ്വകാര്യ നെറ്റ്വർക്കിൽ ശരിയായി എത്തി പിന്നെ തിരിച്ചുവരവ് വഴിയിൽ മരിക്കുന്നു, കാരണം 10.41.0.0/24 എവിടെ താമസിക്കുന്നു എന്ന് Piക്ക് അറിയില്ല. അത് ഫയർവാൾ പ്രശ്നം പോലെ തോന്നുമെങ്കിലും യഥാർത്ഥത്തിൽ കാണാതായ ഒരു റൂട്ടാണ്.
അകലെയുള്ള ഭാഗത്തിനും സ്വന്തം റൂട്ട് വേണം. അകലെയുള്ള അറ്റത്തുള്ള സേവനത്തിന് 10.41.0.0/24 നിങ്ങളുടെ ടണലിലൂടെ എത്താമെന്ന് അറിയില്ലെങ്കിൽ, മറുപടികൾ ഉത്തരമില്ലാത്ത ആദ്യ ഹോപ്പിൽ നിൽക്കുന്നു. പാക്കറ്റ് ഫിൽട്ടറുകൾ വായിക്കുന്നതിന് മുമ്പ് രണ്ട് ദിശകളും ചേർക്കുക.
അടുത്ത ഹോപ്പുകൾ അറ്റാച്ച്മെന്റിൽ നിന്ന് വരുന്നു
അടുത്ത ഹോപ്പ് ഉപകരണത്തിന് യഥാർത്ഥത്തിൽ എത്താൻ കഴിയുന്ന നെറ്റ്വർക്കിലെ വിലാസമായിരിക്കണം. VPN പിയറിന്റെ പൊതു വിലാസം സ്വകാര്യ സബ്നെറ്റിനുള്ള അടുത്ത ഹോപ്പല്ല, അകലെയുള്ള സേവന നെറ്റ്വർക്ക് ഒരിക്കലും അടുത്ത ഹോപ്പല്ല. എത്തിച്ചേരാനാകാത്ത ഗേറ്റ്വേയിലേക്കുള്ള റൂട്ട് പട്ടികയിൽ ശരിയായി കാണപ്പെടുന്നു, എല്ലാ പാക്കറ്റും വീഴ്ത്തുന്നു. ലക്ഷ്യത്തെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ഗേറ്റ്വേ മറുപടി നൽകുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.
Piയുടെ പുറം VPN പിയറിനെ അതിന്റെ സ്വന്തം അൺഡർലേ റൂട്ടിലൂടെ എത്താവുന്നതാക്കി നിലനിർത്തുക. ആ എൻട്രി പേലോഡ് റൂട്ടുകളിൽ നിന്ന് വേറെയാണ്, അവ കൂട്ടിക്കലർത്തിയാൽ പാത മാറിയതിന് ശേഷം വീണ്ടും സ്ഥാപിക്കാനാകാത്ത ടണൽ ലഭിക്കും.
സ്റ്റാറ്റിക് റൂട്ടുകളുടെ ഡോക്യുമെന്റേഷൻ ഓരോ പ്ലാറ്റ്ഫോമും മെനുകൾക്ക് വ്യത്യസ്ത പേരിട്ടാലും ലക്ഷ്യവും ഗേറ്റ്വേയും തമ്മിലുള്ള വ്യത്യാസം വ്യക്തമാക്കുന്നു. മറ്റൊരു വിൽപ്പനക്കാരന്റെ സ്ക്രീൻ പകർത്തുന്നതിന് പകരം നിങ്ങൾക്ക് മുന്നിലുള്ള ഉപകരണത്തിന്റെ ഡോക്യുമെന്റേഷൻ വായിക്കുക. താഴെയുള്ള കമാൻഡുകൾ Linuxൽ എൻട്രികളുടെ രൂപം കാണിക്കുന്നു.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1വിവർത്തനം ഉറവിടത്തിനോട് എന്ത് ചെയ്യുന്നു
താഴെയുള്ള റൗട്ടർ ഇതിനകം ക്ലയന്റുകളെ ട്രാൻസിറ്റ് വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്യുന്നുണ്ടെങ്കിൽ, Pi ഓരോ ക്ലയന്റിന്റെയും സ്വന്തം വിലാസത്തിന് പകരം ഒരു വിവർത്തനം ചെയ്ത ഉറവിടം കാണുന്നു. ഇത് മുകളിലെ ഉറവിടം സംരക്ഷിക്കുന്ന രൂപകൽപ്പനയിൽ നിന്ന് വ്യത്യസ്തമാണ്. ഇത് ഉറവിടാധിഷ്ഠിത നയം, ലോഗിംഗ്, ഏത് വശത്തിന് കണക്ഷനുകൾ തുടങ്ങാമെന്നത് എന്നിവ മാറ്റുന്നു. രണ്ട് രൂപകൽപ്പനകളും പ്രവർത്തിക്കുന്നു; അവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു.
അപ്സ്ട്രീം VPN സേവനം ക്ലയന്റ് പ്രിഫിക്സ് തിരികെ റൗട്ട് ചെയ്യാൻ വിസമ്മതിക്കുമ്പോൾ, Piയുടെ ടണൽ എഗ്രെസ്സിൽ ഒരു ഇടുങ്ങിയ വിവർത്തനം നിയമാനുസൃതമായ താൽക്കാലിക പരിഹാരമാകാം. കാണാതായ റൂട്ട് അനാവശ്യമായിരുന്നു എന്നതിന് ഇത് തെളിവല്ല. അകലെയുള്ള നെറ്റ്വർക്ക് യഥാർത്ഥത്തിൽ ഏത് വിലാസം കാണുന്നു, ഏത് തിരിച്ചുവരവ് പാത ഉണ്ടാകുന്നു എന്ന് രേഖപ്പെടുത്തുക.
റൂട്ട് തിരഞ്ഞെടുപ്പ്, ഫോർവേഡിംഗ് അനുമതി, ഉറവിട വിവർത്തനം എന്നിവ മൂന്ന് വേറിട്ട ജോലികളായി തുടരുന്നു. ഒരു വയർഡ് ക്ലയന്റ് പ്രവർത്തിക്കുന്നതിനാൽ പങ്കിട്ട NAT ചെയിൻ ഫ്ലഷ് ചെയ്യുന്നതോ എല്ലാ ഇന്റർഫേസിനും അനുമതി നൽകുന്നതോ ആണ് പ്രവർത്തിക്കുന്ന പരീക്ഷണത്തെ തുറന്ന ഫോർവാർഡറാക്കുന്ന വഴി.
ഒരു ക്ലയന്റ് മെഷീനിൽ നിന്ന് അത് തെളിയിക്കുക
താഴെയുള്ള LANലെ ഒരു മെഷീനിൽ നിന്ന് അഭ്യർത്ഥന അയയ്ക്കുക, പിന്നെ അതിന്റെ ഉറവിടം പുറത്തേക്കും തിരികെയും പിന്തുടരുക. Pi അയയ്ക്കുന്ന ping ഒരിക്കലും താഴെയുള്ള തിരിച്ചുവരവ് റൂട്ട് ഉപയോഗിക്കുന്നില്ല, അതിനാൽ വിജയകരമായ ping കാണുന്നതിനേക്കാൾ കുറഞ്ഞത് തെളിയിക്കുന്നു. Piയുടെ സ്വന്തം LANലെ വയർഡ് ക്ലയന്റിൽ നിന്ന് രണ്ടാമതൊരു പരീക്ഷണം ചേർക്കുക, അപ്പോൾ രണ്ട് പാതകളും താരതമ്യം ചെയ്യാം. ഏതെങ്കിലും ഉപകരണം റീബൂട്ട് ചെയ്ത ശേഷം രണ്ടും ആവർത്തിക്കുക.
കൈകൊണ്ട് ചേർത്ത റൂട്ടുകളും ഒരിക്കലും സംരക്ഷിക്കാത്ത വിവർത്തനങ്ങളും ഒരുമിച്ച് അപ്രത്യക്ഷമാകുന്നു. അപ്പോൾ ആ ജോടി അപൂർണ്ണ ജോലിയല്ല, പുതിയ തകരാറായി തോന്നുന്നു.
അറ്റാച്ച്മെന്റ് മോഡൽ റൂട്ടുകൾ, അനുവദിച്ച സ്വകാര്യ സേവനം, ഏത് വിവർത്തനം എന്നിവയോടൊപ്പം ഒരു കുറിപ്പിൽ സംരക്ഷിക്കുക. ആ കുറിപ്പാണ് അടുത്തയാളെ വയർലെസ് സ്ഥാനം റൗട്ടിംഗ് നയത്തിന്റെ ചോദ്യമായി കാണുന്നതിൽ നിന്ന് തടയുന്നത്.