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માં હોવું એ પ્રવેશ નીતિ નથી.
જમાવટ પછીની કસોટી કંટાળાજનક અને નિર્ણાયક છે: મંજૂર પ્રીફિક્સની અંદર એક વિનંતી જે સફળ થાય, ગેટવે પર વધતો કાઉન્ટર, અને પ્રીફિક્સની બહાર એક જાણી જોઈને કરેલો પ્રયાસ જે નિષ્ફળ જાય.