Azure Point-to-Site VPN ના લોગ ક્યાં છે? Monitor માં જુઓ

વપરાશકર્તા Point-to-Site ગેટવે સાથે કનેક્ટ થઈ શકતો નથી, તમે ગેટવે બ્લેડ ખોલો છો, અને પૃષ્ઠ પર ક્યાંય કનેક્શન ઇતિહાસ નથી. રૂપરેખાંકન, પ્રમાણપત્રો, સ્થિતિ: બધું હાજર, કોઈ રેકોર્ડ નથી. લોગ અસ્તિત્વમાં છે, પરંતુ નેટવર્કિંગ પૃષ્ઠો તેમને બિલકુલ બનાવતા નથી. તેઓ ગેટવે સંસાધન સાથે જોડાયેલી ડાયગ્નોસ્ટિક સેટિંગમાંથી આવે છે, અને તે સેટિંગ Monitor હેઠળ રહે છે; તેથી સ્પષ્ટ જગ્યાએ પ્રથમ શોધ કંઈ પણ પરત કરતી નથી, અને લોકો તારણ કાઢે છે કે સેવા કોઈ ઓડિટ ટ્રેલ રાખતી નથી.

સ્પષ્ટ શોધ કેમ નિષ્ફળ જાય છે

જૂની માર્ગદર્શિકા કહે છે કે Azure Point-to-Site VPN માં કોઈ ઓડિટ નથી, અને તે ત્યારે સાચું હતું જ્યારે સેવા દરેક કનેક્શન માટે કોઈ રેકોર્ડ બહાર પાડતી ન હતી. વર્તમાન ગેટવે ટનલ ડાયગ્નોસ્ટિક રેકોર્ડ પ્રકાશિત કરે છે, તેથી ઉપયોગી પ્રશ્ન બદલાયો છે: લોગ છે કે નહીં તે નહીં, પરંતુ કયું સંસાધન તેમને બહાર પાડે છે અને તમે કઈ શ્રેણી ચાલુ કરી છે. ગેટવે બ્લેડ એ રૂપરેખાંકન સપાટી છે, અને રૂપરેખાંકન સપાટીઓ ભાગ્યે જ લોગ વ્યુઅર તરીકે પણ કામ કરે છે. ડાયગ્નોસ્ટિક સેટિંગ એ દરેક સંસાધન માટેની વસ્તુ છે, તેથી તમે પસંદ કરેલું સંસાધન પછીનું બધું નક્કી કરે છે.

મૂંઝવણનો બીજો અડધો ભાગ પ્રમાણીકરણ છે. પ્રમાણપત્ર-આધારિત Point-to-Site કનેક્શન ઓળખ પ્રદાતા જેવી રીતે દરેક વપરાશકર્તા માટે સાઇન-ઇન ઘટના બનાવતા નથી, તેથી પાસવર્ડ ટાઇપ કરતી નામવાળી વ્યક્તિનો કોઈ રેકોર્ડ મળતો નથી.

ડાયગ્નોસ્ટિક સેટિંગને ગેટવે સંસાધન સાથે જોડો

Monitor ખોલો, પછી Diagnostic settings, અને નવી સેટિંગ ઉમેરો જેનું લક્ષ્ય વર્ચ્યુઅલ નેટવર્ક ગેટવે પોતે હોય, તેને ધરાવતું વર્ચ્યુઅલ નેટવર્ક નહીં. Point-to-Site ડાયગ્નોસ્ટિક શ્રેણી પસંદ કરો, જેનું નામ P2SDiagnosticLog છે, કારણ કે તે દરેક ક્લાયન્ટ માટે કનેક્શન રેકોર્ડ ધરાવે છે; ટનલ, રૂટ અથવા IKE શ્રેણીઓ ફક્ત તે કવર કરતી site-to-site ભૂલો માટે ઉમેરો. પછી ડેટા તમે નિયંત્રિત કરો છો તેવા Log Analytics વર્કસ્પેસમાં મોકલો, તમે જાણી જોઈને પસંદ કરેલા જાળવણી સમયગાળા સાથે. મોટાભાગની નિષ્ફળ શોધ એ ખોટા સંસાધન સાથે જોડાયેલી સેટિંગ છે, ખૂટતી સુવિધા નહીં.

શ્રેણીની યાદીઓ ગેટવે પ્રકાર અને પેઢી પ્રમાણે અલગ પડે છે. જો Point-to-Site શ્રેણી ગેરહાજર હોય, તો ગેટવે સુવિધા કરતાં જૂનું હોઈ શકે અથવા એવા SKU પર ચાલતું હોઈ શકે જે તેને ક્યારેય બહાર પાડતું નથી, તેથી પરવાનગીની સમસ્યા શોધતા પહેલાં સમર્થિત શ્રેણીઓ તપાસો. Point-to-Site શ્રેણી વગરનું ગેટવે બગડેલું નથી; તે ફક્ત તે રેકોર્ડનો સ્રોત બની શકતું નથી, અને સૌથી નજીકનો વિકલ્પ ટનલ અથવા IKE શ્રેણી છે, જે ક્લાયન્ટનું સરનામું નોંધે છે ભલે તે Point-to-Site સત્રનું વર્ણન કરતી ન હોય. ખૂટતા લોગ વિશે સપોર્ટ કેસ ખોલતા પહેલાં શ્રેણીની યાદીની પુષ્ટિ કરો.

તમારો મોડ જે કોષ્ટક વાપરે તેમાં રેકોર્ડ વાંચો

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

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

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

ગેટવે રેકોર્ડને ક્લાયન્ટના પોતાના દૃશ્ય સાથે જોડો

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

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

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

જાળવણી, વ્યાપ્તિ અને રનબુક એન્ટ્રી

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

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