SSTP એ HTTPS પરનું PPP છે, પોર્ટ 443 પરનું વેબ પેજ નથી

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

ચાર તબક્કાઓ ક્રમમાં પસાર કરો, અને તમે જે નિષ્ફળતા જુઓ છો તે તેમાંથી એકમાં આવશે.

તબક્કો 1: TCP અને TLS

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

સામાન્ય વેબ સર્વર આ તબક્કો સંપૂર્ણ રીતે પૂર્ણ કરી શકે છે અને તેમ છતાં આગલા તબક્કામાં નિષ્ફળ જાય છે. TLS ની સફળતા પ્રમાણપત્રનો પુરાવો છે, તેની પાછળના પ્રોટોકોલનો નહીં.

તબક્કો 2: HTTPS વિનંતી

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

સર્વર લોગમાં પ્રતિસાદ કોડ અને પદ્ધતિ વાંચો. આ તબક્કે નકાર TCP ટાઈમઆઉટથી જુદી સમસ્યા છે, અને બંને જુદા જુદા સુધારા તરફ દોરી જાય છે.

તબક્કો 3: નિયંત્રણ સંદેશા

વિનંતી સ્વીકારાયા પછી, SSTP એવા નિયંત્રણ સંદેશાઓની આપલે કરે છે જે ટ્યુનલની વાટાઘાટ કરે છે અને તેને તૈયાર કરે છે. આ HTTP વિનંતીઓ નહીં પણ HTTPS બોડીની અંદરના પ્રોટોકોલ સંદેશાઓ છે, તેથી બોડીની તપાસ કરીને ફરી લખતું પ્રોક્સી પેજ વિનંતીઓને અસ્પૃશ્ય રાખીને તેમને તોડી શકે છે.

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

તબક્કો 4: PPP સંભાળ લે છે

પછી PPP સત્રનું વર્તન પૂરું પાડે છે: લિંક વાટાઘાટ, પ્રમાણીકરણ અને તે પછીની નેટવર્ક-સ્તર ગોઠવણી. PPP પ્રમાણીકરણ ક્લાયન્ટ પહેલેથી પસાર થયેલી TLS તપાસથી અલગ છે. ક્લાયન્ટ જે સર્વર પ્રમાણપત્ર સ્વીકારે છે તે વપરાશકર્તાના ઓળખપત્રો માન્ય છે કે ખાતું અધિકૃત છે તે વિશે કંઈ કહેતું નથી.

સ્વીકૃત પ્રમાણપત્ર અને નકારેલું લોગિન પરસ્પર વિરોધી નથી. તે સ્વતંત્ર પરિણામો સાથેના ક્રમિક તબક્કાઓ છે.

પ્રમાણીકરણની ઘણી ભૂમિકાઓ છે

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

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

બ્રાઉઝર પરીક્ષા શું બતાવી શકે અને શું નહીં

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

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