VPN-ന് പിന്നിൽ IoT സെൻസറുകൾ വയ്ക്കുന്നതിന് മുമ്പ് മൂന്ന് വിലാസ തീരുമാനങ്ങൾ
മൂന്ന് വിലാസങ്ങൾ മൂന്ന് ജോലികൾ ചെയ്യുന്നു: പൊതു ഹബ്, സാക്ഷ്യപ്പെടുത്തിയ സൈറ്റ് പിയർ, സെൻസറിന്റെ സ്വകാര്യ വിലാസം. എന്തെങ്കിലും പൊതുവായി അനുവദിക്കുന്നതിന് മുമ്പ് ഓരോന്നും ആസൂത്രണം ചെയ്യുക.
ഓരോ IoT-VPN പദ്ധതിയിലും മൂന്ന് വിലാസങ്ങൾ കുരുങ്ങുന്നു, അവ ഒരേ തരത്തിലുള്ള തീരുമാനമല്ല. ഒന്ന്, വിദൂര ഓപ്പറേറ്റർ ടണലിന്റെ അവസാന പോയിന്റ് എങ്ങനെ കണ്ടെത്തുന്നു എന്നതാണ്; മറ്റൊന്ന്, സൈറ്റ് താൻ തന്നെ സൈറ്റാണെന്ന് എങ്ങനെ തെളിയിക്കുന്നു എന്നതാണ്; മൂന്നാമത്തേത്, സെൻസറിന്റെ സേവനം യഥാർത്ഥത്തിൽ എവിടെ കേൾക്കുന്നു എന്നതാണ്. അതേ ക്രമത്തിൽ ഉത്തരം നൽകുക, രൂപകൽപ്പന മിക്കവാറും സ്വയം വരും. ഒരൊറ്റ ചോദ്യമായി ഉത്തരം നൽകിയാൽ, ഒരിക്കലും ആവശ്യമില്ലാത്ത ഉപകരണങ്ങൾക്ക് പൊതു വിലാസങ്ങൾ അനുവദിക്കുന്ന അവസ്ഥയിൽ എത്തും. പുറത്തേക്കുള്ള സൈറ്റ് ടണലിന് പിന്നിലുള്ള സെൻസർ, സെൻസറിലേക്ക് ചൂണ്ടുന്ന ഒരു ഇൻബൗണ്ട് നിയമവുമില്ലാതെ അധികാരമുള്ള ഓപ്പറേറ്ററിന് എത്താവുന്നതാണ്.
ആരാണ് തുടങ്ങുന്നത് എന്നതിൽ നിന്ന് തുടങ്ങുക
ആരാണ് ഡയൽ ചെയ്യുന്നത് എന്നത് തുടർന്നുള്ള മിക്കതും തീരുമാനിക്കുന്നു. സൈറ്റ് ഹബ്ബിലേക്ക് ഡയൽ ചെയ്യുമ്പോൾ, സൈറ്റിന് ഇൻബൗണ്ട് എത്തിച്ചേരൽ ആവശ്യമില്ല, ഹബ്ബിന് സൈറ്റിന് പരിഹരിക്കാവുന്ന ഒരു പേരോ വിലാസമോ വേണം. ആ ഒരു തിരഞ്ഞെടുപ്പ് സ്ഥിര പൊതു വിലാസനിർണ്ണയത്തിന്റെ ചർച്ചയുടെ ഭൂരിഭാഗവും അത് തുടങ്ങുന്നതിന് മുമ്പ് തന്നെ ഒഴിവാക്കുന്നു.
പിന്നീട് മൂന്ന് പങ്കുകളും വ്യക്തമായി വേർപിരിയുന്നു, താഴെയുള്ള പട്ടിക തീരുമാനത്തിന്റെ ഏറ്റവും ചെറിയ രൂപമാണ്.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
ഓരോ വരിക്കും വ്യത്യസ്ത ഉടമയുണ്ട്, അതാണ് യഥാർത്ഥ കാര്യം. ഹബ് VPN സേവനം നടത്തുന്നവരുടേതാണ്, സൈറ്റ് പിയർ നെറ്റ്വർക്ക് ടീമിന്റേതാണ്, സെൻസറിന്റെ വിലാസം ഉപകരണം സ്വന്തമായുള്ളവരുടേതാണ്.
ഹബ് വിലാസം ബൂട്ട്സ്ട്രാപ്പാണ്, ലക്ഷ്യസ്ഥാനമല്ല
പരിപാലിക്കുന്ന പൊതു വിലാസത്തിലേക്ക് പരിഹരിക്കുന്ന ഒരു പേര് ഹബ്ബിന് മതി. ടണലിന്റെ അവസാന പോയിന്റ് നീങ്ങുമ്പോൾ DNS റെക്കോർഡിന് അതിനെ പിന്തുടരാം, ഓരോ സൈറ്റ് കോൺഫിഗറേഷനും കൈകൊണ്ട് തിരുത്താതെ. DNS ചെയ്യാത്തത് എത്തിച്ചേരൽ സൃഷ്ടിക്കുകയോ പഴയ ഉത്തരം കാഷ് ചെയ്യുന്ന ക്ലയന്റ് പുതുക്കുകയോ ചെയ്യുന്നതാണ്, അവ വ്യത്യസ്ത പ്രശ്നങ്ങളാണ് വ്യത്യസ്ത പരിഹാരങ്ങളോടെ.
ഹബ്ബില്ലാതെ സൈറ്റ്-ടു-സൈറ്റ് ടണലുകൾ നടത്തുന്നുവെങ്കിൽ, അതേ യുക്തി മറ്റൊരു രൂപത്തിൽ ബാധകമാണ്: ഒരു വശത്തിന് എത്താവുന്ന അവസാന പോയിന്റ് വേണം, അല്ലെങ്കിൽ ഇരുവശങ്ങളും മൂന്നാം കക്ഷിയെ ഡയൽ ചെയ്യുന്നു. ആ വിലാസവും അതിന്റെ പുതുക്കലുകളും ആരെങ്കിലും ഇപ്പോഴും സ്വന്തമായിരിക്കണം.
സൈറ്റ് പിയർ ഒരു പ്രിഫിക്സ് ചേർത്ത വ്യക്തിത്വമാണ്
പിയർ ആദ്യം വ്യക്തിത്വവും പിന്നീട് പ്രിഫിക്സുമാണ്. WireGuard പദങ്ങളിൽ പിയർ ഒരു കീ ജോഡി സൂക്ഷിക്കുന്നു, ഹബ്ബിന്റെ AllowedIPs എൻട്രി ആ കീയെ സൈറ്റിന്റെ പ്രിഫിക്സിലേക്ക് ബന്ധിക്കുന്നു. IKEv2 പദങ്ങളിൽ ഒരു സർട്ടിഫിക്കറ്റോ മുൻകൂട്ടി പങ്കിട്ട കീയോ സൈറ്റിനെ തിരിച്ചറിയുന്നു, അതിന്റെ ട്രാഫിക് സെലക്ടർമാർ എന്ത് കൊണ്ടുപോകാമെന്ന് പറയുന്നു. ഒരു പകുതി മാത്രം മാറ്റുന്നത് ക്രമീകരണം തകർക്കുന്നു, അതിനാൽ വിലാസ മാറ്റം ഒരിക്കലും വ്യക്തിത്വ മാറ്റമായി കണക്കാക്കരുത്.
കീയുടെയോ സർട്ടിഫിക്കറ്റിന്റെയോ ഉടമസ്ഥത ഹബ് ഓപ്പറേറ്ററിലല്ല, സൈറ്റിൽ സൂക്ഷിക്കുക, ദാതാവ് മാറ്റം വ്യക്തിത്വ മാറ്റമാകാതിരിക്കാൻ.
പ്രിഫിക്സ് ആളുകൾ ആസൂത്രണം ചെയ്യാൻ മറക്കുന്ന ഭാഗമാണ്. ഹബ് സെൻസറിന്റെ സബ്നെറ്റ് ശരിയായ പിയറുമായി ബന്ധിപ്പിക്കണം, ഓപ്പറേറ്ററുടെ ക്ലയന്റിന് അതിലേക്ക് ഒരു റൂട്ട് വേണം; ക്ലയന്റിൽ മാത്രം നിലനിൽക്കുന്ന റൂട്ട് ട്രാഫിക്കിനെ നിശ്ശബ്ദമായി ഉപേക്ഷിക്കുന്ന ടണലിലേക്ക് അയയ്ക്കുന്നു. കീ ഫിംഗർപ്രിന്റിന് അടുത്ത് സൈറ്റ് റെക്കോർഡിൽ പ്രിഫിക്സ് എഴുതുക, മാറ്റിസ്ഥാപിച്ച ഗേറ്റ്വേ ശ്രദ്ധിക്കപ്പെടാതെ വ്യത്യസ്ത കവറേജുമായി വരാതിരിക്കാൻ.
സെൻസറിന്റെ വിലാസം ആപ്ലിക്കേഷന്റേതാണ്
സൈറ്റിന്റെ പ്ലാനിൽ നിന്നുള്ള സ്വകാര്യ വിലാസം മതി, അതിന് വേണ്ടത് പൊതു എത്തിച്ചേരലല്ല, സ്ഥിരതയാണ്: DHCP റിസർവേഷൻ, സ്റ്റാറ്റിക് അനുവദനം, അല്ലെങ്കിൽ സൈറ്റിന്റെ സ്വന്തം സോണിലെ ഒരു പേര്. ഉപകരണം വീണ്ടും നമ്പർ ചെയ്യാൻ കഴിയില്ലെങ്കിൽ, സൈറ്റ് ഗേറ്റ്വേയിലെ വിവർത്തനം സാധുവായ ഉത്തരമാണ്, വിവർത്തനം രേഖപ്പെടുത്തിയതും തിരിച്ചുള്ള ട്രാഫിക് അതിനെ പിന്തുടരുന്നതുമായിരിക്കണം.
സൂക്ഷിക്കാൻ യോഗ്യമായ മറ്റൊരു ശീലം: സെൻസറിന്റെ ഹോസ്റ്റിലെ അടുത്ത-ഹോപ്പ് ഫീൽഡിൽ പൊതു ഹബ് വിലാസം ഒരിക്കലും ഒട്ടിക്കരുത്. VPN സ്വന്തം പാത ഇൻസ്റ്റാൾ ചെയ്യുന്നു, പൊതു അവസാന പോയിന്റിലേക്കുള്ള സാധാരണ ഈതർനെറ്റ് സാമീപ്യം വിശ്വസനീയമായി തോന്നുന്ന കോൺഫിഗറേഷൻ സൃഷ്ടിക്കുന്ന ഒരു കൽപ്പിതമാണ്.
ഉത്തരങ്ങളാണ് ഒഴിവാക്കപ്പെടുന്ന പകുതി. ഉപകരണം അതിന്റെ ഉത്തരം ടണലിലേക്ക് തിരികെ അയയ്ക്കണം, ഒന്നുകിൽ ഓപ്പറേറ്ററുടെ ക്ലയന്റിലേക്കുള്ള റൂട്ടിലൂടെ അല്ലെങ്കിൽ അഭ്യർത്ഥന വിവർത്തനം ചെയ്ത അതേ ഗേറ്റ്വേയിലൂടെ. തെറ്റായ ഡിഫോൾട്ട് ഗേറ്റ്വേയുള്ള സെൻസർ അഭ്യർത്ഥന സ്വീകരിച്ച് ഒന്നുമില്ലാത്തതിലേക്ക് ഉത്തരം നൽകുന്നു, ഫോർവേഡിംഗ് കുറിപ്പുകൾ എത്തിച്ചേരലും ഉത്തര റൂട്ടിംഗും ഒന്നല്ല രണ്ട് ആവശ്യകതകളാണെന്ന് വിശദീകരിക്കുന്നു.
തീരുമാനിക്കുക, പിന്നീട് അതിർത്തി എഴുതുക
ആരെങ്കിലും ബന്ധിപ്പിക്കുന്നതിന് മുമ്പ് പ്രവേശന അതിർത്തി എഴുതുക. ഗേറ്റ്വേയെ IoT സെഗ്മെന്റിലേക്കും ഓപ്പറേറ്റർക്ക് ആവശ്യമായ നിർദ്ദിഷ്ട സേവനങ്ങളിലേക്കും പരിമിതപ്പെടുത്തുക, പ്രവർത്തിക്കുന്ന റൂട്ട് അബദ്ധവശാൽ പൊതു പ്രവേശനമായി മാറാൻ സാധ്യതയുണ്ട്. വായന-മാത്രം നിരീക്ഷണവും കോൺഫിഗറേഷൻ അധികാരവും വ്യത്യസ്ത വ്യക്തിത്വങ്ങളുള്ള വേറിട്ട പങ്കുകളായി സൂക്ഷിക്കുക, കരാർ അവസാനിക്കുമ്പോൾ പ്രവേശനം നീക്കുന്ന വ്യക്തിയുടെ പേര് എഴുതുക.
അനുമതി നെറ്റ്വർക്ക് ഉടമയുടേതാണ്, DMZ-ൽ ആയിരിക്കുന്നത് പ്രവേശന നയമല്ല.
വിന്യാസത്തിന് ശേഷമുള്ള പരിശോധന വിരസവും നിർണ്ണായകവുമാണ്: അനുവദിച്ച പ്രിഫിക്സിനുള്ളിൽ ഒരു അഭ്യർത്ഥന വിജയിക്കുന്നു, ഗേറ്റ്വേയിൽ ഒരു കൗണ്ടർ കൂടുന്നു, പ്രിഫിക്സിന് പുറത്ത് ഒരു ബോധപൂർവ്വമായ ശ്രമം പരാജയപ്പെടുന്നു.