Nebula punchy সেটিংস: কোনটি আপনার NAT ঠিক করে

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

সময়ের আগে প্রান্তবিন্দু নিশ্চিত করুন

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

আপনি যে প্রান্তবিন্দু জোড়া দিয়ে পরীক্ষা করছেন তা লিখে রাখুন, যাতে পরের তুলনাগুলো অন্য দুটি মেশিনের বদলে একই পিয়ার ব্যবহার করে।

punch ম্যাপিং রাখে, respond দিক খোলে

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

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

বিলম্ব ঠিক করে কখন, তা নয় যে হবে কি না

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

প্রক্রিয়াটি ঠিক না হওয়া পর্যন্ত ওগুলো ছেড়ে দিন। তারপর একটি সমন্বয় করুন, আর পুরনো মান লিখে রাখুন।

যখন রিলেই সৎ উত্তর

কিছু NAT সমন্বয় সরাসরি পথ সমর্থন করতে পারে না, সময় যেভাবেই সাজানো হোক। দুই পাশেই সিমেট্রিক NAT, বা এমন ফায়ারওয়াল যা অযাচিত আগত ট্রাফিক সম্পূর্ণ ফেলে দেয়, ভেদ করার মতো কিছুই রাখে না।

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

ব্যর্থ জোড়াটি অলস থাকার পরে পরীক্ষা করুন

যে অবস্থা ভেঙেছিল তা পুনরুৎপাদন করুন: একই ব্যবধানের জন্য জোড়াটি অলস রাখুন, বা আগে যে হ্যান্ডশেক ক্রমটি ব্যর্থ হতো তা পুনরাবৃত্তি করুন। তারপর ওই দুই পিয়ারের মধ্যে অ্যাপ্লিকেশন চালান, বাতিঘরে কোনো অনুরোধ নয়। বাতিঘরের উত্তর নিয়ন্ত্রণ পথ প্রমাণ করে, ডেটা পথ সম্পর্কে কিছুই নয়।

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