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

બે નિષ્ફળતા, બે જુદાં આદાનપ્રદાન

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

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

લોગની લાઇન સામાન્ય રીતે કહે છે કે તમે ત્રણમાંથી ક્યાં છો, તેથી પહેલા ફેરફાર પહેલાં તેને કેદ કરવી યોગ્ય છે.

સમયસીમા એટલે એક તબક્કો ક્યારેય પૂરો ન થયો

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

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

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

સાથી તરફથી કોઈપણ પ્રતિસાદ પહેલાંની સમયસીમા ખાતા વિશે કંઈ કહેતી નથી, અને તે સમયે પાસવર્ડ બદલવો ફક્ત એક ચલ ઉમેરે છે.

પ્રમાણપત્ર ભૂલ એટલે ઓળખ નકારાઈ

અહીં સર્વરે ખરેખર જવાબ આપ્યો, તેથી નેટવર્ક કામ કરે છે અને પ્રશ્ન ઓળખ તરફ ખસે છે. ક્લાયન્ટ જે નામે ડાયલ કરે છે તેને પ્રમાણપત્ર ખરેખર જે નામો દાવો કરે છે તેની સાથે સરખાવો, પછી માન્યતા તારીખો અને જારક સાંકળ તપાસો.

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

સફળ TLS તબક્કો પસાર થયા પછી અકબંધ રાખો, કારણ કે પછીથી તેને પાછું વાળવાથી કયા ફેરફારે ટનલ ખરેખર સુધારી તે છુપાય છે.

બંને ક્યાં ભળી જાય છે

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

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

પ્રમાણપત્રનો પ્રશ્ન અને પહોંચનો પ્રશ્ન કારણસર અલગથી દસ્તાવેજ કરાયા છે.

સાચા ક્લાયન્ટ સાથે ફરી પરીક્ષણ કરો, પછી અંદરની તરફ જાઓ

ચોક્કસ સુધારો જગ્યાએ બેસી જાય પછી બ્રાઉઝર ટૅબ નહીં, વાસ્તવિક SSTP ક્લાયન્ટ અને સાચી પ્રોફાઇલ સાથે ફરી પ્રયાસ કરો.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

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

સંબંધિત લેખો