સાઠ સેકન્ડનો TLS સમયસીમા: કઈ બાજુ ખરેખર અટકી?

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

એક પ્રયાસને એવી ઓળખ આપો જે તમે શોધી શકો

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

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

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

ચાર અવલોકન, ચાર જુદા જુદા આગલા પગલાં

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

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

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

પુરાવો જે તબક્કાનું નામ લે છે તે સુધારો

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

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

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

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

વિન્ડો લંબાવવાથી ખરેખર શું બદલાય છે

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

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