কীভাবে একটি webpack ডেভ সার্ভার VPN ঠিকানায় চালাবেন

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

তিনটি প্রশ্ন উত্তর নির্ধারণ করে: কে সংযোগ করে, তারা কোন ঠিকানায় পৌঁছাতে পারে, এবং তাদের জন্য লাইভ রিলোড কাজ করতে হবে কি না।

কনফিগার ফাইল দিয়ে নয়, সকেট দিয়ে শুরু করুন

চলমান প্রক্রিয়াটি আসলে কোন ঠিকানায় বাঁধা পড়েছে তা যে নেটওয়ার্ক প্রসঙ্গে এটি চালু হয়েছিল সেখানেই পড়ুন, কারণ একটি কনটেইনার বা নেমস্পেস এমন সকেটের মালিক হতে পারে যা হোস্ট শেল দেখতে পায় না। লিসেন কলামটি প্রথম প্রশ্নের উত্তর দেয়: শুধু লোকাল পথ, একটি নির্দিষ্ট ইন্টারফেস, নাকি প্রতিটি ইন্টারফেস।

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

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

রুট বা ফায়ারওয়াল নিয়মে হাত দেওয়ার আগে সেই পর্যবেক্ষণের সাথে মিলিয়ে নিন। প্রক্রিয়াটি যদি ভুল ঠিকানায় শুনছে, তবে কোনো পলিসি রাউটিংই ক্লায়েন্টকে সেখানে পৌঁছাতে পারবে না।

কে পৌঁছাবে তার ভিত্তিতে বাইন্ড ঠিকানা বেছে নিন

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

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

তারপরে ঠিকানাটি আপনার লঞ্চার আসলে যে ফরম্যাটে পড়ে সেভাবে সেট করুন। একটি কনফিগারেশন ফাইল এবং একটি স্ক্রিপ্ট যা সার্ভারটি প্রোগ্রাম্যাটিকভাবে তৈরি করে, একই অপশন ব্যবহার করে না:

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

সেই অংশের ঠিকানাটি উদাহরণমূলক এবং হোস্টের মালিকানাধীন VPN ঠিকানাকে বোঝায়। যদি প্রকল্পটি সার্ভারটি new WebpackDevServer(options, compiler), দিয়ে তৈরি করে, তবে অপশনগুলো পরিবর্তে কনস্ট্রাক্টর আর্গুমেন্টের মাধ্যমে দিন, কারণ webpack কনফিগারেশনের আলাদা devServer প্রপার্টিটি সেই পথে বিবেচিত হয় না। কনফিগারেশন ফাইল এবং Node API-এর মধ্যে এই পার্থক্যটি তাদের ধরে যারা স্নিপেট এমন প্রকল্পে কপি করে যা তা কখনও পড়ে না। dev-server ডকুমেন্টেশন দুটি লঞ্চ স্টাইলকে আলাদা করে এবং ব্যবহৃত সংস্করণের সাথে মিলিয়ে দেখার রেফারেন্স।

আপনি যে নামগুলো অনুমোদন করেন তার সাথে হোস্টনেম যাচাই মিলান

হোস্টনেম যাচাই থাকে যাতে আক্রমণকারীর নিয়ন্ত্রিত নাম থেকে পরিবেশিত একটি পৃষ্ঠা ব্রাউজারের মাধ্যমে আপনার ডেভেলপমেন্ট সার্ভারের সাথে কথা বলতে না পারে। এটি allowedHosts: "all" দিয়ে নিষ্ক্রিয় করা সেই সুরক্ষা সরিয়ে দেয়, এবং সুবিধাটি অভ্যন্তরীণ পরিষেবায় পৌঁছাতে পারে এমন মেশিনে বিরলভাবে মূল্যবান। ব্রাউজার কোন নাম পাঠাবে তা জানলে যাচাই সঠিকভাবে পূরণ করা সস্তা।

আপনি যে সঠিক নামগুলো ব্যবহার করবেন সেগুলো তালিকাভুক্ত করুন, টানেল ঠিকানায় সমাধান হওয়া ব্যক্তিগত নামসহ। যদি ক্লায়েন্ট একটি নামকে আপনি যে ঠিকানায় বাঁধেছেন তার থেকে ভিন্ন ঠিকানায় সমাধান করে, তবে আপনার নাম সমাধানের সমস্যা, সার্ভার কনফিগারেশনের সমস্যা নয়, এবং অনুমোদিত তালিকায় নাম যোগ করলে তা ঠিক হবে না। সমাধানটি সার্ভার থেকে নয়, ক্লায়েন্ট থেকে নিশ্চিত করুন।

তিনটি নিয়ন্ত্রণ আলাদা করে মনে রাখুন: বাইন্ড ঠিকানা নির্ধারণ করে কোন ইন্টারফেস সংযোগ গ্রহণ করবে, অনুমোদিত তালিকা নির্ধারণ করে কোন Host হেডার গ্রহণ করা হবে, এবং প্রমাণীকরণ নির্ধারণ করে কাকে ঢুকতে দেওয়া হবে। কেবল তৃতীয়টিই অ্যাক্সেস নিয়ন্ত্রণ, এবং ডেভেলপমেন্ট সার্ভারে সাধারণত কোনোটিই থাকে না। টানেল ঠিকানাও প্রমাণীকরণ পদ্ধতি নয়, কারণ যে কেউ সেখানে রাউট করতে পারে সে ইতিমধ্যে আপনি যে সীমার উপর নির্ভর করছিলেন তার ভিতরেই আছে।

পৃষ্ঠা এবং লাইভ-রিলোড সকেট একসাথে যাচাই করুন

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

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

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

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