Mac VPN એક વાર કનેક્ટ થાય છે અને પછી સમય સમાપ્ત: IKE ડીમન સાફ કરો

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

macOS પર, તે કંઈક સામાન્ય રીતે IKE ડીમન હોય છે.

પેટર્ન: એક વાર કનેક્શન, પછી સમય સમાપ્ત

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

આ એક પણ લોગ ખોલ્યા પહેલાં તપાસને સાંકડી કરે છે. પ્રશ્ન એ બને છે કે કઈ પ્રક્રિયા IKE પોર્ટ ધરાવે છે અને તે પોતાને શું કરતી માને છે.

બે ડીમન, એક પોર્ટ

સિસ્ટમ ચલાવે છે racoon જ્યારે કનેક્શન IKE આવૃત્તિ 1 બોલે છે. વર્તમાન આવૃત્તિઓ પણ લાવે છે iked IKEv2 અને નવા IPsec સ્ટેક માટે. બંને UDP 500 અને UDP 4500 બાંધી શકે છે, અને બંને પાસવર્ડ પ્રોમ્પ્ટ પર કનેક્શન પ્રયાસ રદ થવા પર અથવા નેટવર્ક ફેરફારથી વચ્ચે અટકી પડવા પર અડધું-ખુલ્લું સુરક્ષા એસોસિએશન પકડી રાખી શકે છે.

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

કંઈપણ મારતા પહેલાં માલિક શોધો, કારણ કે જવાબ નક્કી કરે છે કે તમે કઈ સેવા ફરી શરૂ કરશો અને આગળ કયો લોગ વાંચશો.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

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

પ્રક્રિયા નહીં, જોબ ફરી શરૂ કરો

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

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

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

પછી એક વાર કનેક્ટ કરો અને ક્લાયન્ટ લોગ શરૂઆતથી વાંચો. જે વાટાઘાટ તબક્કા 1 પછી આગળ વધે છે અને પછી ટ્રાન્સમિટ નિષ્ફળતા જણાવે છે તે સ્થાનિક સોકેટ સમસ્યાનું પુનરાવર્તન કરે છે; પીઅર દ્વારા નકારાયેલી વાટાઘાટ સંપૂર્ણપણે અલગ ટિકિટ છે.

જ્યારે સર્વર જ નકારી રહ્યું હોય

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

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

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

જૂના ક્લાયન્ટ અને 64-બિટ કર્નલ

જૂનો Cisco IPSec ક્લાયન્ટ 32-બિટ અને PowerPC સિસ્ટમો માટે બનેલું કર્નલ એક્સટેન્શન લોડ કરે છે. 64-બિટ કર્નલમાં બૂટ થયેલા Mac પર તે એક્સટેન્શન લોડ થઈ શકતું નથી, અને ક્લાયન્ટ ભૂલ 51 સાથે વહેલું નિષ્ફળ જાય છે કારણ કે તે VPN સબસિસ્ટમ સુધી જ પહોંચી શકતું નથી. ખોટી આર્કિટેક્ચર ધરાવતું કર્નલ એક્સટેન્શન કેટલાય ડીમન રીસ્ટાર્ટથી પણ સુધરતું નથી.

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

• એક વાર પુનઃઉત્પાદન કરો, પછી પ્રોફાઇલને સ્પર્શ કરતા પહેલાં કયું ડીમન UDP 500 ધરાવે છે તે તપાસો.
• તબક્કા 1 પછીની પહેલી નિષ્ફળતા વાંચો: ટ્રાન્સમિટ ભૂલ સ્થાનિક સોકેટ તરફ ઇશારો કરે છે.
• ફક્ત પ્રક્રિયા નહીં, launchd જોબ ફરી શરૂ કરો અને પોર્ટ મુક્ત છે તેની પુષ્ટિ કરો.
• સર્વર-બાજુની ફરી પ્રમાણીકરણ વિન્ડોને ક્લાયન્ટ ખામીથી અલગ પાડવા બીજું એકાઉન્ટ અજમાવો.
• ક્લાયન્ટને દોષ આપતા પહેલાં કર્નલ આર્કિટેક્ચર નોંધો.

બરાબર એક વાર કામ કરતું VPN વિરુદ્ધ સાબિત ન થાય ત્યાં સુધી સ્થિતિની સમસ્યા છે. ડીમન સાફ કરવું રીબૂટ કરવા કરતાં ઝડપી છે, અને તે તે લોગ પુરાવા જાળવે છે જે રીબૂટ ફેંકી દેત.