একটি ক্লাউড সেবার জন্য নেটিভ TLS, SSH ফরওয়ার্ড বা VPN

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

নেটওয়ার্ক নয়, সেবা দিয়ে শুরু করুন

প্রসেস থেকে বাইরের দিকে হাঁটুন। এটি কোন প্রোটোকল বলে, ক্লায়েন্ট কোন নাম যাচাই করবে, এবং কে আদৌ সংযোগ খুলতে পারে? এই তিনটি উত্তর যেকোনো তুলনা সারণির চেয়ে দ্রুত বিকল্প বাদ দেয়, এবং সেবার নিজস্ব কনফিগারেশন সাধারণত কয়েক মিনিটেই সেগুলির উত্তর দেয়।

এমন একটি ছোট অভ্যন্তরীণ API নিন যা ইতিমধ্যে 8443 পোর্টে HTTPS পরিবেশন করে, api.internal.example-এর জন্য একটি সার্টিফিকেট সহ। হোস্টে ss -ltnp দেখায় এটি কীসের সাথে বাঁধা, আর openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example দেখায় সার্টিফিকেটটি ক্লায়েন্টের প্রকৃত ব্যবহার করা নামের জন্য বৈধ কি না। দুটিই সুস্থ থাকলে সেবা নিজের প্রবাহ রক্ষা করতে পারে এবং কেবল পৌঁছানোর কাজ বাকি থাকে। এটি নেটওয়ার্ক তৈরি করার চেয়ে অনেক ছোট সমস্যা।

ধাপ 1: সেবা কি নিজেকে রক্ষা করে?

এটি যখন মানায় তখন নেওয়ার বিকল্প, এবং দলগুলি যতটা ধরে নেয় তার চেয়ে বেশি মানায়। সেবার এনক্রিপশন ক্লায়েন্ট ও সার্ভারের মধ্যে পুরো পথ ঢাকে, মাঝখানের প্রতিটি হপ সহ, যা মাঝখান দিয়ে যাওয়া কোনো টানেল উন্নত করে না। প্রত্যাশিত নাম ও বিশ্বাস স্পষ্টভাবে কনফিগার করুন, ক্লায়েন্টের ডিফল্ট স্টোরে যা আছে তার উপর নির্ভর না করে।

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

ধাপ 2: একটি TCP পোর্টই কি পুরো প্রয়োজন?

যখন প্রয়োজন সত্যিই একটি TCP পোর্ট, ফরওয়ার্ডই সবচেয়ে ছোট কাজ করা জিনিস। একটি SSH লোকাল ফরওয়ার্ড সেই পোর্টটি ইতিমধ্যে বিদ্যমান প্রমাণিত সংযোগের মধ্য দিয়ে নিয়ে যায়।

আকৃতিটি ssh -N -L 8443:127.0.0.1:8443 [email protected], এবং গুরুত্বপূর্ণ বিবরণটি লক্ষ্য ঠিকানা: 127.0.0.1 দূরবর্তী দিকে সমাধান হয়, তাই সেবার সংযোগ আপনার ল্যাপটপ নয়, বাস্টিয়ন থেকে খোলে। লোকাল লিসেনারকে -L 127.0.0.1:8443:... হিসেবে সংকীর্ণভাবে বাঁধুন যাতে দুর্ঘটনাক্রমে সেবাটি নিজের লোকাল নেটওয়ার্কে প্রকাশ না করেন। সার্ভারের দিকে ক্লায়েন্টের ভালো আচরণে বিশ্বাস না করে অ্যাকাউন্টটি কী ফরওয়ার্ড করতে পারবে তা সীমিত করুন। PermitOpen, AllowTcpForwarding local এবং GatewayPorts no ডিফল্ট — এই তিনটি সেটিং সাধারণ রিলেকে নির্দিষ্ট চ্যানেলে পরিণত করে।

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

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

ধাপ 3: রাউটিংই কি আসল প্রয়োজন?

সেই তালিকাটি ক্ষুদ্রতম বিকল্পের সৎ মূল্য, এবং সেজন্যই দলগুলি শেষে ভুলে যাওয়া কয়েকটি ব্যাকগ্রাউন্ড কমান্ডকে পরিচালিত কিছু দিয়ে বদলে দেয়। প্রতিস্থাপনটি স্বয়ংক্রিয়ভাবে VPN নয়। প্রয়োজন যদি এখনও একটি TCP পোর্ট হয়, নথিভুক্ত মালিকসহ তদারকিকৃত ফরওয়ার্ড ওভারলের চেয়ে সস্তায় চলে এবং আপনি দেখতে পারেন এমনভাবে ব্যর্থ হয়। সৌন্দর্য মাপার আগে পরিচালন মালিকানা মাপুন।

রাউটিংই প্রয়োজন হলে রাউটিংই সঠিক উত্তর হয়ে ওঠে। সাধারণ IP সংযোগ দরকার এমন কয়েকটি অ্যাপ্লিকেশন, TCP ফরওয়ার্ড বহন করতে পারে না এমন প্রোটোকল, বা হোস্টের মধ্যে সরে যাওয়া সেবা — সবই একই দিকে ইঙ্গিত করে।

ওভারলে অংশগ্রহণকারীদের একটি ঠিকানা ও রুট দেয়, তারপর আসল কাজ শুরু হয়: অ-ওভারল্যাপিং রেঞ্জ, রুট মালিকানা, DNS, নথিভুক্তি, বাতিলকরণ এবং সহকর্মী অদৃশ্য হলে কী হয়। এর কিছুই ঠিকানার সাথে আসে না। ওভারলে-এ গৃহীত সহকর্মীও গন্তব্যে প্রতিটি কাজের জন্য স্বয়ংক্রিয়ভাবে অনুমোদিত নয়, তাই সেবা-স্তরের প্রমাণীকরণ থাকে।

পরে আপনার যা আছে

আপনি যে রেকর্ড রেখে যান তাতে দুটি জিনিস থাকে। প্রথমটি হলো যে পরিচয় ক্লায়েন্টের যাচাই করার কথা, কারণ কোনো কিছু কাজ করানোর জন্য নাম যাচাই শিথিল হলেই এই প্রতিটি সীমা নীরবে অবনতি হয়। দ্বিতীয়টি হলো অপসারণের ধাপ: অ্যাক্সেস শেষ হলে কোন কী, কোন নিয়ম বা কোন রুট অদৃশ্য হয়, এবং কে তা করে।

এই পদচারণা যেখানে শুরু হয়েছিল, সেবার কাছেই শেষ হয়। প্রকৃত ট্রাফিক ঢাকে এবং আপনি যাদের যাচাই করতে চেয়েছিলেন তাদের যাচাই করে এমন সীমা বেছে নিন, তারপর লিখুন কীভাবে অ্যাক্সেস হালনাগাদ, পর্যবেক্ষণ ও অপসারিত হয়। OpenSSH রেফারেন্স সংকীর্ণ চুক্তি দেওয়ার আগে ফরওয়ার্ডিং বিকল্পগুলি নিশ্চিত করার জায়গা। এক বাক্যে অপসারণের ধাপ বর্ণনা করতে না পারলে সীমাটি সমস্যার চেয়ে বড়।