VPN વારંવાર ડિસ્કનેક્ટ થાય છે? આ ક્રમમાં તપાસો
કંઈપણ બદલતા પહેલાં અંતરાલ, ક્લાયન્ટની ભૂલ અને નેટવર્કની સ્થિતિ નોંધો. ડિસ્કનેક્શન વચ્ચેનું અંતર કહે છે કે ચાર સ્તરોમાંથી કયું તપાસવું.
ક્લાયન્ટને ફરીથી ઇન્સ્ટોલ કરતા પહેલાં ત્રણ વસ્તુઓ લખો: ટનલ કેટલા સમય સુધી ચાલુ રહી, ડિસ્કનેક્ટ થયા ત્યારે ક્લાયન્ટે શું કહ્યું, અને એ દરમિયાન મશીન સૂતું હતું કે નેટવર્ક બદલ્યું હતું. એ નોંધ જ પછી તમારી પાસે રહેતો એકમાત્ર પુરાવો છે, અને ફરીથી ઇન્સ્ટોલ કરવાથી તે સામાન્ય રીતે ભૂંસાઈ જાય છે. પુનરાવર્તિત અંતરાલ પર થતું ડિસ્કનેક્શન ટાઇમર કે સ્થિતિની સમાપ્તિ છે; અવ્યવસ્થિત ક્ષણે થતું ડિસ્કનેક્શન માર્ગની સમસ્યા છે. નીચેનો ક્રમ તમને એકસાથે ત્રણ વસ્તુઓ બદલીને કંઈ ન શીખવાથી રોકે છે.
પ્રથમ પગલું: અંતરાલ અને ભૂલનું લખાણ નોંધો
વેન્ડરના ડેશબોર્ડને બદલે ક્લાયન્ટના પોતાના લોગથી શરૂ કરો. Linux ક્લાયન્ટ પર, સેવા લોગ અને ટનલની જીવંત સ્થિતિ મળીને તેનો મોટો ભાગ આવરી લે છે:
journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0
ફક્ત આઇકોનનો રંગ બદલાયાની ક્ષણ નહીં, પણ છેલ્લા સફળ હેન્ડશેકના સમયચિહ્નો અને ટ્રાફિક અટક્યાની ક્ષણ નોંધો. પછી ડિસ્કનેક્ટ થયું કહેતો GUI ક્લાયન્ટ કદાચ કર્નલ થોડી સેકન્ડ પહેલાં પહોંચેલી સ્થિતિની જાણ કરી રહ્યો હોય.
ભૂલનું શબ્દોત્તર જાળવી રાખો. ટાઇમઆઉટ, પ્રમાણીકરણનો અસ્વીકાર અને એડેપ્ટર કે ડ્રાઇવરની ભૂલ ત્રણ જુદા સ્તરો તરફ ઇશારો કરે છે, અને આ સમસ્યામાં બગડેલો મોટો ભાગ તેમને એક ગણીને વર્તવાથી આવે છે. લાઇન શબ્દશઃ તમારી નોંધમાં કૉપિ કરો.
બીજું પગલું: પ્રોફાઇલ નહીં, એક ચલ બદલો
ઉપકરણ અને પ્રોફાઇલ અપરિવર્તિત રાખો અને મશીનને બીજા એક્સેસ નેટવર્ક પર લઈ જાઓ, જેમ કે ફોનનો હોટસ્પોટ. ક્લાયન્ટને માર્ગથી અલગ પાડતી આ સૌથી સસ્તી કસોટી છે. મૂળ નિષ્ફળતાના અંતરાલને આવરી લે તેટલા લાંબા સમય ચલાવો; બે સ્થિર મિનિટ ત્રીસમી મિનિટે થતા ડિસ્કનેક્શન વિશે કંઈ પુરવાર કરતી નથી.
Ethernet પોર્ટવાળો લેપટોપ બીજી સરખામણી આપે છે જે Wi-Fiને ચિત્રમાંથી સંપૂર્ણ દૂર કરે છે. ટનલ બંને વિકલ્પો પર ટકે તો મૂળ એક્સેસ નેટવર્ક ધ્યાન દેવા લાયક છે: એક્સેસ પોઇન્ટ વચ્ચે રોમિંગ, અનુવાદ કોષ્ટક સમાપ્ત થતું ગ્રાહક રાઉટર, અથવા લાંબા પ્રવાહોને રીસેટ કરતી અપસ્ટ્રીમ લિંક.
તમે કયું ચલ બદલ્યું તે લખો. બાકીનું બધું સરખું રહ્યું હોય તો જ સરખામણી ગણાય છે, અને તેમાં સર્વરનું અંતિમ બિંદુ અને દિવસનો સમય પણ આવે છે.
ત્રીજું પગલું: અંતરાલને સ્તર સાથે જોડો
સારા સત્રની લંબાઈ તમારી પાસેની સૌથી માહિતીપ્રદ એક જ સંખ્યા છે. ટાઇમરને અડકતા પહેલાં તેને આ યાદી સામે વાંચો:
- સૂવા કે ફરી શરૂ થયા પછી ડિસ્કનેક્શન: ટનલની સ્થિતિ સસ્પેન્ડમાંથી પસાર થઈ ગઈ પણ ઇન્ટરફેસ નહીં. ફરી શરૂ થાય ત્યારે ક્લાયન્ટનું ફરી જોડાવાનું વર્તન અને સેવા ટનલ ફરી શરૂ કરે છે કે ટ્રાફિકની રાહ જુએ છે તે તપાસો.
- ફક્ત નિષ્ક્રિય હોય ત્યારે ડિસ્કનેક્શન: વચ્ચે કંઈકે પ્રવાહની મુદત પૂરી કરી. keepalive આ જ કિસ્સા માટે છે.
- નિશ્ચિત સત્ર-ઉંમરે ડિસ્કનેક્શન: ફરી પ્રમાણીકરણ કે કી નવીકરણની ઘટના, માર્ગની નિષ્ફળતા નહીં. બરાબર એ જ અંતરાલે લોગમાં સ્પષ્ટ અસ્વીકાર એ સંકેત છે.
- મોટા સ્થાનાંતરણ કે મોટા પૃષ્ઠો દરમિયાન ડિસ્કનેક્શન: MTU અને ફ્રેગ્મેન્ટેશન પર શંકા કરો, નિષ્ક્રિય ટાઇમર પર નહીં.
નિષ્ક્રિયતાના કિસ્સામાં સેટિંગ્સ પ્રોટોકોલ-આધારિત છે અને બંને છેડા મહત્વના છે. સર્વર પર OpenVPNનું keepalive 10 60 દર 10 સેકન્ડે પિંગ મોકલે છે અને એક પણ ન આવે તો 60 સેકન્ડ પછી લિંક ફરી શરૂ કરે છે; NAT પાછળના WireGuard ક્લાયન્ટ પીઅર બ્લોકમાં PersistentKeepalive = 25 વાપરે છે. OpenVPN ટાઇમર પ્રમાણે ડેટા ચેનલની ફરી વાટાઘાટ પણ કરે છે, reneg-sec, જે 2.xમાં મૂળભૂત રીતે 3600 સેકન્ડ છે.
બીજા પ્રદાતાની માર્ગદર્શિકામાંથી આક્રમક મૂલ્યો કૉપિ કરશો નહીં. નુકસાનયુક્ત મોબાઇલ લિંક પર ટૂંકો ટાઇમઆઉટ એ જ ડિસ્કનેક્શન પેદા કરે છે જે તેને રોકવાના હતા, અને સર્વર મોકલેલા મૂલ્યો ક્લાયન્ટ પ્રોફાઇલમાં તમે સેટ કરેલા મૂલ્યો પર વર્ચસ્વ ધરાવે છે.
ચોથું પગલું: એક સમર્થિત વિકલ્પની સરખામણી કરો
ઓપરેટર UDP અને TCP બંને પ્રોફાઇલ પ્રકાશિત કરે તો એ જ ઉપકરણ અને નેટવર્ક બીજા સામે ચલાવો. કૉપિ કરેલા પ્રોફાઇલમાં ટ્રાન્સપોર્ટ સંપાદિત કરવાને બદલે ખરેખર મેળ ખાતી ફાઇલ વાપરો. જ્યાં UDP રીસેટ થાય ત્યાં સ્થિર TCP પ્રોફાઇલ સમસ્યાને એ માર્ગ સુધી સંકુચિત કરે છે; તે પુરવાર કરતું નથી કે TCP દરેક જગ્યાએ વધુ સારું ટ્રાન્સપોર્ટ છે.
એ જ તર્ક અંતિમ બિંદુઓને લાગુ પડે છે. બીજું સર્વર અજમાવો અને મૂળ પરિણામ તેની બાજુમાં રાખો. જો ફક્ત એક આઉટલેટ સત્રો રીસેટ કરે, તો તે એ અંતિમ બિંદુ વિશેનો પુરાવો છે, લેપટોપના દરેક એડેપ્ટરને ફરી બનાવવાનું કારણ નહીં.
કોઈપણ ફેરફાર પછી મૂળ ટ્રિગરનું પુનરાવર્તન કરો અને ટ્રાફિક ખરેખર ક્યાં જાય છે તેની ખાતરી કરો. પાછું મળેલું ઇન્ટરનેટ એક્સેસ ટનલની અંદરના ટ્રાફિક જેવું જ પરિણામ નથી, અને ચૂપચાપ સીધા માર્ગે પાછું ફરેલું ક્લાયન્ટ બ્રાઉઝરથી સ્વસ્થ દેખાય છે.
સુધારો ચકાસો, અને રોલબેક રાખો
સુધારો મૂળ ટ્રિગરનું પુનરુત્પાદન કરીને ચકાસાય છે, સફળ કનેક્શનથી નહીં. જૂના નિષ્ફળતા અંતરાલની બહાર ટનલને નિષ્ક્રિય રાખો, એક વાર સસ્પેન્ડ અને ફરી શરૂ કરો, અને પછી હેન્ડશેકની ઉંમર અને એક્ઝિટ સરનામું તપાસો:
wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak # before editing timers
નવું વર્તન પૂરો કામકાજી દિવસ ટકી ન જાય ત્યાં સુધી અગાઉનું પ્રોફાઇલ અને અગાઉનાં ટાઇમર મૂલ્યો રાખો. ડિસ્કનેક્શન પાછાં આવે તો બેકઅપ પુનઃસ્થાપિત કરો, પછી બીજો પ્રયાસ જાણીતી સ્થિતિથી શરૂ થાય તે માટે એક વખતે એક ફેરફાર ફરી લાગુ કરો.
લોગ સ્વચ્છ રહે અને ટનલ હજી પુનરાવર્તિત અંતરાલે ડિસ્કનેક્ટ થાય તો આગલું સ્ટેશન એ સત્રના સર્વર બાજુ છે. ક્લાયન્ટનું સત્ર ઓળખકર્તા અને ડિસ્કનેક્શનનો ચોક્કસ સમય સાથે લો, કારણ કે એ જ જોડી સર્વર લોગને શોધપાત્ર બનાવે છે. પ્રોટોકોલની લિંક વિકલ્પો OpenVPN 2.6 મેન્યુઅલમાં દસ્તાવેજ કરેલા છે, જ્યારે તમને મૂલ્યનો ચોક્કસ અર્થ જોઈએ.