MSCHAPv2 એ VPN પ્રોટોકોલ નથી: પહેલાં ટનલ વિશે પૂછો

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

પ્રમાણીકરણ ટનલની અંદર ચાલે છે

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

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

એ જ પદ્ધતિ જ્યાં દેખાય છે તેવી ત્રણ જગ્યાઓ

PPP માં પ્રમાણીકરણનું પગલું લિંક અસ્તિત્વમાં આવે ત્યાં સુધી રાહ જુએ છે, અને RFC 2759 MS-CHAPv2 ને તે પગલું તરીકે વ્યાખ્યાયિત કરે છે, તેથી જ આ પદ્ધતિ L2TP અને જૂની PPTP સ્થાપનોમાં દેખાય છે. ટનલ પહેલાં સમાપ્ત થાય છે અને PPP વાટાઘાટ તેની અંદર થાય છે, તેથી નિષ્ફળ PPP તબક્કો સર્વર લોગમાં ટનલને સ્થપાયેલી જેવી છોડી શકે છે. ઓળખપત્રો નકારાયા હોવાનું નિષ્કર્ષ કાઢતા પહેલાં તે બે તબક્કા અલગ વાંચો. તેથી L2TP માટે ગોઠવાયેલો ક્લાયન્ટ સંપૂર્ણ સાચો હોઈ શકે અને તેમ છતાં ફક્ત IKEv2 બોલતા ગેટવે માટે ખોટો ક્લાયન્ટ હોઈ શકે.

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

TLS આધારિત VPN ત્રીજી ગોઠવણ ઉમેરે છે, તેના પોતાના વપરાશકર્તાનામ અને પાસવર્ડ ક્ષેત્રો સાથે અને વિનિમયમાં ક્યાંય પણ MS-CHAPv2 વગર. તેથી પાસવર્ડ બોક્સ જોવું તેની પાછળના પ્રોટોકોલનો કોઈ પુરાવો નથી, કારણ કે ફોર્મ પરિચિત દેખાવા માટે બનાવાયું છે. પ્રોટોકોલની પુષ્ટિ ક્લાયન્ટ વિન્ડોના આકારથી નહીં, સર્વરના દસ્તાવેજીકરણથી કરો.

તમને ખરેખર જે જવાબોની જરૂર છે

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

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

ગેટવે ચકાસણી ઢીલી ન કરો

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

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

પ્રોફાઇલ મેળવો, પછી દરેક તબક્કો સાબિત કરો

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

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