VPN কনটেইনারের ভিতরে ওয়েব ইন্টারফেসে পৌঁছানো: পোর্টের মালিক বেছে নিন

অ্যাপে কোনো সমস্যা নেই এবং টানেলে কোনো সমস্যা নেই, তবুও ড্যাশবোর্ড লোড হয় না। যখন কোনো সার্ভিস network_mode: service:vpn দিয়ে চলে, তখন এটি VPN কনটেইনারের নেটওয়ার্ক নেমস্পেস ভাগ করে, যার অর্থ এর লিসেনার ও প্রকাশিত পোর্টগুলো সার্ভিসের নয়, বরং সেই নেমস্পেসের। সেখান থেকে তিনটি সিদ্ধান্ত আসে: অ্যাপ কোথায় বাইন্ড করবে, কোন কনটেইনার পোর্ট প্রকাশ করবে, এবং ম্যানেজমেন্ট পথ কতটা সংকীর্ণ হবে। ভুল ক্রমে করলে প্রতিটি আলাদা সেটিং সঠিক দেখায়, অথচ সমন্বয়টি কাজ করতে পারে না।

পোর্ট নেমস্পেসের মালিক কে

ভাগ করা নেমস্পেসে নির্ভরশীল সার্ভিসে একটি ports: এন্ট্রি যোগ করা কার্যকর কিছু করে না, এবং কয়েকটি নেটওয়ার্কিং অপশন ডিজাইন অনুসারেই এর জন্য অসমর্থিত। বরং যে কনটেইনার নেমস্পেসের মালিক তার উপর প্রকাশ করুন। সেই কনটেইনারই হলো যার ঠিকানা হোস্টে দেখা যায়, তাই ম্যাপিংটি প্রতি সার্ভিসে একটি নয়, বরং একটি এন্ট্রি হিসেবে পড়া যায়।

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

ম্যাপিংয়ের বাম দিকের ঠিকানাটি লক্ষ করুন। 127.0.0.1-এ বাইন্ড করলে প্রকাশিত পোর্ট হোস্টের লুপব্যাকে থাকে, যা সাধারণত একটি ম্যানেজমেন্ট ইন্টারফেস চায়। 0.0.0.0-এ বাইন্ড করলে এটি হোস্টের প্রতিটি ইন্টারফেসে উন্মুক্ত হয়, আর এটি সুবিধা নয়, ভিন্ন একটি নিরাপত্তা সিদ্ধান্ত।

অ্যাপকে নেমস্পেস যেখানে আশা করে সেখানে শুনতে দিন

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

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

অ্যাপের ভিতরের লিসেনার তালিকা বাইন্ড ঠিকানা সম্পর্কে সত্য বলে, আর docker port বলে মালিক আসলে কী প্রকাশ করেছে। প্রথমটি যদি 127.0.0.1 দেখায় আর দ্বিতীয়টি হোস্ট ম্যাপিং দেখায়, তবে VPN কনফিগারেশন স্পর্শ না করেই আপনি অমিলটি খুঁজে পেয়েছেন।

ম্যানেজমেন্ট পথ কীভাবে ঢুকবে তা বেছে নিন

তিনটি যুক্তিসঙ্গত ব্যবস্থা আছে। VPN কনটেইনারে প্রকাশ করুন এবং হোস্ট বা লোকাল নেটওয়ার্ক থেকে সেখানে পৌঁছান। নেমস্পেসের সামনে একটি রিভার্স প্রক্সি রাখুন এবং প্রক্সিকে একমাত্র উন্মুক্ত পোর্ট দিন। অথবা ড্যাশবোর্ড কেবল নেমস্পেসের ভিতর থেকে exec সেশন বা SSH টানেলের মাধ্যমে পৌঁছানোর উপযোগী রাখুন, যা সবচেয়ে কম উন্মোচন এবং সবচেয়ে কম সুবিধা।

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

সবকিছু না খুলে ম্যানেজমেন্ট পোর্ট খুলুন

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

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

ম্যানেজমেন্ট ডিভাইস থেকে যাচাই করুন, পরে আবার যাচাই করুন

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

স্ট্যাক পুনরায় তৈরি করার পর আবার পরীক্ষা করুন। পরিবর্তিত নেটওয়ার্ক মালিক যে নেমস্পেসে অ্যাপ সংযুক্ত হয় তা বদলে দেয়, আর আপডেটের আগে কাজ করা URL পরে কোনো কিছুর দিকেই নির্দেশ নাও করতে পারে। প্রকাশিত ম্যাপিং ও বাইন্ড ঠিকানা লিখে রাখুন যাতে পরবর্তী পুনর্নির্মাণ পুনরায় তদন্ত নয়, বরং দুই মিনিটের যাচাই হয়।