Cloud VPN સ્થિતિ: IKE લોગ પહેલાં સંસાધનની સ્થિતિ વાંચો

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

એક ટનલ ઑબ્જેક્ટ અને એક સમય-વિન્ડોથી શરૂ કરો.

બે જીવનચક્ર, એક ટનલ ઑબ્જેક્ટ

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

એ જ ભેદ આખી સમસ્યા છે. બાકીનું બધું એ છે કે અસંબંધિત સંદેશાઓ ભેગા કર્યા વિના તેનું નિરીક્ષણ કેવી રીતે કરવું.

ઑબ્જેક્ટ વાંચો, કન્સોલનો સારાંશ નહીં

APIને ફક્ત તે બે ક્ષેત્રો માટે પૂછો જે મહત્વના છે અને બીજું કંઈ નહીં, જેથી જવાબ રાત્રે ત્રણ વાગ્યે વાંચવા જેટલો નાનો રહે: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". status ક્ષેત્ર જીવનચક્રનો તબક્કો નામ આપે છે, અને detailedStatus તેની સાથે જોડાયેલું વાંચી શકાય તેવું કારણ વહન કરે છે. સંપૂર્ણ રૂપરેખાંકન ડમ્પ બીજા પ્રશ્નોના જવાબ આપે છે અને ટિકિટમાં પેસ્ટ કરવું વધુ મુશ્કેલ છે. આવા ફક્ત-વાંચન કોલ ટનલ બદલી શકતા નથી, જે ઘટના હજી ચાલુ હોય ત્યારે મહત્વનું છે.

કોલનો ટાઇમસ્ટેમ્પ મૂલ્યોની બાજુમાં નોંધો, કારણ કે બંને ક્ષેત્રો ખસે છે.

ALLOCATING_RESOURCES કીની અસંગતિ નથી

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

રૂપરેખાંકન વિશે તારણ કાઢતાં પહેલાં સ્થિતિ બદલાય તેની રાહ જુઓ.

ESTABLISHED એ ઍક્સેસ ચકાસણીઓની શરૂઆત છે

સ્થાપિત ટનલ એટલે IKE પૂર્ણ થયું, ટ્રાફિક વહે છે એમ નહીં. ટનલ જે રૂટ વહન કરે છે તેની ખાતરી કરો અને, જ્યાં Cloud Router સંડોવાયેલું હોય, BGP સત્ર અને તેણે શીખેલા પ્રીફિક્સની ખાતરી કરો. પછી મંજૂર એપ્લિકેશન આપલેનું પરીક્ષણ કરો, કારણ કે ફાયરવોલ નિયમ અથવા ખૂટતો રૂટ સંપૂર્ણ સ્વસ્થ ટનલમાંથી ટ્રાફિક અવરોધી શકે છે. તેમાંથી દરેક અલગ નિરીક્ષણ છે અલગ સુધારા સાથે.

સ્થિતિ તમને કહે છે કે આગળ કયો પ્રશ્ન પૂછવો. તે ક્યારેય તમારા વતી ઍક્સેસના પ્રશ્નનો જવાબ આપતું નથી.

એક ઑબ્જેક્ટ અને એક સમય-વિન્ડોને સહસંબંધિત કરો

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

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

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