ExpressRoute প্লাস VPN: কোন ব্যর্থতা-ডোমেইনগুলো আপনি কভার করেন?
দ্বিতীয় একটি IPsec টানেল একটি প্রান্তবিন্দু কভার করে, তার নিচের সার্কিট নয়। প্রতিটি ব্যর্থতা-ডোমেইন ম্যাপ করুন, তারপর ঠিক করুন আনএনক্রিপ্টেড ফলব্যাক অনুমোদিত কি না।
ExpressRoute প্রাইভেট পিয়ারিংয়ের উপর চলমান একটি IPsec টানেল এমন একটি ট্রান্সপোর্টে এনক্রিপশন যোগ করে যা ইতিমধ্যেই বিদ্যমান। দ্বিতীয় একটি টানেল প্রান্তবিন্দুর প্রাপ্যতা বাড়ায়, আর দুটিরই নিচের ক্যারিয়ার পথের জন্য এটি কিছুই করে না। এই পার্থক্যটি হারানো সহজ যখন ড্যাশবোর্ড দুটি সবুজ টানেল দেখায় আর ডিজাইন পর্যালোচনা অন্য একটি প্রশ্ন করে: এই সংযোগকে কোন কোন ব্যর্থতা টিকে থাকতে হবে? আগে তার উত্তর দিন, তারপর টানেল গুনুন, কারণ সবুজ সূচকগুলোর সংখ্যা এনক্রিপশন স্তরের একটি বৈশিষ্ট্য আর ব্যর্থতা-ডোমেইনের সংখ্যা সমগ্র পথের একটি বৈশিষ্ট্য।
সবুজ টানেল দিয়ে নয়, ব্যর্থতা দিয়ে শুরু করুন
কিছু আঁকার আগে চারটি সারি লিখুন: একটি VPN প্রান্তবিন্দু বা পিয়ার ইনস্ট্যান্স ব্যর্থ হওয়া, একটি স্থানীয় রাউটার বা ফার্স্ট-মাইল সংযোগ ব্যর্থ হওয়া, শেয়ার করা ExpressRoute পথ ব্যর্থ হওয়া, এবং প্রাইভেট পিয়ারিং তখনও ট্রাফিক বহন করার সময় IPsec অনুপলব্ধ হয়ে যাওয়া। প্রতিটি সারি বলে ডিজাইনকে কী সংরক্ষণ করতে হবে, আর প্রতিটির উত্তর দেয় ভিন্ন একটি প্রক্রিয়া।
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft ExpressRoute প্রাইভেট পিয়ারিংয়ের উপর প্রাইভেট-IP সাইট-টু-সাইট VPN এবং ইন্টারনেট-ভিত্তিক সাইট-টু-সাইট সংযোগের সঙ্গে সমর্থিত সহাবস্থান নথিভুক্ত করে। সেই সহাবস্থান একটি ভিন্ন আন্ডারলে ডিজাইন, এবং আপনি আরেকটি প্রাইভেট টানেল প্রান্তবিন্দু যোগ করলেই তা দেখা যায় না।
ব্যর্থতা-ডোমেইন 1: VPN প্রান্তবিন্দু
একটি গেটওয়েতে দুটি টানেল সাধারণত active-active জোড়া যা একই Azure-পাশের রিসোর্সে শেষ হয়। তারা একটি টানেল বা ইনস্ট্যান্সের সমস্যা থেকে রক্ষা করে, আর সেই রিসোর্স অনুপলব্ধ, পুনঃকনফিগার বা ধারণক্ষমতার বাইরে হয়ে যাওয়া থেকে রক্ষা করে না। প্রান্তবিন্দু-অতিরিক্ততা মানে নিজস্ব পথ ও নিজস্ব কনফিগারেশনসহ একটি দ্বিতীয় সমর্থিত প্রান্তবিন্দু, সঙ্গে একটি রুট যা তাতে পৌঁছাতে পারে।
ডায়াগ্রাম যা বলে তার বদলে আপনি আসলে কী মোতায়েন করেছেন তা যাচাই করুন, কারণ পোর্টাল এই রিসোর্সগুলো এমনভাবে গোষ্ঠীবদ্ধ করে যা তাদের সম্পর্ক লুকায়:
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'যদি দুটি টানেলই একটি পাবলিক IP-সহ একটি গেটওয়ের দিকে নির্দেশ করে, তবে আপনার কাছে একটি নির্দিষ্ট ও সীমিত ধরনের প্রান্তবিন্দু-অতিরিক্ততা আছে। এটি হয়তো ঠিক তাই যা প্রয়োজনীয়তা চায়, এবং রিডানড্যান্ট সংযোগ হিসেবে বর্ণনা না করে ঠিক সেভাবেই বলা উচিত।
ব্যর্থতা-ডোমেইন 2: স্থানীয় পথ ও ক্যারিয়ার
এনক্রিপশনের নিচে রয়েছে একটি ভৌত ও বাণিজ্যিক বাস্তবতা: একটি গ্রাহক-প্রান্ত ডিভাইস, একটি ক্রস-কানেক্ট, একটি প্রোভাইডার নেটওয়ার্ক এবং একটি পিয়ারিং লোকেশন। ExpressRoute প্রাপ্যতা নির্দেশিকা স্পষ্টভাবে বলে যে এন্ড-টু-এন্ড অতিরিক্ততার মধ্যে গ্রাহক ও সেবা-প্রদানকারীর অংশগুলো অন্তর্ভুক্ত, শুধু Microsoft-এর দিক নয়। দুটি লজিক্যাল পথ যদি একটি রাউটার, একটি পাওয়ার ফিড বা একটি ফার্স্ট-মাইল সংযোগ ভাগ করে, তবে তারা এখনও সেই নির্ভরতাই ভাগ করে।
এখানেই একটি ডিজাইন সাধারণত সৎ পর্যালোচনায় ব্যর্থ হয়। একই প্রদানকারীর দুটি সার্কিট, একই ভবনে শেষ হওয়া, একই ক্রয়াদেশের সরঞ্জামে, দুটি ব্যর্থতা-ডোমেইন নয়। তারা দুইটি ইনভয়েসসহ একটি ব্যর্থতা-ডোমেইন।
ক্যারিয়ারকে লিখিতভাবে প্রশ্ন করুন: এই পথগুলোর কোনটি কোথায় বিচ্ছিন্ন হয়, এবং শেয়ার করা অংশ ব্যর্থ হলে নথিভুক্ত আচরণ কী? ডিজাইন কলের সময় মৌখিক আশ্বাস সেই আউটেজে টেকে না যার জন্য আপনি ডিজাইন করছেন।
ব্যর্থতা-ডোমেইন 3: যে রুট IPsec ছাড়া টেকে
প্রাইভেট পিয়ারিং ও IPsec একই অ্যাপ্লিকেশন প্রিফিক্সে প্রতিদ্বন্দ্বী রুট দিতে পারে. সুরক্ষিত রুটটি হারিয়ে গেলে, টিকে থাকা সরাসরি ExpressRoute রুটটি হয়তো এখনও ব্যবহারযোগ্য, সেই এনক্রিপশন স্তর ছাড়া যা টানেলটি দিচ্ছিল। এটি গ্রহণযোগ্য কি না তা একটি নীতি-সিদ্ধান্ত, এবং এটিই সেই সিদ্ধান্ত যা সবচেয়ে বেশি অন্তর্নিহিত রাখা হয়।
এনক্রিপশনের প্রয়োজনীয়তা ও প্রাপ্যতার প্রয়োজনীয়তা এখানে সত্যিই সংঘর্ষে যেতে পারে। „যেকোনো টিকে থাকা রুটই সফলতা“ একটি প্রাপ্যতা-বিবৃতি যা এনক্রিপশনের প্রশ্নের উত্তর চুপচাপ „না“ দিয়ে দেয়। কোনটি জেতে, কোন প্রিফিক্সের জন্য এবং কে অনুমোদন করেছে তা লিখে রাখুন।
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o tableশেখা রুটগুলোর সঙ্গে আপনার প্রত্যাশিত প্রিফিক্সগুলো তুলনা করুন। ছোট একটি প্রশাসনিক কাজভার বহনকারী ফলব্যাক সেই কাজের জন্য পুরোপুরি যথেষ্ট হতে পারে, অথচ প্রোডাকশন চাহিদার প্রয়োজনীয় ধারণক্ষমতার ধারেকাছে নয়, তাই রুটের পাশে ধারণক্ষমতার অনুমানটি লিখে রাখুন।
একটি রায় নয়, তিনটি আলাদা সারি লিখুন
প্রান্তবিন্দু-অতিরিক্ততা, ট্রান্সপোর্ট-অতিরিক্ততা এবং দুর্যোগ পুনরুদ্ধারকে ডিজাইন রেকর্ডে আলাদা এন্ট্রি হিসেবে রাখুন, প্রতিটির নিজস্ব প্রক্রিয়া, নিজস্ব যাচাই ও নিজস্ব মালিকসহ। কোনো ঘটনা-পর্যালোচনা যখন জিজ্ঞেস করে সংযোগটি কেন একটি গেটওয়ে রিস্টার্ট টিকে গেল কিন্তু ফাইবার কাট টিকল না, তখন তিনটি সারি এক বাক্যে উত্তর দেয়; একটি „রিডানড্যান্ট“ চেকবক্স তা পারে না।
তারপর যে সারিগুলো সস্তায় পরীক্ষা করা যায় সেগুলো পরীক্ষা করুন। একটি টানেল ব্যর্থ করুন এবং নিশ্চিত করুন ট্রাফিক সরে যায় ও পুনরায় এনক্রিপ্ট হয়। একটি রুট প্রত্যাহার করুন এবং নিশ্চিত করুন টিকে থাকা পথটি আপনার অভীষ্টটিই, তারপর নিশ্চিত করুন এটি এখনও এনক্রিপ্টেড কি না। যে ব্যর্থতাগুলো আপনি অনুকরণ করতে পারেননি সেগুলো নথিভুক্ত করুন, কারণ অপরীক্ষিত সারি একটি অনুমান এবং সেটিকে তেমনই চিহ্নিত করা উচিত।
উপযোগী ফলাফল একটি সংক্ষিপ্ত টেবিল আর প্রতি সারির জন্য একটি বাক্য। কোনো সারির প্রক্রিয়া না থাকলে সেটিই হলো অনুসন্ধান, এবং ডিজাইন পর্যালোচনায় তা আবিষ্কার করা ক্যারিয়ার আউটেজের সময় আবিষ্কারের চেয়ে অনেক সস্তা, যে আউটেজ দুটি টানেলই কখনো টিকত না।