બ્રાઉઝરનું HTTPS જ્યાં સફળ થાય છે ત્યાં SSTP નિષ્ફળ જાય છે: કેમ
SSTP પોર્ટ 443 પર TLSની અંદર ચાલે છે, પણ તે વેબ વિનંતી નથી. TCP, TLS ઓળખ, SSTP વિનિમય અને PPP પ્રમાણીકરણને અલગ તબક્કા તરીકે ચકાસો.
બ્રાઉઝર VPN હોસ્ટનામને HTTPS પર કોઈ ફરિયાદ વિના ખોલે છે, અને SSTP ક્લાયન્ટ હજી પણ જોડાવાનો ઇનકાર કરે છે. એ જોડીમાં કંઈ વિરોધાભાસી નથી. SSTP TLSને બાહ્ય પરિવહન તરીકે વાપરે છે અને પછી તે જ જોડાણની અંદર પોતાની વિનંતી અને PPP પેલોડ ચલાવે છે, તેથી પૃષ્ઠ સફળતાપૂર્વક લોડ થવું ફક્ત એક સાંકડી વાત સાબિત કરે છે: હોસ્ટ પોર્ટ 443 પર GETનો જવાબ આપે છે. ક્લાયન્ટ બીજો પ્રશ્ન પૂછે છે, અને સર્વર તેનો જવાબ ખરાબ આપી શકે છે.
પૃષ્ઠ લોડ થાય છે અને ટનલ નહીં
લોકો બ્રાઉઝર પરીક્ષણ તરફ વળે છે કારણ કે તે ઝડપી છે, અને પછી પરિણામને સર્વર પહોંચી શકાય તેવું અને ગોઠવાયેલું હોવાના પુરાવા તરીકે લે છે. તે એડ્રેસ બારે ખોલેલા માર્ગ પરની GET વિશેનો પુરાવો છે, વધુ કંઈ નહીં. VPN વાતચીત એ જ TLS હેન્ડશેક પછી શરૂ થાય છે, પણ મોકલે છે એવી પદ્ધતિ અને માર્ગ જે વેબ પૃષ્ઠ ક્યારેય વાપરતું નથી. તેથી બ્રાઉઝર માટેનો 200 જવાબ SSTP એન્ડપોઇન્ટ અસ્તિત્વમાં છે કે નહીં તે વિશે કંઈ કહેતો નથી.
બે અવલોકનોને અલગ કરો અને શોધ ટૂંકી થાય છે. પરિવહન અને પ્રમાણપત્ર સાંકળ કામ કરે છે, અને તેમની ઉપરના પ્રોટોકોલ વિનિમયમાં કંઈક કામ કરતું નથી. આ તૂટેલા પોર્ટ કે સમાપ્ત થયેલા પ્રમાણપત્ર કરતાં જુદી તપાસ છે, અને તેને જુદા પુરાવા જોઈએ.
SSTP ક્લાયન્ટ ખરેખર શું મોકલે છે
ક્લાયન્ટ /sra_{GUID}/ માર્ગ પર SSTP_DUPLEX_POST પદ્ધતિ સાથે HTTP વિનંતી મોકલે છે, પછી જોડાણના બોડીને PPP ફ્રેમ્સ વહન કરતા દ્વિદિશ પ્રવાહ તરીકે ખુલ્લું રાખે છે. અનુરૂપ સર્વર HTTP/1.1 200નો જવાબ આપે છે અને વેબ સર્વર જેવું વર્તન બંધ કરે છે. બીજું કંઈ પણ એક સહી છે: 405 કે 404 એટલે એન્ડપોઇન્ટ નથી, 301 કે 302 એટલે કંઈક વિનંતીને ફરીમાર્ગિત કરે છે, અને તાત્કાલિક FIN એટલે પ્રોક્સી કે સર્વરે પ્રવાહ બંધ કર્યો છે.
તેથી લક્ષ્ય TLS પ્રમાણપત્ર જોડેલું વેબ સર્વર નહીં, પણ SSTP સર્વર હોવું જોઈએ. પદ્ધતિ, માર્ગ અને લાંબા સમયની બોડી પ્રોટોકોલની આવશ્યકતાઓ છે, તેથી રિવર્સ પ્રોક્સી ફક્ત ગોઠવણીથી તેમને ઉમેરી શકતું નથી. સામાન્ય HTTPS સંપૂર્ણ રીતે આગળ મોકલતું પ્રોક્સી પણ એવી પદ્ધતિ નકારી શકે છે જે તે ઓળખતું નથી.
પ્રોક્સી કે વેબ સર્વર પ્રવાહ ક્યાં તોડે છે
મધ્યસ્થી કંઈ પણ આગળ મોકલતા પહેલાં HTTP વિનંતી લાઇન તપાસે છે, અને અસામાન્ય માર્ગ સાથેની કસ્ટમ પદ્ધતિ તેના નિયમોમાં નિષ્ફળ જઈ શકે છે. કેટલાક ઉપકરણો સામાન્ય પૃષ્ઠ પરસોતા હોય છે જ્યારે ટનલ નકારે કે વિક્ષેપિત કરે છે, તેથી ક્લાયન્ટ સ્વચ્છ ઇનકારને બદલે શરૂ થઈને પછી મૃત્યુ પામતા જોડાણની જાણ કરે છે. અન્ય વિનંતી સ્વીકારે છે, પછી બોડી કે નિષ્ક્રિયતાની સમયમર્યાદા લાગુ કરે છે જે PPP કીપઅલાઇવ ટકી શકતા નથી. બંને ક્લાયન્ટની બાજુથી એકસરખા દેખાય છે, તેથી કયો તબક્કો નિષ્ફળ ગયો તે ભૂલના લખાણ કરતાં વધુ મહત્ત્વનું છે.
વેબસાઇટ અને SSTP વચ્ચે પોર્ટ 443 વહેંચવો એ રાઉટિંગ પસંદગી છે, દરેક હોપ બંને વાતચીતને એકસરખી રીતે સંભાળશે તેવું વચન નથી. જો માર્ગમાં લોડ બેલેન્સર, ફાયરવોલ કે TLS ટર્મિનેટર હોય, તો VPN ગોઠવણીને સ્પર્શતા પહેલાં તેને શંકાસ્પદ યાદીમાં ઉમેરો.
તબક્કા અલગ રીતે ચકાસો
તપાસ ક્રમમાં ચલાવો અને પ્રથમ નિષ્ફળતા પર અટકો, કારણ કે દરેક તબક્કો અલગ સ્તરને બાકાત કરે છે. નીચેની TLS પ્રોબ પ્રમાણપત્રની ઓળખને SSTP જે કરે છે તે બધાથી અલગ પાડે છે. હોસ્ટનામને તમારા એન્ડપોઇન્ટ સાથે બદલો અને તે જે સબ્જેક્ટ અને સાંકળ છાપે છે તે વાંચો.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comપછી ક્લાયન્ટ ભૂલમાંથી અનુમાન કરવાને બદલે બાકીના પુરાવાને તબક્કાઓ સાથે મેળવો. નીચેનું કોષ્ટક ટિકિટમાં ટાંકવા માટેની ચેકલિસ્ટ છે, જે સહી એક નિષ્ફળતાને બીજીથી અલગ પાડે છે.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
ટિકિટમાં "જોડાઈ શકાતું નથી" લખવાને બદલે છેવટે સફળ થયેલો તબક્કો નોંધો. MS-SSTP સ્પેસિફિકેશન TLS હેન્ડશેક પછી આવતી વિનંતી અને PPP વિનિમયનું દસ્તાવેજીકરણ કરે છે, અને બ્રાઉઝર પરીક્ષણ બંનેથી એકનું પણ વિકલ્પ કેમ ન બની શકે તેનો સંદર્ભ તે છે.
પહેલા ઓળખ, પછી PPP
TLS ઓળખ અને PPP પ્રમાણીકરણ ક્રમિક છે, વૈકલ્પિક નથી, અને તેમને ભેળવવાથી લોકો ખોટી સર્વર સેટિંગ તરફ જાય છે. ક્લાયન્ટ પહેલા સર્વર પ્રમાણપત્ર અને તેના ઇચ્છિત હેતુને માન્ય કરે છે, પછી PPP પોતાની સ્થિતિ વાટાઘાટ કરે છે અને વપરાશકર્તાને ચેલેન્જ-રિસ્પોન્સ પદ્ધતિ કે EAP સાથે પ્રમાણિત કરે છે. પ્રમાણપત્રની સમસ્યા નકારેલા પાસવર્ડ કરતાં જુદી ભૂલ આપે છે, અને બંન્નેમાંથી કોઈ ભૂલ બીજી જે તબક્કો આવરે છે તેનું વર્ણન કરતી નથી.
હોસ્ટનામને સરનામાથી બદલવું, અથવા પ્રમાણપત્ર ચેતવણી વટાવીને ક્લિક કરવું, નિષ્ફળ તબક્કાને ઓળખી કાઢતી તપાસને દૂર કરે છે, તેને સુધારતું નથી. ચેતવણી રાખો અને તેને વાંચો. જ્યારે HTTP વિનિમય ક્યારેય SSTP વર્તન સુધી પહોંચ્યો ન હોય ત્યારે PPP પાસવર્ડ રીસેટ કરશો નહીં, કારણ કે ઓળખપત્ર ક્યારેય માંગવામાં આવ્યું નથી.