TLSની તપાસ કરતા પ્રોક્સી પાછળ SSTP: સેશન ક્યાં તૂટે છે

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

ક્લાયન્ટ જ્યાં અટકે છે ત્યાંથી શરૂ કરો

ક્લાયન્ટ નિશ્ચિત ક્રમમાંથી પસાર થાય છે: પોર્ટ 443 પર TCP જોડાણ, TLS હેન્ડશેક, પ્રમાણપત્ર માન્યતા, SSTPનું HTTP વિનિમય, PPP વાટાઘાટ અને પ્રમાણીકરણ, પછી IP રૂપરેખાંકન. દરેક તબક્કે નિષ્ફળતા અલગ છાપ છોડે છે, અને તેમને ભેળવી દેવાથી તમે ખોટા રૂપરેખાંકન પૃષ્ઠ પર પહોંચો છો.

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

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

SSTP નેટવર્કને શું વહન કરવાનું કહે છે

SSTP TCP 443 પર TLS ઉપર ચાલે છે અને પછી SSTP સ્પષ્ટીકરણ માં વ્યાખ્યાયિત SSTP_DUPLEX_POST નામની HTTP વિનંતી /sra_{GUID}/ સ્વરૂપના પથ પર મોકલે છે. વિનંતી વ્યવહારીક રીતે અમર્યાદિત સામગ્રી લંબાઈ જાહેર કરે છે અને સેશનના આખા જીવનકાળ દરમિયાન સ્ટ્રીમને બંને દિશામાં ખુલ્લી રાખે છે. PPP ફ્રેમ્સ તે સ્ટ્રીમની અંદર મુસાફરી કરે છે.

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

મેથડ ફિલ્ટરિંગ અને પ્રમાણીકરણ પોતાની નિષ્ફળતાની રીતો ઉમેરે છે. જો પ્રોક્સી વિનંતી માટે ઓળખપત્ર માંગે, તો બ્રાઉઝર જવાબ આપે તેમ હોવા છતાં VPN ક્લાયન્ટ જવાબ ન આપે. જો તે મેથડ દૂર કરે કે ફરી લખે, તો ગેટવે PPP શરૂ થાય તે પહેલાં વિનંતી નકારી કાઢે છે.

તપાસ ઓળખ કેમ બદલે છે

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

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

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

સેટિંગ્સ બદલતા પહેલાં જારીકર્તા ઓળખો

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

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

એ જ હોસ્ટ પર બ્રાઉઝર પરીક્ષણ ફક્ત એ સાબિત કરે છે કે પ્રોક્સી GET સ્વીકારે છે. તે SSTP મેથડ, વિનંતી URI કે બોડીના જીવનકાળ વિશે કંઈ કહેતું નથી, તેથી કાર્યરત ઇન્ટ્રાનેટ પૃષ્ઠને ટનલ પથ સમર્થિત હોવાનો પુરાવો ન ગણો.

સમર્થિત પથ પસંદ કરો

નેટવર્ક માલિકને એક ચોક્કસ પ્રશ્ન પૂછો: શું પ્રોક્સી આ ગેટવે પર પોર્ટ 443 પર બિન-બફર ડ્યુપ્લેક્સ POSTની મંજૂરી આપે છે? હા એટલે પ્રોક્સીમાં અપવાદ કે VPN હોસ્ટ માટે દસ્તાવેજીકૃત બાયપાસ. ના એટલે તપાસાયેલો પથ SSTP વહન કરી શકતો નથી, અને સમર્થિત સુધારો ક્લાયન્ટની ફેરફાર નહીં, બીજો પથ કે પ્રોટોકોલ છે.

વિકલ્પોમાં સામાન્ય રીતે VPN ગેટવે માટે બિન-તપાસાયેલું એગ્રેસ, ફક્ત કોર્પોરેટ ટ્રાફિક પ્રોક્સી દ્વારા મોકલતું સ્પ્લિટ-ટનલ ડિઝાઇન, અથવા સંસ્થા બીજા પોર્ટ પર સમર્થન આપતો વૈકલ્પિક પ્રોટોકોલ સામેલ હોય છે. દરેક નેટવર્ક ડિઝાઇનનો ભાગ છે, અને તુલના પથને અલગ કરે તે માટે દરેકને એ જ ઉપકરણ અને પ્રોફાઇલ સાથે ચકાસવું જોઈએ.

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