SSTP પહેલાં સર્વર અને પછી વપરાશકર્તાને પ્રમાણિત કરે છે

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

વિશ્વસનીય પ્રમાણપત્ર અંતિમ બિંદુ સાબિત કરે છે; ખાતા વિશે તે કંઈ કહેતું નથી.

TLS હેન્ડશેક શું સ્થાપિત કરે છે

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

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

SSTP અને PPP ઉપર શું ઉમેરે છે

SSTP HTTPS પર ચાલે છે અને અંદર PPP વહન કરે છે, જોડાણની આસપાસ તેની પોતાની નિયંત્રણ આપલે સાથે. પછી PPP તેના લિંક અને પ્રમાણીકરણ તબક્કા ચલાવે છે, અને પ્રમાણીકરણ પદ્ધતિ સર્વર નીતિ અને ક્લાયન્ટ ક્ષમતા પર આધાર રાખે છે. PAP, CHAP, MS-CHAPv2 અને EAP એ બધા ખૂબ જુદા ગુણધર્મો ધરાવતા PPP પ્રમાણીકરણ વિકલ્પો છે. VPN ની વપરાશકર્તા તપાસ એ PPP તબક્કો છે, તેની નીચેનું TLS સ્તર નહીં.

તેથી વપરાશકર્તા નકાર માન્યતાઓ, ખાતા પ્રતિબંધ કે પદ્ધતિ બિનમેળ સૂચવી શકે છે.

સર્વર બાજુનું કારણ પ્રોફાઇલમાંના દરેક રહસ્યને ફરીથી સેટ કરવા કરતાં ઘણું વધુ ઉપયોગી છે. ખાતું નિષ્ક્રિય થવાની ઘટના અને પદ્ધતિ વાટાઘાટની નિષ્ફળતા ક્લાયન્ટ પર સમાન દેખાય છે અને સર્વર પર તેમનું કંઈ સામ્ય નથી.

ભૂલને તબક્કા સાથે મેળવો

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

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

લૉગિન પછી, અધિકૃતિ હજી પણ અલગ છે

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

તે એ જ સ્તરીકરણ છે જે હેન્ડશેકે દર્શાવ્યું, એક સ્તર ઉપર.

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