vpnc જૂથ રહસ્ય કે તમારું લોગિન: કયું ક્ષેત્ર શું લે છે?
vpnc પ્રોફાઇલ જૂથ ID, જૂથ રહસ્ય અને XAuth લોગિન માંગે છે, અને લોકો ખાતાનો પાસવર્ડ ખોટા બોક્સમાં નાખે છે. દરેક ક્ષેત્રને તેની ભૂમિકા મુજબ નકશા કરો.
પહેલી વાર કોઈ તમને vpnc પ્રોફાઇલ આપે ત્યારે ઓળખપત્ર સંવાદ ચાર વસ્તુઓ પૂછે છે અને એવું વાંચાય છે કે જાણે એક જ પાસવર્ડ જોઈએ. એવું નથી: જૂથનું પૂર્વ-શેર કરેલું રહસ્ય અને વ્યક્તિગત XAuth લોગિન અલગ માલિકો સાથેનાં અલગ મૂલ્યો છે, અને ખાતાનો પાસવર્ડ જૂથ ક્ષેત્રમાં નાખવાથી એવી નિષ્ફળતા આવે છે જે ખોટા બોક્સ જેવી નહીં પણ ખોટા પાસવર્ડ જેવી લાગે. આ નકશો સાચો બનાવવો એ જ આખું કામ છે. નીચેનો પ્રોટોકોલ બીજા કોઈનો સ્થળાંતર પ્રોજેક્ટ છે, એટલે આમાંથી કંઈ પણ નવી IKEv1 સુરંગો બનાવવાનો દલીલ નથી.
બે રહસ્યો, બે માલિકો, એક સંવાદ
જૂથ રહસ્ય ગેટવે પ્રોફાઇલનું છે. જે દરેક વ્યક્તિ એ પ્રોફાઇલ દ્વારા જોડાય છે તે સમાન મૂલ્ય વાપરે છે, અને એટલે જ તે વ્યક્તિને ઓળખી શકતું નથી અને પ્રોફાઇલના અન્ય તમામ વપરાશકર્તાઓ માટે બદલ્યા વિના એક લેપટોપ પરથી પાછું ખેંચી શકાતું નથી. XAuth વપરાશકર્તાનામ અને પાસવર્ડ તેના બદલે માણસના છે, અને ગેટવે IPsec જોડાણ પહેલેથી ઊભું હોય તે પછી બીજા તબક્કામાં તેમનું મૂલ્યાંકન કરે છે.
લોકો આ બે-તબક્કાનું સ્વરૂપ ચૂકી જાય છે. સુરંગ સ્થાપવી અને વપરાશકર્તા પ્રમાણીકરણ એ અલગ ઇનપુટ સાથેની અલગ આપલે છે, તેથી જે ક્લાયન્ટ કદી ઓળખપત્ર સૂચના સુધી પહોંચતું નથી તેણે લોગિનમાં જરાય નિષ્ફળતા પામી નથી. સંવાદને એક નહીં પણ બે કોલમ તરીકે વાંચો: ડાબે પ્રોફાઇલ-વ્યાપી મૂલ્યો, જમણે વ્યક્તિગત મૂલ્યો. જ્યારે કનેક્શન નિષ્ફળ જાય, ત્યારે તમે છેલ્લે ભરેલી કોલમ આપોઆપ દોષિત કોલમ હોતી નથી.
ક્ષેત્રોને ભૂમિકા મુજબ નકશા કરો, લેબલ મુજબ નહીં
vpnc પોતાના નિર્દેશોને પ્રોજેક્ટ દસ્તાવેજીકરણમાં નામ આપે છે, અને દરેક ગ્રાફિકલ ફ્રન્ટએન્ડ તેમને ફરી લેબલ કરે છે. દરેક મૂલ્યની ભૂમિકા અનુવાદ કરો, પછી લેબલોનું મહત્વ રહેતું નથી:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
જૂથ ક્ષેત્રની બાજુમાં «વપરાશકર્તાનામ» અને «પાસવર્ડ» બતાવતું ફ્રન્ટએન્ડ ખોટું નથી — એ અલગ નામો હેઠળનાં એ જ ત્રણ મૂલ્યો છે. જે તૂટે છે તે એ છે કે મૂલ્ય બોક્સમાં બંધ બેસે એટલે બોક્સ ભરવું. વપરાશકર્તા પાસવર્ડ તરીકે પેસ્ટ કરેલું જૂથ રહસ્ય પ્રોફાઇલને પ્રમાણિત કરે છે અને પછી વપરાશકર્તા તબક્કે નિષ્ફળ જાય છે; જૂથ રહસ્ય તરીકે પેસ્ટ કરેલો ખાતાનો પાસવર્ડ વહેલા, કોઈપણ સૂચના પહેલાં નિષ્ફળ જાય છે અને લોકોને ફાયરવોલમાં એવી સમસ્યા શોધવા મોકલે છે જે ટેક્સ્ટ ક્ષેત્રમાં રહે છે.
જૂથ ઓળખકર્તા શું નથી
જૂથ શબ્દ ખોટા વાંચનનું નિમંત્રણ આપે છે. અહીં જૂથ ઓળખકર્તા એ પસંદગીકર્તા છે જે ગેટવેને કહે છે કે કઈ પ્રોફાઇલ રૂપરેખા લાગુ કરવી; તે ડિરેક્ટરી સભ્યપદ વિશે કંઈ કહેતું નથી, અને બંને બાજુનું મેળ ખાતું નામ ઓપરેટર તેની પુષ્ટિ કરે ત્યાં સુધી સંજોગ છે. અધિકૃતિ XAuth સફળ થયા પછી થાય છે, ગેટવે જેની સલાહ લેવા રૂપરેખાંકિત છે તે નક્કી કરે છે, અને એમાંથી કંઈ પણ ક્લાયન્ટ સંવાદમાં દેખાતું નથી.
એ જ સાવધાની જૂથ રહસ્યને પણ લાગુ પડે છે. તેને જાણવું ઓળખ નથી, અને એક રહસ્યને ટીમમાં ફેરવવું એવા પરિણામો સાથેનો કાર્યાત્મક નિર્ણય છે જે ક્લાયન્ટ તમને બતાવી શકતું નથી.
જોડાતા પહેલાં અસ્પષ્ટ સૂચના ઉકેલો
જૂની હસ્તાંતરણ નોંધોમાં ઘણી વાર «સમર્પિત જાહેર IP વાપરો» જેવી લીટી હોય છે. એ વાક્ય એ સરનામું હોઈ શકે જ્યાંથી સામેની બાજુની મંજૂરી-યાદી તમારા ટ્રાફિકને આવવાની અપેક્ષા રાખે છે, આ ઓપરેટર નેટવર્કની બહિર્ગમન લાક્ષણિકતા છે અને ગેટવે ક્ષેત્રમાં તમે લખો છો તે અંતિમ બિંદુ સાથે તેને કોઈ સંબંધ નથી. મૂલ્ય ક્યાંય જાય તે પહેલાં પૂછો કે બેમાંથી કયું અભિપ્રેત છે. ઊંધું ભરવાથી તે દરેક પેકેટને એવા સરનામે મોકલે છે જે કદી જવાબ આપતું નથી, અને પરિણામી સમયસીમા અવરોધિત પોર્ટ જેવી વંચાય છે.
સંસ્થાની ચકાસાયેલી ચેનલ દ્વારા ચાર વસ્તુઓ માંગો: કયો ક્લાયન્ટ અને પ્રોટોકોલ સમર્થિત છે, કયું અંતિમ બિંદુ વાપરવું, ગેટવે કઈ ઓળખ રજૂ કરશે, અને ઓળખપત્રો કેવી રીતે સોંપાય છે. સાચાં રહસ્યોને સ્ક્રીનશોટ, ટિકિટ અને વહેંચાયેલી મુશ્કેલીનિવારણ નોંધોથી બહાર રાખો. પ્રમાણપત્ર તપાસ નિષ્ક્રિય કરો નહીં અને જૂની સાઇફર યાદી પેસ્ટ કરો નહીં જેથી અલગ રીતે રૂપરેખાંકિત સેવા સુસંગત દેખાય, કારણ કે ફક્ત ચકાસણી નબળી કરીને ચાલતું કનેક્શન એ કનેક્શન નથી જે તમને બનાવવા કહ્યું હતું.
જૂની પ્રોફાઇલને પ્રામાણિક રાખો
IKEv1 અપ્રચલિત છે, અને RFC 9395 એ દસ્તાવેજ છે જેનો ઉલ્લેખ સ્થળાંતરનો પ્રશ્ન આવે ત્યારે કરવો જોઈએ. સફળ ક્ષેત્ર-નકશો એ પુરાવો નથી કે પ્રોટોકોલ નવી રચનામાં આવે છે; તે જે ખરીદે છે તે છે બદલી નિયોજિત થાય ત્યાં સુધી કામ કરતું કનેક્શન, ઉપરાંત લેખિત વ્યાપ અને તે સ્થળાંતર માટેનો માલિક.
પછી સંવાદ સામે નહીં, આવશ્યકતા સામે ચકાસો. જોડાયા પછી ખાતરી કરો કે સુરંગ ઇન્ટરફેસ પાસે અપેક્ષિત સરનામું છે અને આંતરિક ગંતવ્ય તેમાંથી માર્ગ પામે છે; જો મૂળ આવશ્યકતામાં મંજૂરી-યાદી માટે બહિર્ગમન સરનામું કહ્યું હતું, તો એ સરનામું પણ ખાતરી કરો, કારણ કે તે સુરંગ ઊભી હોવાથી અલગ હકીકત છે. જે પ્રોફાઇલ યોગ્ય રીતે પ્રમાણિત થાય છે અને કંઈ પણ માર્ગ આપતું નથી તેણે જે કાર્ય માટે બનાવાયું તે હજી પણ ચૂક્યું છે.