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 সংযোগ লগ, বা ক্লায়েন্ট অ্যাপ যে ত্রুটি পাঠ দেখিয়েছে তা। মিলিত ক্লায়েন্ট প্রচেষ্টা ছাড়া একটি গেটওয়ে রেকর্ড ক্লায়েন্টের দিকে ইঙ্গিত করে; কোনো ক্লায়েন্ট সাফল্য জানালে অথচ গেটওয়ে কিছু রেকর্ড না করলে সাধারণত বোঝায় প্রোফাইলটি অন্য গেটওয়ের লক্ষ্য করে।

দুই অর্ধেক একই টিকিটে রাখুন। একা গেটওয়ে লগ ভুল সিদ্ধান্তে আমন্ত্রণ জানায়, এবং একা ক্লায়েন্ট লগ দেখাতে পারে না প্যাকেটটি আদৌ পৌঁছেছিল কি না।

যদি দুই জায়গার কোথাও কিছু না দেখা যায়, প্ল্যাটফর্মকে সন্দেহ করার আগে ক্লায়েন্টের ঘড়ি পরীক্ষা করুন। বেঠিক টাইমস্ট্যাম্প সম্পর্ককে এমনভাবে ব্যর্থ করে যা ঠিক অনুপস্থিত ডেটার মতো দেখায়।

ধারণকাল, পরিধি এবং রানবুক এন্ট্রি

টানেল রেকর্ডে ক্লায়েন্ট ঠিকানা ও সংযোগের টাইমস্ট্যাম্প থাকে, তাই প্ল্যাটফর্মের ডিফল্ট রেখে না দিয়ে সেগুলিকে মুছে ফেলার সময়সূচিসহ ব্যক্তিগত ডেটা হিসেবে বিবেচনা করুন। এটিও পরীক্ষা করুন যে ওয়ার্কস্পেসটি সাবস্ক্রিপশনের প্রতিটি রিসোর্সের প্রতিটি বিভাগ গ্রহণ করছে না, কারণ কোলাহলপূর্ণ ওয়ার্কস্পেস সম্পর্ককে ক্লায়েন্ট লগ সরাসরি পড়ার চেয়ে ধীর করে দেয়।

অবশেষে, সেটিংয়ের নাম, ওয়ার্কস্পেস এবং বেছে নেওয়া বিভাগগুলি গেটওয়ের রানবুকে লিখুন। পরবর্তী যে ব্যক্তি কোনো ক্লায়েন্ট ডিবাগ করবেন তিনি প্রথমে গেটওয়ে ব্লেডে দেখবেন, কিছু পাবেন না, এবং সিদ্ধান্তে আসবেন যে লগগুলির অস্তিত্ব নেই।