পয়েন্ট-টু-সাইট VPN-এর মাধ্যমে একটি ব্যক্তিগত Container Apps অ্যাপে পৌঁছান
একটি অভ্যন্তরীণ Container Apps পরিবেশের জন্য একটি ব্যক্তিগত প্রবেশপথ, মিলে যাওয়া হোস্টনেম এবং VPN যে রিজলভারে পৌঁছাতে পারে তা প্রয়োজন। প্রতিটি ধাপ চালান, তারপর অস্বীকৃতি যাচাই করুন।
এই রানবুকে ওয়ার্কলোড-প্রোফাইলসহ একটি Container Apps পরিবেশ বর্ণিত হয়েছে, যার একটি অভ্যন্তরীণ ভার্চুয়াল-নেটওয়ার্ক প্রবেশপথ আছে এবং যা একটি অনুমোদিত পয়েন্ট-টু-সাইট VPN-এর মাধ্যমে ল্যাপটপ থেকে পৌঁছানো যায়, অ্যাপের সরাসরি FQDN ব্যবহার করে এবং পরিবেশ-স্তরে কোনো HTTP রুট ছাড়াই। পরিবেশের প্রবেশপথটি ক্লায়েন্ট থেকে পৌঁছানো যায়, অ্যাপের ইনগ্রেস পরিধি আহ্বানকারীকে গ্রহণ করে, এবং হোস্টনেমটি ব্যক্তিগত প্রবেশপথে রিজলভ হয়। নিচের প্রতিটি ধাপ একটি যাচাইযোগ্য ফলাফল এবং এমন একটি রোলব্যাক রেখে যায় যা আপনি পরিবর্তন করেননি এমন কিছু স্পর্শ করে না। প্রদত্ত ক্রমে সেগুলো সম্পন্ন করুন, কারণ ধাপ 1-এ ভুলভাবে নেওয়া পরিধি-সিদ্ধান্তের ক্ষতিপূরণ পরবর্তী কোনো ধাপ দিতে পারে না।
DNS স্পর্শ করার আগে অভ্যন্তরীণ শব্দটির অর্থ স্থির করুন। এই পণ্যে এটি দুইটি ভিন্ন পরিধির জন্য ব্যবহৃত হয়, আর এদের অদলবদল করাই হলো সবচেয়ে সাধারণ কারণ যে একটি কাজ করা নামও এখনো কাজের কিছু ফেরত দেয় না।
ধাপ 1: পরিবেশ ও অ্যাপের পরিধি স্থির করুন
কোনো রেকর্ড পরিবর্তন করার আগে অ্যাপের ইনগ্রেস কনফিগারেশন পড়ুন:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
অভ্যন্তরীণ ইনগ্রেস পরিবেশের VNet-এর ভিতরে পরিবেশের অভ্যন্তরীণ লোড ব্যালান্সারে প্রকাশ করা হয়, তাই প্রশ্নটি ল্যাপটপ অন্য একটি কন্টেইনার অ্যাপ কি না তা নয়, বরং এটি সেই VNet-এ পৌঁছাতে পারে কি না। VNet-এ একটি রুট আছে এবং পরিবেশের ডিফল্ট ডোমেইন ব্যক্তিগত জোনের মাধ্যমে রিজলভ হয় এমন একটি VPN ক্লায়েন্ট যোগ্য আহ্বানকারী, আর বাকি ধাপগুলো ঠিক এটাই গড়ে তোলে। পাবলিক প্রবেশপথবিহীন অভ্যন্তরীণ পরিবেশ আর অভ্যন্তরীণ ইনগ্রেসযুক্ত অ্যাপ দুইটি ভিন্ন তথ্য, আর অ্যাপ স্তরে বাহ্যিক ইনগ্রেস পরিবেশকে কোনো পাবলিক দরজা দেয় না। পরিধিটি পোর্টালের পাশাপাশি টিকিটেও লিখুন, কারণ পরবর্তী প্রকৌশলী প্রথমে টিকেট পড়েন।
চালিয়ে যাওয়ার আগে কনফিগারেশন মালিকের সঙ্গে সেই পরিধি নিশ্চিত করুন, এবং গেটটি সংকীর্ণ রাখুন: যদি পরিবেশের VNet-এ কোনো রুট না থাকে, বা পরিবেশের ডিফল্ট ডোমেইন ব্যক্তিগত জোনের মাধ্যমে রিজলভ না হয়, তবে থামুন এবং আগে সেই পথ ঠিক করুন। যে আহ্বানকারী VNet-এ পৌঁছাতে বা নামটি রিজলভ করতে পারে না, তার বিকল্প পরবর্তী কোনো ধাপ দিতে পারে না।
ধাপ 2: আসল হোস্টনেম ও প্রবেশঠিকানা সংগ্রহ করুন
পরিবেশের ডিফল্ট ডোমেইন, তার স্থির ব্যক্তিগত প্রবেশঠিকানা এবং অ্যাপের কনফিগার করা FQDN লিখে রাখুন, যা পুরোনো স্ক্রিনশট বা উইকি পাতার বদলে রিসোর্স থেকেই নেওয়া:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"Container Apps-এর ব্যক্তিগত প্রবেশপথের নির্দেশিকা অ্যাপ্লিকেশনের হোস্টনেম অক্ষত রেখে পরিবেশের ডোমেইনকে তার অভ্যন্তরীণ ঠিকানার সঙ্গে মেলানোর কথা বর্ণনা করে। এখানে হাতে আপনি ঠিক এই আকারই গড়ছেন, তাই নতুন নামকরণ স্কিম উদ্ভাবনের বদলে জোনের বিষয়বস্তু এর সঙ্গে মিলিয়ে নিন।
আপনি যে ডোমেইন পড়েছেন তা অ্যাপ যে FQDN রিপোর্ট করে তার সঙ্গে না মিললে থামুন এবং এখনই সেগুলো মিলিয়ে নিন। ভুল সাফিক্সের বিপরীতে জোন গড়লে এমন হোস্টনেম তৈরি হয় যা নিখুঁতভাবে রিজলভ হয় এবং তবুও ভুল ভার্চুয়াল হোস্টে গিয়ে পড়ে।
ধাপ 3: ব্যক্তিগত জোনটি VPN-এর রিজলভার পথে রাখুন
পরিবেশের প্রকৃত ডিফল্ট ডোমেইনের জন্য সমর্থিত ব্যক্তিগত DNS জোন তৈরি করুন বা পুনরায় ব্যবহার করুন, নথিভুক্ত ওয়াইল্ডকার্ড ও ঠিকানা রেকর্ডগুলো স্থির প্রবেশপথের দিকে নির্দেশ করে। সেই জোনটি উপযুক্ত ভার্চুয়াল নেটওয়ার্কের সঙ্গে লিঙ্ক করুন, এবং লিঙ্কই যথেষ্ট ধরে নেওয়ার বদলে VPN-এর অনুমোদিত রিজলভার পথ দিয়ে ব্যক্তিগত কর্তৃত্বকে পৌঁছনোযোগ্য করুন।
একটি পয়েন্ট-টু-সাইট ক্লায়েন্টের সাধারণত সেই জোনে পৌঁছাতে ব্যক্তিগত রিজলভার ইনবাউন্ড এন্ডপয়েন্ট বা সমর্থিত DNS ফরওয়ার্ডার প্রয়োজন হয়। জোন লিঙ্ক করলে লিঙ্ক করা নেটওয়ার্কগুলোর জন্য Azure যা রিজলভ করে তা বদলে যায়; এটি প্রতিটি বাহ্যিক ল্যাপটপের পাবলিক রিজলভারকে পুনর্নির্দেশ করে না। ভিন্ন Container Apps নেটওয়ার্কিং মডেল থেকে ধার করা ব্যক্তিগত-এন্ডপয়েন্ট DNS জোন দিয়ে প্রতিস্থাপন করবেন না, কারণ রেকর্ডের নাম ও জোন সাফিক্স মিলবে না।
এই ধাপের রোলব্যাক হলো জোন লিঙ্ক বা আপনার যোগ করা রেকর্ড সরিয়ে ফেলা। কোনটি ছিল তা লিখে রাখুন, কারণ একটি লিঙ্ক বাতিল করতে শেয়ার করা জোন মুছে ফেলা দ্বিতীয় পরিবেশ নষ্ট করার একটি সুপরিচিত উপায়।
ধাপ 4: নামটি পরীক্ষা করুন, তারপর অস্বীকৃত দর্শক
হোস্টনেম ও TLS পরিচয় একসঙ্গে পরীক্ষা করুন, শুধু ঠিকানা নয়। নিয়ন্ত্রিত নাম-ম্যাপিং ডায়াগনস্টিকের জন্য হোস্টনেম অক্ষত রেখে ঠিকানাটি পিন করতে পারেন:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/হোস্টনেমটি আসল অ্যাপ FQDN দিয়ে এবং ঠিকানাটি আসল অভ্যন্তরীণ প্রবেশপথ দিয়ে প্রতিস্থাপন করুন। এটি কেবল সেই একটি অনুরোধকে প্রভাবিত করে এবং DNS প্রভিশনিং নয়। পরিচয় ব্যর্থতাকে আপাত সাফল্যে পরিণত করতে -k যোগ করবেন না, কারণ সার্টিফিকেটের অমিলই হলো সংকেত যে আপনি ভুল লিসেনারে আঘাত করছেন।
সংখ্যাসূচক ঠিকানাটি সরাসরি অনুরোধ করলে ভুল ভার্চুয়াল হোস্ট বেছে নিতে পারে বা TCP 443 উত্তর দিলেও বৈধতা ব্যর্থ হতে পারে, তাই সফল IP পরীক্ষাকে নেটওয়ার্ক সম্পর্কে প্রমাণ হিসেবে ধরুন, তার বেশি কিছু নয়। উদ্দিষ্ট ল্যাপটপ থেকে স্বাভাবিক রিজলভার পথ হলো ক্লায়েন্টের DNS ফরওয়ার্ডার বা জোনটি হোস্ট করা ব্যক্তিগত রিজলভারের ইনবাউন্ড এন্ডপয়েন্ট, আর সেখানে ব্যর্থতা মানে অনুপস্থিত রেকর্ড নয়, বরং রিজলভারে পৌঁছানোর সমস্যা। সেই পথে একই অনুরোধ সফল হয় তা নিশ্চিত করুন, তারপর নিশ্চিত করুন যে অস্বীকৃত দর্শক এখনো অস্বীকৃত।
কী রেকর্ড করবেন, আর কী রোলব্যাক করবেন
কন্টেইনারের লক্ষ্য পোর্ট এবং ক্লায়েন্টের HTTPS পোর্ট আলাদা সেটিংস। কন্টেইনারটি সেখানেই শোনে বলে তার লক্ষ্য পোর্ট VPN জুড়ে প্রকাশ করবেন না, আর পোর্ট পরীক্ষা পাস করানোর জন্য নেটওয়ার্ক নিয়ম প্রশস্ত করবেন না। দুই পরিবর্তনই ঘটনার পরেও টিকে থাকে এবং পরে সেগুলো কার দ্বারা হয়েছে তা নির্ধারণ করা কঠিন।
উদ্দিষ্ট ল্যাপটপ থেকে তার অনুমোদিত পরিচয় ও স্বাভাবিক DNS ব্যবহার করে একটি নতুন অ্যাপ্লিকেশন অপারেশন দিয়ে শেষ করুন, তারপর দেখুন যে অননুমোদিত আহ্বানকারী এখনো ব্যর্থ হয়। অ্যাপ কনফিগারেশনে থাকার সময় আরও নিশ্চিত করুন যে পরিবেশ-স্তরের কোনো HTTP রুট এই অ্যাপটিকে লক্ষ্য হিসেবে প্রকাশ করে কি না, কারণ সেই রুট হলো দ্বিতীয় দরজা যা ইনগ্রেস পরিধি বর্ণনা করে না।
পাঁচটি মান একসঙ্গে রেকর্ড করুন: পরিবেশের পরিধি, অ্যাপের ইনগ্রেস পরিধি, FQDN, ব্যক্তিগত প্রবেশঠিকানা এবং রিজলভারের মালিক। এই পাঁচটিই পুরো প্রবেশ চুক্তি বর্ণনা করে, আর এটি ডিবাগ করতে আসা পরবর্তী ব্যক্তি ঠিক এগুলোই চাইবেন।