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

তিনটি অবজেক্ট, যার একটি প্রিফিক্স ধরে রাখে

ভার্চুয়াল নেটওয়ার্কের ঠিকানার জায়গা অন্য একটি প্রশ্নের উত্তর দেয়: Azure-এর ভিতরে কী থাকে। সেখানে দূরবর্তী প্রিফিক্স যোগ করলে ট্রাফিক সেখানে রুট হয় না, এটি কেবল সেই জায়গাটি প্রশস্ত করে যা প্ল্যাটফর্ম মনে করে তার মালিকানা, এবং তা প্রকৃত দূরবর্তী রেঞ্জের সঙ্গে সংঘর্ষে যেতে পারে। লোকাল নেটওয়ার্ক গেটওয়ে হলো সেই অবজেক্ট যা দূরবর্তী প্রিফিক্সগুলো ধরে রাখে, এবং সংযোগটি দুটি গেটওয়ে এবং একটি পূর্ব-শেয়ার করা কী-র প্রতি রেফারেন্স করে।

আরও একটি সংরক্ষণ আছে যা মনে রাখতে হবে। GatewaySubnet পরিচালিত গেটওয়ে ইনস্ট্যান্সগুলো হোস্ট করে, ঠিক সেই নামটিই বহন করতে হবে, এবং নন-Basic SKU-এর জন্য এটি অন্তত /27 হওয়া প্রত্যাশিত।

ওই সাবনেটে আর কিছুই থাকার কথা নয়, এবং প্রিফিক্স পরিবর্তনের তা স্পর্শ করার কোনো কারণ নেই। লোকাল নেটওয়ার্ক গেটওয়েতে অনুপস্থিত প্রিফিক্স সংযোগের অবস্থা যা-ই বলুক, পৌঁছানো যায় না, কারণ গেটওয়ে টানেল নেগোশিয়েট করার সময় কেবল সেই প্রিফিক্সগুলোই অফার করে যা তাকে জানানো হয়েছিল। এজন্যই উপসর্গটি অপ্রতিসম: টানেল চালু, সিকিউরিটি অ্যাসোসিয়েশন ঠিক, আর একটি সাবনেট কখনোই ট্রাফিক সিলেক্টরে দেখা যায় না। যদি প্রতিবেশীরা কাজ করার সময় একটি দূরবর্তী রেঞ্জ অনুপস্থিত থাকে, তবে টানেলের দিকে তাকানো বন্ধ করুন এবং লোকাল নেটওয়ার্ক গেটওয়ে পড়ুন।

কেন সংযোগটিই সরানো হয়

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

সেই মুছে ফেলা হলো আউটেজ, তাই এটিকে দ্রুত সম্পাদনার বদলে শুরু ও প্রত্যাশিত শেষসহ নির্ধারিত পরিবর্তন হিসেবে দেখুন। PowerShell-এ ক্রমটি সংক্ষিপ্ত: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, তারপর Set-AzLocalNetworkGateway নতুন -AddressPrefix অ্যারে দিয়ে, তারপর New-AzVirtualNetworkGatewayConnection একই -SharedKey এবং একই গেটওয়ে দিয়ে। কী পুনরায় ব্যবহার করা গুরুত্বপূর্ণ, কারণ দূরবর্তী দিকটি পুনরায় কনফিগার হচ্ছে না এবং নতুন কী মানে দূরবর্তী ডিভাইসের মালিকের সঙ্গে সমন্বয়। যদি অন্য দল ওই ডিভাইস চালায়, কিছু সরানোর আগে তাদের সঙ্গে সময়সীমা একমত করুন।

কখন গেটওয়েটি নিজেই নতুন করে তৈরি করতে হয়

এই সমস্যাটিকে ঘিরে ঘোরা দ্বিতীয় একটি উত্তর বলে গেটওয়ে পুনরায় তৈরি করতে হবে এবং কী আবার বিনিময় করতে হবে। এটি ভিন্ন ধরনের কাজের জন্য সঠিক: গেটওয়ের ধরন বা SKU পরিবর্তন, পয়েন্ট-টু-সাইট ও সাইট-টু-সাইটের মধ্যে স্থানান্তর, অথবা যে গেটওয়ের নিজের কনফিগারেশন ভুল তা মেরামত। ওই পরিবর্তনগুলো সত্যিই গেটওয়ে রিসোর্স বদলায়, তাই নতুন করে তৈরি করা সত্যিই প্রয়োজন।

পয়েন্ট-টু-সাইটের জন্য তৈরি গেটওয়েকে সহজে সাইট-টু-সাইট সংযোগ দেওয়া যায় না। পয়েন্ট-টু-সাইট কনফিগারেশন সরিয়ে গেটওয়ে পুনরায় তৈরি করতে হয়, যা নতুন শেয়ার করা কী এবং নতুন ক্লায়েন্ট প্যাকেজও দেয়।

পয়েন্ট-টু-সাইট প্যাকেজটির আলাদা নোট দরকার কারণ এটি মেয়াদোত্তীর্ণ হয়। পোর্টাল একটি স্বল্পস্থায়ী ফাইল তৈরি করে, তাই ব্যবহারিক পন্থা হলো এটি একবার ডাউনলোড করে ক্লায়েন্ট সার্টিফিকেটের সঙ্গে বিতরণ করা, ব্যবহারকারীদের এমন পোর্টাল লিঙ্ক পাঠানো নয় যা তারা ক্লিক করার সময় মৃত থাকবে। প্রিফিক্সের প্রশ্নে এর কিছুই প্রযোজ্য নয়। দুটি পদ্ধতি আলাদা রাখাই পুরো শৃঙ্খলা: প্রিফিক্স সংযোগ-স্তরের পরিবর্তন, আর গেটওয়ে বৈশিষ্ট্য গেটওয়ে-স্তরের পরিবর্তন।

অবস্থা পড়ুন, পোর্টালের ব্যাজ নয়

পোর্টালের ব্যাজের বদলে রিসোর্স থেকে অবস্থা পড়ুন। Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 ফেরত দেয় ConnectionStatus ইনগ্রেস ও এগ্রেস বাইট কাউন্টারের সঙ্গে, এবং কাউন্টারগুলোই সংযুক্ত কিন্তু কিছু বহন করছে না এমন টানেলকে কখনো প্রতিষ্ঠিত হয়নি এমন টানেল থেকে আলাদা করে।

যে কাউন্টারগুলো ট্রান্সফারের মাঝপথে বাড়া থামিয়ে দেয়, সেগুলো প্রমাণীকরণের বদলে পথের দিকে ইঙ্গিত করে. আর যে কাউন্টার একেবারেই নড়ে না, তা প্রিফিক্স সেট বা শেয়ার করা কী-র দিকে ইঙ্গিত করে।

টাইমার এমন এক শ্রেণির বিচ্ছিন্নতা ব্যাখ্যা করে যা ভুলভাবে VPN-এর উপর আরোপ করা হয়। Azure-এর লোড ব্যালান্সার তার কনফিগার করা টাইমআউটের পরে নিষ্ক্রিয় ফ্লো বন্ধ করে, এই নোটগুলো লেখার সময় ডিফল্ট চার মিনিট এবং ঊর্ধ্বমুখীভাবে কনফিগারযোগ্য, তাই keepalive ছাড়া VM-এ OpenVPN সার্ভার প্রতি কয়েক মিনিটে ড্রপ করতে পারে, অথচ বাকি সবকিছু সুস্থ দেখায়। প্ল্যাটফর্ম যে গেটওয়ে চক্রাকারে চালায়, সেটিও একটি VNet সংযোগ Web App-এ বিচ্ছিন্ন করতে পারে, এবং সেই ব্যর্থতা ক্লায়েন্ট কনফিগারেশনে নয়, প্ল্যাটফর্মের দিকে। চিহ্ন হলো বিচ্ছিন্নতা নির্দিষ্ট বিরতি অনুসরণ করে, নাকি আপনার করা কোনো পরিবর্তন অনুসরণ করে।

তিনটি অবজেক্ট ও তাদের মান এক রেকর্ডে রাখুন: ভার্চুয়াল নেটওয়ার্কের ঠিকানার জায়গা, লোকাল নেটওয়ার্ক গেটওয়ের প্রিফিক্স তালিকা, এবং সংযোগের শেয়ার করা কী-র রেফারেন্স। সাইট-টু-সাইট PowerShell নিবন্ধ লোকাল নেটওয়ার্ক গেটওয়ের কমান্ড এবং তাদের যে ক্রমে থাকা উচিত তা নথিভুক্ত করে। স্মৃতির সঙ্গে প্রিফিক্স পরিবর্তনের তুলনা করাই হলো একটি কাজ করা টানেলকে দুবার নতুন করে তৈরি করার উপায়।

তারপর যে ক্রমে পরিবর্তন করেছেন সেই ক্রমে যাচাই করুন: লোকাল নেটওয়ার্ক গেটওয়ে নতুন প্রিফিক্স তালিকা দেখায়, সংযোগ আবার Connected-এ ফিরেছে, এবং নতুন রেঞ্জের কোনো হোস্টে ট্রাফিক পাঠালে কাউন্টার নড়ে। যদি প্রথম দুটি পাস করার সময় তৃতীয় ধাপ ব্যর্থ হয়, তবে দূরবর্তী দিকটি নতুন ট্রাফিক সিলেক্টর গ্রহণ করেনি এবং দূরবর্তী ডিভাইসের মিলিত ফেজ 2 এন্ট্রি দরকার। এটি টানেলের অন্য প্রান্তের সঙ্গে কথাবার্তা, Azure-এ আরেকটি পরিবর্তন নয়।

সম্পর্কিত নিবন্ধ