WireGuard হ্যান্ডশেক কাজ করে কিন্তু ইন্টারনেট নেই: প্যাকেটটি অনুসরণ করুন
হ্যান্ডশেক কেবল কী ও পৌঁছানোযোগ্যতার প্রমাণ দেয়। AllowedIPs থেকে ফরওয়ার্ডিং, NAT ও ফেরত রুট হয়ে একটি প্যাকেট অনুসরণ করুন এবং দেখুন কোথায় থামে।
টানেল চালু আছে, wg show একটি সাম্প্রতিক হ্যান্ডশেক দেখাচ্ছে, আপনি সার্ভারের টানেল ঠিকানায় ping করতে পারেন, আর তারপরের কিছুই উত্তর দেয় না। সহজাত প্রবৃত্তি হলো কী আবার তৈরি করা বা কনফিগ আবার শেয়ার করা। কিন্তু এতে পথের ঠিক সেই অংশটি বদলানো হয় যা ইতিমধ্যে কাজ করার প্রমাণ দিয়েছে।
সম্পূর্ণ হওয়া একটি হ্যান্ডশেক বলে যে দুই প্রান্ত কী নিয়ে একমত, UDP এন্ডপয়েন্টে পৌঁছায়, এবং ক্রিপ্টো রাউটিং প্যাকেটটি গ্রহণ করে। এটি বলে না যে প্যাকেটটি এরপর সার্ভার ছাড়তে পারবে কি না।
তাই অনুমান না করে একটি প্যাকেট অনুসরণ করুন। এটি মারা যেতে পারে এমন চারটি জায়গা আছে, আর প্রতিটি আলাদা চিহ্ন রেখে যায়।
হ্যান্ডশেক আসলে কী প্রমাণ করে
WireGuard হলো একটি UDP প্রোটোকল, যা Noise হ্যান্ডশেক দিয়ে সেশন স্থাপন করে এবং তারপর সহকর্মীর জন্য প্যাকেট এনক্রিপ্ট করে। যখন wg show কয়েক সেকেন্ড পুরোনো হ্যান্ডশেক ও বাড়তে থাকা ট্রান্সফার কাউন্টার দেখায়, তখন এন্ডপয়েন্ট, কী এবং সহকর্মীর পাবলিক কী সবই ঠিক আছে।
এটি প্রমাণ করে না যে আপনার ক্লায়েন্ট ইন্টারনেটগামী ট্রাফিক আদৌ ইন্টারফেসে পাঠাচ্ছে, সার্ভার তা ফরওয়ার্ড করতে রাজি, বা উত্তর ফেরার পথ খুঁজে পাবে। এগুলো কার্নেলের রাউটিং ও ফায়ারওয়ালের সিদ্ধান্ত, আর সেগুলো টানেলের বাইরে নেওয়া হয়।
এই কারণেই সার্ভারের টানেল ঠিকানায় ping করা এত বিভ্রান্তিকর পরীক্ষা। ওই প্যাকেটটি সার্ভারের নিজের কাছে ঠিকানাভুক্ত, তাই এটি স্থানীয়ভাবেই শেষ হয়। এর কখনো ফরওয়ার্ডিং দরকার হয় না, কখনো অনুবাদ দরকার হয় না, আর কখনো ইন্টারনেট থেকে ফেরত রুট দরকার হয় না।
AllowedIPs একটি রাউটিং সিদ্ধান্ত
ক্লায়েন্টে AllowedIPs দুটি কাজ করে। এটি হলো ক্রিপ্টোকী রাউটিং টেবিল, যা ঠিক করে কোন গন্তব্য ঠিকানা এই সহকর্মীর টানেলে পাঠানো হবে, আর এটি হলো সেই সব সোর্স ঠিকানার তালিকা যা সহকর্মী আপনার কাছ থেকে গ্রহণ করবে। ক্লায়েন্ট কনফিগে যদি শুধু 10.8.0.0/24 থাকে, তাহলে পাবলিক গন্তব্য কখনো ইন্টারফেসে ঢোকে না এবং আপনার স্বাভাবিক ডিফল্ট রুট সেগুলোকে টানেলের বাইরে নিয়ে যায়। তখন টানেল নিখুঁতভাবে কাজ করে এবং আপনি যা চেয়েছিলেন তার কিছুই করে না।
কনফিগ ফাইল যা বলে তা নয়, ক্লায়েন্ট আসলে কী ইনস্টল করেছে তা দেখুন:
wg show wg0 allowed-ipsip route get 1.1.1.1
দ্বিতীয় কমান্ডটাই নির্ণায়ক। উত্তর যদি আপনার ফিজিক্যাল ইন্টারফেস ও স্বাভাবিক গেটওয়ের নাম বলে, তাহলে প্যাকেট টানেল হয়ে যাচ্ছে না এবং সার্ভার পাশে কোনো পরিবর্তনই তা ঠিক করবে না। IPv4-এর জন্য 0.0.0.0/0 এবং IPv6-এর জন্য ::/0 আলাদাভাবে যোগ করুন; এক পরিবারের জন্য সবকিছু ধরা নিয়ম অন্য পরিবারটিকে তার পুরোনো পথেই রাখে, আর এটাই কাজ করা IPv4 টানেল ও আটকে থাকা IPv6 লুকআপের সাধারণ কারণ।
গেটওয়েতে প্যাকেট কোথায় মারা যায়
রুট ঠিক থাকলে আর প্যাকেট তবুও কোথাও না গেলে, এটি সার্ভারে পৌঁছে সেখানেই থেমে যায়। চারটি পরীক্ষা বেশিরভাগ গেটওয়ে ঢেকে দেয়।
ফরওয়ার্ডিং। sysctl net.ipv4.ip_forward যদি 0 ফেরত দেয়, এটাই চিরাচরিত উত্তর, এবং অনেক ডিস্ট্রিবিউশনে ডিফল্ট এখনো 0। এটি 1 হতে হবে, আর কমান্ডের বদলে sysctl ফাইলে স্থায়ীভাবে সেট করতে হবে, কারণ কমান্ড রিবুটে হারিয়ে যায়। IPv6 ফরওয়ার্ডিং আলাদা সুইচ।
ফিল্টার নীতি। ডিফল্ট ড্রপ নীতিসম্পন্ন FORWARD চেইন টানেলের ট্রাফিক ফেলে দেবে, অথচ হোস্টের নিজের কাছে যাওয়া ট্রাফিক অনুমোদন করবে, আর এটি উপসর্গের সঙ্গে হুবহু মেলে। সংরক্ষিত ফাইল নয়, জীবন্ত নিয়মসমূহ পড়ুন: nft list ruleset অথবা iptables -S।
অনুবাদ বা রাউটিং। প্রাইভেট টানেল ঠিকানা ব্যবহার করা ক্লায়েন্টের হয় সার্ভারের ইগ্রেস ইন্টারফেসে সোর্স NAT দরকার, নয়তো এমন রাউটেড প্রিফিক্স দরকার যা আপস্ট্রিম নেটওয়ার্ক ফেরত পাঠাতে জানে। দুটির মধ্যে বাছাই ঠিকানা পরিকল্পনা অনুসরণ করে। যে নেটওয়ার্ক ইতিমধ্যে আপনার প্রিফিক্স ফেরত রাউট করে সেখানে MASQUERADE যোগ করা ক্ষতিকর নয়, তবে অর্থহীন, আর যেখানে কোনো রুট নেই সেখানে তা বাদ দিলে উত্তরগুলো অরাউটেবল প্রাইভেট রেঞ্জে ঠিকানাভুক্ত হয়ে পড়ে থাকে।
ফেরত পথ। রাউটেড ডিজাইনে আপস্ট্রিম রাউটারের আপনার সার্ভারের দিকে নির্দেশ করা একটি রুট দরকার। প্রোভাইডার নেটওয়ার্কও এটি আটকাতে পারে: অনেক ক্লাউড ইনস্ট্যান্সে সোর্স ও ডেস্টিনেশন চেক চালু করে, যা এমন প্যাকেট নিঃশব্দে ফেলে দেয় যার সোর্স ইনস্ট্যান্সের নিজের ঠিকানা নয়, যতক্ষণ ওই চেক বন্ধ না করা হয়।
DNS রাউটিং থেকে আলাদাভাবে ব্যর্থ হয়
পরিচিত ঠিকানায় প্যাকেট আর নামের লুকআপ দুটি আলাদা ব্যর্থতা, আর ত্রুটির বার্তাগুলো বিপরীত দিকে বিভ্রান্ত করে। যদি ping 1.1.1.1 কাজ করে অথচ ব্রাউজার কিছুই লোড করতে না পারে, তাহলে রুট ঠিক আছে, নাম রিজলিউশন নেই। যদি ping নিজেই ব্যর্থ হয়, DNS অপ্রাসঙ্গিক এবং আপনি আগের অংশে ফিরে এসেছেন।
wg-quick কনফিগের DNS = লাইন থেকে রিজলভার সেট করতে পারে, আর systemd-resolved-এর প্রতিটি লিঙ্কের জন্য নিজস্ব আচরণ আছে। যে VPN রিজলভারকে কেবল টানেলের ভেতরে পৌঁছানোযোগ্য ঠিকানা দিয়ে প্রতিস্থাপন করে, সেটি টানেল পড়ার মুহূর্তেই প্রতিটি লুকআপ ব্যর্থ করবে, আর এটি দেখে মনে হয় টানেলই ইন্টারনেট ভাঙছে।
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
এমন একটি ক্রম যা প্রমাণ দেয়
প্রথমে ক্লায়েন্টের দিকের পরীক্ষাটি চালান, কারণ এটি একটি কমান্ড এবং সম্ভাবনার অর্ধেক বাদ দেয়। তারপর নিশ্চিত করুন সার্ভারটি আদৌ ইন্টারনেট আউটলেট হিসেবে তৈরি কি না; প্রাইভেট অ্যাক্সেসের জন্য বানানো গেটওয়ে পাবলিক গন্তব্য ব্যর্থ হলে নষ্ট হয় না।
সার্ভারে, ক্লায়েন্ট থেকে ping পাঠানোর সময় ইন্টারফেসটি দেখুন: tcpdump -ni wg0 icmp অনুরোধটি দেখানো উচিত, আর tcpdump -ni eth0 icmp সেটি বেরিয়ে যাওয়া দেখানো উচিত, অনূদিত হোক বা না হোক। যদি প্রথমটিতে দেখা যায় আর দ্বিতীয়টিতে কখনোই না, তাহলে থামা সার্ভারের ভেতরেই। যদি বেরিয়ে যায় অথচ কোনো উত্তর ফেরত না আসে, সমস্যা আপস্ট্রিমে, আর সেটি ভিন্ন আলোচনা।
শেষে ঠিকটি রিস্টার্টেও টিকে থাকার ব্যবস্থা করুন। ফরওয়ার্ডিংয়ের জায়গা sysctl ফাইলে, ফায়ারওয়াল নিয়মের জায়গা সেগুলো লোড করা সার্ভিসে, আর ক্লায়েন্ট রুটের জায়গা সেই কনফিগে যা ইন্টারফেস তোলে, আপনি যে শেল ভুলে যাবেন সেখানে নয়। আবার সংযোগ করুন, একই দুটি পরীক্ষা পুনরাবৃত্তি করুন এবং কাউন্টারগুলো নড়ছে কি না নিশ্চিত করুন।