প্রাইভেট এন্ডপয়েন্ট, একই সার্ভার নাম: Azure SQL সংযোগ স্ট্রিং
Private Link পরিবর্তন করে সার্ভার নামটি কোথায় রিজলভ হয়, নামটি নিজে নয়। লজিক্যাল হোস্টনেম রাখুন এবং VPN ক্লায়েন্টদের প্রাইভেট DNS উত্তর দিন।
Private Link পরিবর্তন করে একটি সংযোগ কোথায় পৌঁছায়, সংযোগটির নাম কী তা নয়। Azure SQL Database-এর জন্য সেই পার্থক্যই পুরো ডিজাইন: লজিক্যাল সার্ভার তার নাম ধরে রাখে, এবং প্রাইভেট এন্ডপয়েন্ট এমন একটি নেটওয়ার্ক এন্ট্রি দেয় যা নামটি রিজলভ করে। নামটিকে IP ঠিকানায় বদলানোই একমাত্র পরিবর্তন যা একসঙ্গে TLS, ক্রেডেনশিয়াল এবং টুলিং ভেঙে দেয়। দুটি সংযোগ স্ট্রিং সমতুল্য দেখাতে পারে এবং সম্পূর্ণ ভিন্নভাবে আচরণ করতে পারে।
orders-db.database.windows.net রাখুন এবং ক্লায়েন্টকে এর জন্য একটি প্রাইভেট উত্তর দিন।
নাম ও ঠিকানার কাজ আলাদা
নামটি SQL পরিষেবা চিহ্নিত করে, সার্টিফিকেট ও লগইন ঠিক এটাই আশা করে। প্রাইভেট ঠিকানা সংযুক্ত ভার্চুয়াল নেটওয়ার্কের ভিতরে একটি নেটওয়ার্ক এন্ট্রি দেয়। একটিকে অন্যটির সঙ্গে গুলিয়ে ফেললে এমন সংযোগ তৈরি হয় যা কিছুতে পৌঁছায় কিন্তু কোনো কিছুর বিরুদ্ধে প্রমাণীকরণ করে না।
Azure SQL-এর জন্য Microsoft-এর নির্দেশনা ক্লায়েন্টদের কাছ থেকে স্বাভাবিক সার্ভার নাম দাবি করে। সরাসরি IP, এবং সমভাবে privatelink উপসর্গযুক্ত নাম, বিনিময়যোগ্য লগইন লক্ষ্য নয়। যে টুল IP গ্রহণ করে সেগুলি তা গ্রহণ করবে এবং পরে TLS-এ বা প্রমাণীকরণে ব্যর্থ হবে, যা আসল ভুলটি লুকায়। সেই ব্যর্থতাগুলি ক্রেডেনশিয়াল সমস্যার মতো পড়া যায় যতক্ষণ না ত্রুটিতে হোস্টনেম দেখেন।
প্রাইভেট জোন আসলে কী বদলায়
প্রাইভেট DNS জোন privatelink নেমস্পেসের ভিতরে সার্ভারের জন্য একটি ঠিকানা রেকর্ড করে, এবং জোনটি সেই ভার্চুয়াল নেটওয়ার্কের সঙ্গে যুক্ত থাকে যা এটি ব্যবহার করবে। রিজলিউশন সরে যায়; সংযোগ স্ট্রিং সরে না। নিচের আকৃতিটি একটি উদাহরণ, পাবলিক জোনে পেস্ট করার রেকর্ড নয়।
Application name: orders-db.database.windows.net
Private DNS zone: privatelink.database.windows.net
Resolved private entry: the approved private endpoint address
সেই রেকর্ড এবং তার জোন লিংককে অবকাঠামো হিসেবে মালিক ও পর্যালোচনার তারিখসহ রক্ষণাবেক্ষণ করুন।
একই উৎস ও ভিন্ন উত্তরের দুটি জোন স্বাভাবিক চূড়ান্ত অবস্থা, দ্বন্দ্ব নয়। পাবলিক ক্লায়েন্টরা পাবলিক উত্তর ধরে রাখে, আর প্রাইভেট ক্লায়েন্টরা এন্ডপয়েন্ট ঠিকানা পায়। যে ব্যর্থতার ধরনটি খেয়াল রাখতে হবে তা হলো প্রাইভেট দৃশ্যের আংশিক বিস্তার, যেখানে একটি সাবনেট প্রাইভেটভাবে রিজলভ করে আর অন্যটি নিঃশব্দে করে না।
Azure-এর বাইরের ক্লায়েন্টদের সেই জোনে ঢোকার পথ দরকার
একটি VPN ক্লায়েন্ট Azure-এর রিজলভারের বাইরে বসে, তাই প্রাইভেট জোনটি হাইব্রিড পথ থেকে পৌঁছানোযোগ্য হতে হবে। একটি Azure DNS ফরওয়ার্ডার বা Azure DNS Private Resolver সেই নেটওয়ার্ক দিয়ে আসা কোয়েরিগুলি পরিবেশন করতে পারে। Microsoft-এর নির্দেশনা হলো সংশ্লিষ্ট পাবলিক সার্ভিস জোনটি সেই ব্যবস্থার মাধ্যমে ফরওয়ার্ড করা, বরং ধরে নেওয়া নয় যে ক্লায়েন্টরা সরাসরি privatelink নামটি কোয়েরি করে। যে ক্লায়েন্টরা প্রাইভেট উত্তর রিজলভ করতে পারে না তারা অভিযোগ না করেই পাবলিক উত্তরে ফিরে যায়।
ফরওয়ার্ডিং সুযোগ ইচ্ছাকৃত রাখুন, কারণ ব্যবহৃত পাবলিক জোন প্রতিস্থাপন করলে এমন নাম ভাঙে যা প্রতিস্থাপনে নেই।
পরিচয় স্থির রেখে এমন ক্রমে প্রস্তুত করুন
ধাপগুলির আলাদা মালিক আছে: এন্ডপয়েন্ট তৈরি ও অনুমোদন করুন, VPN রুট দিন, প্রাইভেট DNS সংযুক্ত করুন, তারপর ক্লায়েন্টকে তার স্বাভাবিক সার্ভার নাম দিয়ে কনফিগার করুন। রুটের আগে DNS করলে টাইমআউট হয় যা DNS ব্যর্থতার মতো দেখায়। ক্লায়েন্টকে শেষে করলে একবারে একটি চলক চলাচলে থাকে। প্রতিটি ধাপের একটি পর্যবেক্ষণযোগ্য ফল আছে, তাই কোনোটিকেই অনুমান করে পরীক্ষা করতে হয় না।
সংযুক্ত VPN আইকন নিজে থেকে প্রাইভেট গন্তব্য বাছাই করে না।
একটি প্রাইভেট এন্ডপয়েন্ট যা বন্ধ করে না
প্রাইভেট এন্ডপয়েন্ট তৈরি করা লজিক্যাল সার্ভারে পাবলিক অ্যাক্সেস স্বয়ংক্রিয়ভাবে বন্ধ করে না। এটি আলাদা ডিপ্লয়মেন্ট সিদ্ধান্ত, এবং এটি আসে উদ্দিষ্ট প্রাইভেট ক্লায়েন্টরা কাজ করছে নিশ্চিত হওয়ার পরে। একটি পুনরুদ্ধার পথ রাখুন এবং যে অ্যাপ্লিকেশনগুলি এখনও পাবলিক এন্ট্রি ব্যবহার করে তাদের হিসাব রাখুন। পাবলিক অ্যাক্সেস আগে বন্ধ করাই হলো একটি চালু পরিষেবাকে পরিচ্ছন্ন অডিট ট্রেইলসহ বিভ্রাটে পরিণত করার উপায়।
সার্ভারটি কোন সংযোগ নীতি ব্যবহার করে তাও যাচাই করুন।
Redirect প্রাথমিক গেটওয়ে সংযোগের পরে ক্লায়েন্টকে নোডের একটি পোর্টে পাঠায়, যা বদলে দেয় ক্লায়েন্ট নেটওয়ার্ককে কী অনুমোদন করতে হবে। Proxy ট্র্যাফিক গেটওয়েতে রাখে। একটি পোর্টে সফল TCP হ্যান্ডশেক পুরো লগইন কর্মপ্রবাহ নয়।
এটি Azure SQL Database, SQL Managed Instance নয়, যার নিজস্ব সংযোগ মডেল আছে এবং সমতুল্য প্রাইভেট এন্ডপয়েন্ট গল্প নেই। উভয় ক্ষেত্রেই তিনটি জিনিস আলাদাভাবে লেবেল করুন: নাম, নেটওয়ার্ক এন্ট্রি এবং ক্রেডেনশিয়াল। সংযোগ কোথায় যায় তা বদলালে ক্লায়েন্ট কোন পরিষেবার সঙ্গে কথা বলছে বলে ভাবে তা কখনও বদলানো উচিত নয়।