VPN চালু হওয়ার পর ক্লাউড ফায়ারওয়াল কোন ঠিকানা দেখে
সম্পূর্ণ টানেল আপনার ডেটাবেস যে সোর্স ঠিকানা দেখে তা বদলে দেয়। অনুমোদিত তালিকা, ব্যক্তিগত পথ বা স্প্লিট টানেল সরান, ক্রেডেনশিয়াল নয়।
যে ডেটাবেস VPN সংযোগের আগে কাজ করে আর পরে ব্যর্থ হয়, সেটি খুব কমই ক্রেডেনশিয়ালের সমস্যা। ক্লাউড ফায়ারওয়াল সোর্স ঠিকানা মেলায়, আর সম্পূর্ণ টানেল সেই ঠিকানাটিকেই বদলে দেয়। আপনার ল্যাপটপ কী পাঠাচ্ছে বলে আপনি ভাবেন আর সার্ভার কী পাচ্ছে—এই ফাঁকটাই পুরো বাগ, আর এটি এক ধাপেই মাপা যায়।
সোর্স ঠিকানা কী হয়ে যায়
সম্পূর্ণ টানেলে প্রতিটি প্যাকেট VPN গেটওয়ে দিয়ে বেরোয়, তাই সার্ভার আপনার বাড়ির সংযোগের বদলে গেটওয়ের আউটবাউন্ড ঠিকানা দেখে। পথে কোনো ফরওয়ার্ড প্রক্সি থাকলে তার ঠিকানাই পৌঁছায়। দুটোই বৈধ সোর্স, আর আপনার মূল নিয়মে থাকা ঠিকানা কোনোটিই নয়।
Azure SQL-এর সার্ভার-স্তর ও ডেটাবেস-স্তরের ফায়ারওয়াল নিয়ম সেই ক্লায়েন্ট ঠিকানার সঙ্গে মেলে, যা লজিক্যাল সার্ভারে পৌঁছায়; সম্পূর্ণ টানেলের পরে সেটিই আউটবাউন্ড ঠিকানা। একটি ঠিকানা অনুমোদন করা AWS সিকিউরিটি গ্রুপও একইভাবে আচরণ করে। প্রমাণীকরণের আগেই প্যাকেটটি বাদ পড়ে, তাই যে ত্রুটি আপনি ফেরত পান সেটি অনুমতির সমস্যার বদলে নেটওয়ার্ক ব্যর্থতার মতো দেখায়। ঠিক এ কারণেই মানুষ পাসওয়ার্ড রিসেট করতে শুরু করে।
অনুমোদিত তালিকা কোথায় নির্ধারিত হয়
ব্যর্থ পথের সঙ্গে যে নিয়মটি মেলে সেটি পড়ুন, আপনি মনে করেন তৈরি করেছেন সেই নিয়মটি নয়। এর পরিধি, পোর্ট, প্রোটোকল এবং কোনো পরিচয় যাচাইয়ের আগে এটি মূল্যায়িত হয় কি না লক্ষ করুন।
তারপর স্থির করুন কোন স্তরের বৈধভাবে এই সিদ্ধান্তের মালিকানা আছে। ঠিকানা-নিয়ম উত্তর দেয় ট্রাফিক কোথা থেকে আসে। ব্যক্তিগত এন্ডপয়েন্ট উত্তর দেয় সেবাটি আদৌ ব্যক্তিগত পথে পৌঁছানো যায় কি না। স্প্লিট-টানেল ব্যতিক্রম উত্তর দেয় কোন গন্তব্যগুলো টানেল এড়িয়ে যায়। এগুলো বিনিময়যোগ্য নয়, আর টানেল বদলালে প্রতিটি ভিন্নভাবে ব্যর্থ হয়।
তিনটি সমাধান, তিনটি স্তর
নিচের প্রতিটি বিকল্প ভিন্ন কারণে প্রবাহ ঠিক করে, আর ভুলটি বেছে নিলে এমন সংযোগ তৈরি হয় যা পরের গেটওয়ে পরিবর্তন পর্যন্ত কাজ করে।
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
আউটবাউন্ড ঠিকানা যোগ করা সবচেয়ে ছোট পরিবর্তন এবং সবচেয়ে ভঙ্গুর, কারণ নতুন গেটওয়ে বা ভিন্ন অঞ্চল এটিকে নীরবে অকার্যকর করে দেয়। টানেলের সংজ্ঞার পাশে ঠিকানাটি নথিভুক্ত করুন যাতে দুটো একসঙ্গে চলে। সাময়িক বিস্তৃত পরিসর একটি রোগনির্ণয়, সমাধান নয়; এটি জায়গায় রেখে দেওয়াই অভ্যন্তরীণ সেবাগুলো উন্মুক্ত থাকার পথ।
কেন একটি পরিচালিত প্ল্যাটফর্ম টানেলে যোগ দিতে পারে না
Heroku, AppHarbor বা CloudBees-এর মতো অ্যাপ্লিকেশন প্ল্যাটফর্ম আপনার কোড এমন পরিবেশে চালায় যেখানে tun বা tap ডিভাইস নেই এবং একটি তৈরির অধিকারও নেই। তাদের ইনবাউন্ড মডেল হলো HTTP, কোনো স্বেচ্ছাচারী লিসেনিং সকেট নয়। VPN বাইনারি বহন করা একটি বিল্ডপ্যাকেরও ইন্টারফেস রাখার জায়গা থাকে না। কার্যকর প্যাটার্ন হলো ডেটাবেস যে স্ট্যাটিক আউটবাউন্ড ঠিকানা অনুমোদন করতে পারে, প্ল্যাটফর্মের দেওয়া একটি ব্যক্তিগত সংযোগ পণ্য, বা DMZ-তে HTTPS দিয়ে পৌঁছানো একটি প্রক্সি।
সেই প্রক্সি নিজস্ব প্রমাণীকরণ ও লগিংসহ একটি অ্যাক্সেস পথ। এটি প্ল্যাটফর্মকে আপনার VPN-এর সদস্য করে না, আর এভাবে বর্ণনা করলে এমন নিয়ম তৈরি হয় যা কেউ নিরীক্ষা করতে পারে না।
ব্যর্থ হওয়া ক্লায়েন্ট থেকে যাচাই করুন
আবার সংযোগ করুন এবং ক্লায়েন্টের ঠিক সেই পথটি পুনরাবৃত্তি করুন। সেবাটি যে সোর্স ঠিকানা লগ করে, ডেটাবেসের নামের জন্য ক্লায়েন্ট যে রুট বেছে নেয়, এবং প্রকৃত কোয়েরির ফলাফল—এই ক্রমে যাচাই করুন। গেটওয়ে থেকে পরীক্ষা প্রমাণ করে গেটওয়ে কাজ করে, যা কখনোই সন্দেহের বিষয় ছিল না। যদি সংযোগ এখন প্রমাণীকৃত হয় আর কোয়েরি এখনো ব্যর্থ হয়, তবে বাকি সমস্যা ডেটাবেসের অনুমতি।
টানেল বদলালেই এই নিয়মগুলো পর্যালোচনা করুন। প্রতিস্থাপিত গেটওয়ে বা নতুন আউটবাউন্ড পরিসর অ্যাপ্লিকেশন কনফিগারেশনে কোনো পরিবর্তন ছাড়াই পথটি ভেঙে দেয়।