Minecraft VPN-এর মাধ্যমে: সার্ভার তালিকায় কোন ঠিকানাটি যায়?
VPN এন্ডপয়েন্ট টানেল তৈরি করে; খেলার জন্য হোস্টের ব্যক্তিগত ঠিকানা ও পোর্ট দরকার। ভূমিকাগুলোকে ঠিকানার সঙ্গে মিলিয়ে নিন, তারপর লিসেনার, রুট ও হোস্ট নিয়ম যাচাই করুন।
Minecraft-এর সার্ভার তালিকায় VPN এন্ডপয়েন্ট টাইপ করা যুক্তিসঙ্গত মনে হয় এবং প্রতিবার ব্যর্থ হয়, কারণ সেই ঠিকানাটি টানেল শেষ করে, খেলা হোস্ট করে না। একই VPN-এ যুক্ত খেলোয়াড়ের ইতিমধ্যে খেলার হোস্টে পথ আছে, তাই এন্ট্রিতে হোস্ট এবং খেলা যে পোর্টে শোনে সেটি উল্লেখ করতে হবে। এই দুটি ঠিক করলেই বাকি সমস্যাটি সাধারণ সেবা-প্রাপ্যতা, যা প্রথমে যতটা মনে হয় তার চেয়ে অনেক ছোট চেকলিস্ট।
দুটি ঠিকানা, দুটি কাজ
একটি ঠিকানা পাবলিক অবকাঠামো: পিয়ারদের মধ্যে এনক্রিপ্টেড প্যাকেট বহনকারী ট্রান্সপোর্ট এন্ডপয়েন্ট। অন্যটি ডেডিকেটেড সার্ভার চালানো মেশিনের ব্যক্তিগত ঠিকানা। এগুলো বিনিময়যোগ্য নয়, এবং একটির বদলে অন্যটি বসালে সংযোগ প্রত্যাখ্যান বা টাইমআউট হয় যা ফায়ারওয়াল সমস্যার মতো দেখায়।
| Role | Address | Where it belongs |
|---|---|---|
| Public transport endpoint | 203.0.113.40 | VPN client configuration, never the game |
| Game host on the VPN | 10.60.0.20 | Server address field, with the port |
| Player peer | 10.60.0.30 | Assigned by the tunnel, nothing to type |
ডিফল্ট পোর্টে খেলোয়াড় 10.60.0.20:25565 টাইপ করে, আর কিছু নয়। Mojang-এর Java সার্ভার ডাউনলোড পেজে 25565 ডিফল্ট হিসেবে উল্লেখ আছে, এবং পোর্ট বদলানো সার্ভার অপারেটরকে পুরোনো টিউটোরিয়াল থেকে সন্দেহ করার বদলে বিশ্বাস করতে হবে।
সেই ঠিকানাকে সত্যিকারের সেবা বানান
পৌঁছানো যায় এমন ঠিকানা প্রয়োজনীয়, যথেষ্ট নয়। ডেডিকেটেড সার্ভার চালু থাকতে হবে, খেলোয়াড়ের ক্লায়েন্ট যে সংস্করণ চালায় তার সঙ্গে সামঞ্জস্যপূর্ণ হতে হবে, এবং টানেল যে ঠিকানায় পৌঁছাতে পারে সেখানে শুনতে হবে। শুধু loopback-এ বাঁধা প্রসেস মেশিনে আরেকটি ঠিকানা যোগ করলেই পৌঁছানোর যোগ্য হয়ে যায় না।
ফায়ারওয়ালে হাত দেওয়ার আগে লিসেনার নিশ্চিত করুন:
ss -lntp | grep 25565
nc -vz 10.60.0.20 25565প্রথম লাইন দেখায় প্রসেসটি আসলে কোথায় বাঁধা, আর দ্বিতীয়টি দেখায় পিয়ার TCP হ্যান্ডশেক সম্পূর্ণ করতে পারে কি না। বাঁধন যখন 127.0.0.1, তখন VPN কনফিগারেশনের কোনো পরিমাণই ফলাফল বদলায় না, এবং এই একটি বিবরণই আশ্চর্যজনক সংখ্যক «VPN ভাঙা» রিপোর্ট ব্যাখ্যা করে।
পিয়ার নীতি, ফায়ারওয়াল ও উত্তরপথ
লিসেনারের উপরে দুটি অনুমতি-প্রশ্ন বসে আছে। VPN পিয়ার কনফিগারেশনকে দুই পিয়ারের মধ্যে ট্রাফিক অনুমোদন করতে হবে, এবং খেলার হোস্টের ফায়ারওয়ালকে সেই পিয়ার থেকে খেলার পোর্ট গ্রহণ করতে হবে। দুটোকেই খেলা সেবা ও অনুমোদিত পিয়ারের মধ্যে সীমিত রাখুন, হোস্টের ফায়ারওয়াল বন্ধ করার বদলে, যা দুই লাইনের নিয়মকে আরও বড় সমস্যার সঙ্গে বদলায়। সংকীর্ণ নিয়মই এর একমাত্র সংস্করণ যা এক অনুচ্ছেদ যুক্তি ছাড়াই নিরাপত্তা পর্যালোচনা পার করে।
তারপর মনে রাখুন সফল ping কী প্রমাণ করে। VPN গেটওয়েতে পৌঁছানো, বা খেলার হোস্ট থেকে উত্তর পাওয়া, শুধু দেখায় ICMP পথ পার হয়েছে। খেলার সংযোগের জন্য নির্দিষ্ট পোর্ট দুই দিকেই খোলা থাকা দরকার, এবং উত্তরপথ বাইরের পথের মতোই গুরুত্বপূর্ণ।
সার্ভার যখন গেটওয়ের পিছনে থাকে
উপরের উদাহরণে খেলার সার্ভার একটি পিয়ার, যা ঠিকানা পরিকল্পনা সহজ রাখে। সার্ভার যদি বদলে VPN গেটওয়ের পিছনে একটি LAN-এ থাকে, খেলোয়াড়ের সার্ভারের রাউটযোগ্য ব্যক্তিগত ঠিকানা দরকার, গেটওয়েতে সেই LAN-এর জন্য ফরওয়ার্ডিং কনফিগার করতে হবে, এবং LAN হোস্টের টানেল করা ক্লায়েন্টের দিকে ফেরার রুট দরকার। ফেরার পথ বাদ দিলে হ্যান্ডশেক অর্ধপথে মরে, যা তিনটির মধ্যে সবচেয়ে বিভ্রান্তিকর ব্যর্থতা।
এই টপোলজি অনুকরণ করতে উদাহরণের পিয়ার ঠিকানা অন্য মেশিনে কপি করবেন না। উদাহরণের ঠিকানাগুলো ভূমিকা বর্ণনা করে, এবং একটি ঠিকানা দুটি ভূমিকায় পুনরায় ব্যবহার করলে ওভারল্যাপ তৈরি হয় যা রাউটিং সমাধান করতে পারে না।
আবিষ্কার, অ্যাকাউন্ট ও কী বদলাবেন না
স্বয়ংক্রিয় LAN আবিষ্কার ঘোষণার উপর তৈরি সুবিধা। রাউটেড VPN-কে সেই ব্রডকাস্ট বহন করতে হয় না, তাই LAN তালিকায় এন্ট্রি না থাকা স্পষ্ট ব্যক্তিগত ঠিকানা কাজ করে কি না সে বিষয়ে কিছুই বলে না। ঠিকানাটি টাইপ করুন, তারপর বিচার করুন। যদি সংযোগ হয়, আবিষ্কারের ফাঁকটি ত্রুটি নয় বরং ব্যবহারযোগ্যতার ঝামেলা, এবং তদন্ত করার বদলে সেটি তেমনই নথিভুক্ত করা যায়।
খেলার স্বাভাবিক অ্যাকাউন্ট প্রমাণীকরণ ও প্রবেশ নীতিও অক্ষত রাখুন। কাজ করা ব্যক্তিগত রুট পথ দেয়, সদস্যপদ নয়, এবং অ্যাডাপ্টার অগ্রাধিকার এলোমেলো করা ক্লায়েন্টের ব্যবহার করা উচিত গন্তব্য চিহ্নিত করার বিকল্প নয়।