TCP રીસેટ સાબિત કરતું નથી કે તમારું VPN બ્લોક થઈ રહ્યું છે

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

રીસેટ પેકેટ છે, ચુકાદો નહીં

TCP રીસેટ પ્રક્રિયા નક્કી કરે છે: RST ફ્લેગવાળો સેગમેન્ટ કનેક્શન તરત જ સમાપ્ત કરે છે. પ્રાપ્તકર્તા વાટાઘાટ કરતું નથી, ફરી પ્રયાસ કરતું નથી અને કેમ પૂછતું નથી. તે રીસેટની જાણ કરે છે અને આગળ વધે છે.

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

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

કયું કનેક્શન રીસેટ થયું તે નિશ્ચિત કરો

પહેલાં તપાસો કે સક્રિય પ્રોફાઇલ ખરેખર TCP વાપરે છે. UDP ટનલ પર રીસેટ અર્થહીન છે, અને HTTP પ્રોક્સીનો લોગ VPN કરતાં બીજા TCP ભાગને લગતો હોઈ શકે.

ગંતવ્ય, પોર્ટ, પ્રયાસનો સમય અને ક્લાયન્ટ પહોંચેલો તબક્કો નોંધો.

તબક્કો સૌથી ઉપયોગી ક્ષેત્ર છે. TLS હેન્ડશેક દરમિયાન રીસેટ એક શંકાસ્પદ જૂથ તરફ ઇશારો કરે છે; પ્રમાણીકરણ પછીનો રીસેટ બીજા જૂથ તરફ. તબક્કા વિના દરેક સિદ્ધાંત ફિટ થાય છે.

માર્ગના બંને છેડા સરખાવો

જો તમે સર્વર સંભાળો છો, તો તે જ પ્રયાસ માટે તેની ઘટનાઓ સરખાવો. તેણે કનેક્શન સ્વીકાર્યું? તેણે તેને જાણી જોઈને બંધ કર્યું? કોઈ જવાબ એક સીમા છોડીને બીજી સીમા સુધી ક્યારેય પહોંચ્યો નહીં?

જો શક્ય હોય તો ક્લાયન્ટ અને સર્વર બંને પર કેપ્ચર કરો. ક્લાયન્ટ પર દેખાતો પણ સર્વર પર ન દેખાતો રીસેટ સર્વર પર ઉદ્ભવ્યો નથી.

બંને દિશામાં RST સેગમેન્ટ પર ધ્યાન રાખો:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

નિયંત્રિત સરખામણીથી સંકુચિત કરો

બીજું મંજૂર નેટવર્ક તમને કહી શકે કે નિષ્ફળતા ક્લાયન્ટને અનુસરે છે કે માર્ગને. જો એ જ પ્રોફાઇલ બીજે કામ કરે, તો ક્લાયન્ટ રૂપરેખા સંભવતઃ ઠીક છે અને ચલ માર્ગ છે.

તે હજી એક ચોક્કસ મધ્યસ્થ ઉપકરણ ઓળખતું નથી. તે વ્યાપ્તિને એક માર્ગ સુધી મર્યાદિત કરે છે, જે ઉપયોગી અને પ્રામાણિક પરિણામ છે.

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

વિશ્વાસ સેટિંગ્સ બદલ્યા વિના સુધારો ચકાસો

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

ઓળખાયેલ ઘટકને તેના માલિક દ્વારા સુધારો, પછી એ જ પ્રોફાઇલ અને એ જ નિરીક્ષણનું પુનરાવર્તન કરો:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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