WireGuard কেবল সার্ভার আগে পাঠানোর পরেই কাজ করে: এন্ডপয়েন্ট জ্ঞান

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

এন্ডপয়েন্ট জ্ঞান, পৌঁছানোযোগ্যতা নয়

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

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

পিয়ার কীভাবে এন্ডপয়েন্ট শেখে

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

wg-এর জন্য টুল ডকুমেন্টেশন ওই হালনাগাদ বর্ণনা করে, এবং এটি নিয়ে ডিজাইন করতে চাইলে একবার পড়া মূল্যবান।

অবস্থাসহ ট্রান্সলেশন নিজের একটি দিক যোগ করে

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

এটি দ্বিতীয় ও স্বাধীন একটি প্রক্রিয়া যা একই দিকনির্ভর উপসর্গ তৈরি করে। এন্ডপয়েন্ট জ্ঞান ও ট্রান্সলেশন অবস্থা দুটোই সঠিক হতে হবে, আর একটি ঠিক করলে অন্যটি ঠিক হয় না।

আপনি যে দিকটি সত্যিই চান সেটি কনফিগার করুন

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

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

ট্রিগারের আগে ও পরে অবস্থা তুলনা করুন

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

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

এন্ডপয়েন্ট কলাম ও ট্রান্সলেশন এন্ট্রি একসাথে লিখুন। এন্ডপয়েন্টহীন পিয়ার আর ম্যাপিংহীন গেটওয়ে দুটি ভিন্ন ত্রুটি। এদের মধ্যে কেবল একটি keepalive দিয়ে ঠিক হয়।