VPN વપરાશકર્તાઓને એક સેવાની ઍક્સેસ આપો, સબનેટની નહીં

એક કોન્ટ્રાક્ટરને એક આંતરિક વેબ ઍપ્લિકેશનની જરૂર છે અને બીજું કંઈ નહીં, અને સહેલો જવાબ એ છે કે તેને સર્વર સબનેટમાં એક ટનલ આપવી. તે ત્યાં સુધી કામ કરે છે જ્યાં સુધી તે સ્કેન ન કરે. સાંકડી ડિઝાઇનને વધુ વિચાર જોઈએ છે, કારણ કે પહોંચ, રૂટિંગ અને ઍપ્લિકેશન પરવાનગી એ ત્રણ અલગ નિયંત્રણો છે જેમને સંમત થવું પડે.

જરૂરિયાત સબનેટ તરીકે નહીં, સેવા તરીકે લખો

ગંતવ્ય હોસ્ટ, પ્રોટોકોલ અને પોર્ટથી શરૂ કરો, પછી તે વપરાશકર્તા કે ઉપકરણ જૂથ ઉમેરો જેને ત્યાં પહોંચવું જોઈએ. ખાનગી DNS ઝોન ફક્ત ત્યારે સામેલ કરો જ્યારે ઍપ્લિકેશન નામ ઉકેલે, અને ઓળખ પ્રદાતા ફક્ત ત્યારે સામેલ કરો જ્યારે સાઇન-ઇન પ્રવાહને તેની જરૂર હોય. બાકીનું બધું એ નિર્ભરતા છે જેને તમે હજી ન્યાયી ઠેરવી નથી.

સબનેટ નેટવર્ક ટીમની અમલ વિગત છે, જ્યારે સેવા એ છે જે વ્યવસાયે માંગ્યું અને એ એકમ જેની સમીક્ષા કરીને નિવૃત્ત કરી શકાય.

જો નિર્ભરતા યાદી ત્રણ વસ્તુઓથી આગળ વધે, તો ઍપ્લિકેશનને સંભવતઃ પોતાની ડિઝાઇન ચર્ચા જોઈએ.

સાંકડું રૂટ કરો, પણ અમલ બીજે કરો

સાંકડો રૂટ કે સિલેક્ટર ટનલને કહે છે કે કયા પેકેટ લઈ જવા; તે અધિકૃતિ નીતિ નથી. ગેટવે ફિલ્ટર, ગંતવ્ય હોસ્ટનો ફાયરવોલ અને ઍપ્લિકેશનનું પોતાનું પરવાનગી મોડેલ એ જગ્યાઓ છે જ્યાં ઍક્સેસ નક્કી થાય છે. એક સરનામું આવરી લેતો રૂટ સારી શરૂઆત છે, અને તે એ નિયંત્રણ નથી જે નિશ્ચયી વપરાશકર્તાને રોકે. એ જ અલગતા તમને ટનલ ફરી ડિઝાઇન કર્યા વિના ફિલ્ટર બદલવા દે છે.

ઊલટું, કડક ફિલ્ટર સાથેનો પહોળો રૂટ કાયદેસર હોઈ શકે, પણ ફક્ત જો સંબંધિત દરેક જાણે કે બેમાંથી કોણ અમલ કરે છે.

અમલ બિંદુ સ્પષ્ટ રીતે દસ્તાવેજ કરો, નહીંતર આગલો ફેરફાર તેને અકસ્માતે ખસેડશે.

સેવા ખરેખર કયો સ્રોત જુએ છે તે ચકાસો

લક્ષ્ય ક્યાં તો ક્લાઇન્ટના પૂલ સરનામું જુએ છે અથવા ગેટવેનું સરનામું, તમે અનુવાદ કરો છો કે નહીં તેના આધારે. હોસ્ટ ફાયરવોલ નિયમો અને લોગ વાસ્તવિક સ્રોત સાથે મેળ ખાવા જોઈએ. જો ઘણા વપરાશકર્તાઓ અનુવાદિત સ્રોત વહેંચે, તો તે હોસ્ટ પર કોઈ પણ પ્રતિ-વપરાશકર્તા નિયમ તેમને અલગ કરી શકતો નથી, અને તે ડિઝાઇન મર્યાદા છે, ભૂલ નહીં.

અનુવાદ જાણી જોઈને પસંદ કરો: તે રૂટિંગ સરળ બનાવે છે અને સ્રોતની ઓળખનો નાશ કરે છે, જે ઓડિટ અને પ્રતિ-વપરાશકર્તા નિયમો માટે મહત્વપૂર્ણ છે.

બેમાંથી કયું પસંદ કર્યું તે તેના પર આધારિત નિયમની બાજુમાં લખો.

ઍપ્લિકેશન અધિકૃતિ વૈકલ્પિક નથી

પોર્ટ સુધી પહોંચવાથી ભૂમિકા મળતી નથી. ઍપ્લિકેશનને હજી પોતાનું લોગિન અને પોતાની પરવાનગીઓ જોઈએ, કારણ કે નેટવર્ક સ્તર એ વ્યક્ત કરી શકતું નથી કે વપરાશકર્તા કયા રેકોર્ડ સંપાદિત કરી શકે. આંતરિક સબનેટની કોઈ પણ વિનંતી પર ભરોસો કરતી સેવા સાંકડી ટનલને એક સમાધાનિક ઓળખપત્ર માટે સંપૂર્ણ ઍક્સેસમાં ફેરવે છે. ટનલ નક્કી કરે છે કે કોણ સોકેટ ખોલી શકે, અને ઍપ્લિકેશન નક્કી કરે છે કે તેની સાથે શું કરી શકાય.

અહીં સાંકડી ડિઝાઇન બે વાર ફળે છે, કારણ કે ઓછા પહોંચી શકાય તેવા હોસ્ટ એટલે ઓછી જગ્યાઓ જ્યાં ઍપ્લિકેશન સ્તરની ભૂલનો દુરુપયોગ થઈ શકે.

નેટવર્ક નિયમ અને ઍપ્લિકેશન ભૂમિકા અલગ સિસ્ટમોમાં રાખો, અને તેમને અલગ રીતે નિવૃત્ત કરો.

મંજૂર અને નકારેલ બંને માર્ગ સાબિત કરો

અધિકૃત વપરાશકર્તા તરીકે જોડાઓ અને એક નિરુપદ્રવ પ્રતિનિધિ ક્રિયા કરો, પછી એ ગંતવ્ય અજમાવો જે પહોંચની બહાર હોવું જોઈએ. જે ડિઝાઇન ફક્ત પહેલો અડધો ભાગ ચકાસે છે તે ચકાસાયેલી નથી, અને નકારની કસોટી જ ડિઝાઇન સાબિત કરે છે. દરેક નિયમ ફેરફાર પછી નવું સત્ર ચકાસો, અને જો વિનંતીઓ આવે પણ જવાબો ન આવે તો પરત માર્ગ જુઓ.

સ્વીકૃતિ કસોટી પાસ કરવા ફોરવર્ડિંગ ફિલ્ટર નિષ્ક્રિય કરશો નહીં, કારણ કે તે ચકાસાતી વસ્તુને બદલી નાખે છે.

જ્યારે વપરાશકર્તાને સેવાની જરૂર ન રહે, ત્યારે દૂરસ્થ ઓળખ અને ઍપ્લિકેશન ભૂમિકા તેમની સંબંધિત સિસ્ટમોમાં નિવૃત્ત કરો, અને બંને નોંધો. strongSwan ફોરવર્ડિંગ માર્ગદર્શિકા માર્ગની ગેટવે બાજુ આવરી લે છે.