কিল সুইচ কোনো ট্রাফিক প্রবাহের আগেই VPN সার্ভারকে আটকে দেয়
কিল সুইচ কোন ধাপে আটকাচ্ছে: এন্ডপয়েন্ট খোঁজা, বাইরের রুট, ফেরার পথ এবং পুরোনো পিয়ার ব্যতিক্রম— অনুমানের বদলে কাউন্টার দিয়ে।
কিল সুইচ ব্যর্থ হয় এমন দিকেও যা মানুষ আশা করে না: এগুলো টানেল বন্ধ থাকার সময় ট্রাফিক আটকাতে তৈরি, আর টানেল তৈরির প্যাকেটগুলো নিজেই ট্রাফিক। পুরো বাগটাই এখানে। যে নিয়মসেট টানেল দিয়ে না-যাওয়া সবকিছু ফেলে দেয়, সেটি সেই হ্যান্ডশেকও ফেলে দেয় যা টানেলটি তুলবে, তাই ক্লায়েন্ট লুপে আবার চেষ্টা করে এবং ত্রুটিটি প্রথমে যাচাই করা ধাপের ওপর চাপে। ফায়ারওয়াল বাড়ানোর আগে বের করুন তিনটি ধাপের কোনটি প্রত্যাখ্যাত হচ্ছে: নাম খোঁজা, পিয়ারের কাছে বাইরের প্যাকেট, নাকি ফিরে আসা উত্তর।
টানেল আর তার নিজের পরিবহন কীভাবে পরস্পরের ওপর নির্ভর করে
একটি VPN ক্লায়েন্টকে একই সকেট পথ ভাগ করা দুটি নেটওয়ার্ক অবস্থা হিসেবে পড়ুন। টানেল তৈরি হওয়ার আগে ক্লায়েন্ট ফিজিক্যাল অ্যাডাপ্টারে সকেট খোলে এবং পিয়ারের ঠিকানা ও পোর্টে এনক্রিপ্ট করা ফ্রেম পাঠায়। সেই বিনিময় সফল হওয়ার পরেই এটি টানেল ডিভাইস তৈরি করে ও রুট বসায়। কিল সুইচ দ্বিতীয় অবস্থার নীতিমালা, যা এত বিস্তৃতভাবে লেখা যে দুটিরই ওপর প্রযোজ্য।
ইন্টারফেস-ভিত্তিক নিয়মই সাধারণ রূপ: যা দিয়ে বেরোয় তা গ্রহণ করুন tun0 বা wg0, বাকি আউটপুট পথ ফেলে দিন। এই গঠন ক্লায়েন্টের নিজের সার্ভার-সংযোগকে ছাড় দিতে পারে না, তাই সঠিক বাস্তবায়ন সেই ব্যতিক্রমটি স্পষ্টভাবে যোগ করে, আর আপনিও হাতে নিয়ম লেখার সময় তা করেন। Windows ও macOS-এ প্রতি-অ্যাপ্লিকেশন নিয়ম ইন্টারফেসের বদলে প্রসেস মিলিয়ে এর কিছুটা এড়ায়, কিন্তু টানেল তৈরির আগে প্রসেসকেও বেরোতে হয়।
তিনটি ধাপ, ঘটার ক্রম অনুসারে
প্রথম ধাপ রেজলিউশন। প্রোফাইল যখন আক্ষরিক ঠিকানার বদলে হোস্টনাম সংরক্ষণ করে, তখন কিছু পাঠানোর আগে ক্লায়েন্টের DNS উত্তর দরকার। যে প্রোফাইল DNS-কে টানেল রিজলভারের দিকে পাঠায়, তা এক অচল অবস্থা তৈরি করে: রিজলভারটি কেবল সেই টানেল দিয়েই পৌঁছনো যায় যা খোঁজাটি চালু করার কথা। টানেলের বাইরে রিজলভ করা, বা এন্ডপয়েন্টকে একটি ঠিকানায় পিন করা, এই দ্বিধা সরিয়ে দেয়।
দ্বিতীয় ধাপ বাইরের প্যাকেট, যাকে এই ক্রমে আগে রাউটিং তারপর ফায়ারওয়াল পেরোতে হয়। wireguard-tools WireGuard-এর জন্য এর রাউটিং অর্ধেক সামলায় নিজের প্যাকেট চিহ্নিত করে ও একটি নীতি নিয়ম যোগ করে, যাতে সেগুলো এইমাত্র বসানো ডিফল্ট রুট এড়িয়ে যায়; wg-quick ম্যান পেজ সেই নিয়ম ও যে টেবিলটি এটি ব্যবহার করে তা বর্ণনা করে। হাতে সেই রাউটিং আবার গড়ুন, বা দ্বিতীয় কোনো টুলকে নিয়মগুলো পুনর্লিখতে দিন, তাহলে চিহ্নিত প্যাকেটগুলো যে টানেলে ঢোকার কথা সেটিতেই ফিরে যেতে পারে।
তৃতীয় ধাপ ফেরার পথ। উত্তরহীন হ্যান্ডশেক বাইরের দিকে ফেলে দেওয়ার প্রমাণ নয়; এটি সার্ভারের ইনবাউন্ড নিয়ম বা ম্যাপিং ভুলে যাওয়া NAT ডিভাইসের সাথেও সমানভাবে মেলে। ক্লায়েন্টে হাত দেওয়ার আগে এগুলো আলাদা করুন।
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
ক্লায়েন্ট যা ধরে ফেলে সেই লক্ষণ লগ করে, ব্যর্থ ধাপটি নয়, তাই টেবিল সাধারণত লগের চেয়ে দ্রুত।
কাউন্টার লগের চেয়ে দ্রুত সিদ্ধান্ত দেয়
Linux-এ, nft list ruleset বা iptables -vnL OUTPUT প্রতি নিয়মে একটি প্যাকেট কাউন্টার ছাপে। একবার সংযোগ করুন, ব্যর্থ হতে দিন, তারপর কাউন্টার আবার পড়ুন। যে নিয়মের কাউন্টার নড়েছে সেটিই সেই নিয়ম যেখানে হ্যান্ডশেক লেগেছে; যদি কোথাও কিছুই না নড়ে, প্যাকেটটি ফায়ারওয়ালে পৌঁছায়নি। আমি দেখেছি একটি নিয়মসেট নিজের হ্যান্ডশেকই ফেলে দিয়েছে, আর কেবল কাউন্টারই তা বলেছে।
ফায়ারওয়ালে কখনো পৌঁছায়নি আর হোস্ট ছেড়েইনি—এই দুটো আলাদা করতে ইন্টারফেসটাই লক্ষ্য করুন। ip -s link show dev wlan0 পাঠানো প্যাকেট জানায়, আর tcpdump -ni wlan0 udp port 51820 ফ্রেমগুলো দেখায়। ক্লায়েন্ট আবার চেষ্টা করার সময় এটি সমান থাকে, তবে ত্রুটি netfilter-এর ওপরে: অনুপস্থিত পিয়ার রুট, এমন ডিভাইসের দিকে যাওয়া নীতি নিয়ম যা এখনো নেই, বা ক্লায়েন্ট যে সকেট ত্রুটি গিলে ফেলছে।
ডকুমেন্টেশন ঠিকানা দিয়ে ব্যতিক্রম পরীক্ষা করুন, যেমন 203.0.113.10, যাতে কোনো ভুলে অন্যের হোস্ট পরখ করা না যায়।
পুরোনো এন্ডপয়েন্ট ব্যতিক্রম সার্ভার বিকল হিসেবে পড়া হয়
সবচেয়ে বিভ্রান্তিকর সংস্করণটি আসে পিয়ারের ঠিকানা বদলানোর পরে: গতিশীল-ঠিকানা সেবা সেটি সরিয়েছে, হোস্ট পুনর্নির্মিত হয়েছে, বা আপনার নেটওয়ার্কের আউটগোয়িং ঠিকানা আলাদা। ব্যতিক্রমটি এখনো পুরোনো ঠিকানার নাম বলে, তাই নতুন ঠিকানায় যাওয়া প্যাকেট ফেলে দেওয়ার নিয়মে পড়ে। একই কনফিগারেশন গতকাল কাজ করেছিল, তাই মানুষ সার্ভার নিয়ে সমস্যা খোঁজা শুরু করে।
ফায়ারওয়াল নিয়মের ভেতরে হোস্টনাম আপনাকে বাঁচায় না। nftables-এ নিয়মসেট লোড হওয়ার সময় নামটি রিজলভ হয়, তাই সেই মুহূর্তে যে ঠিকানা ছিল তা পিন হয়ে যায় এবং আক্ষরিক ঠিকানার মতোই পুরোনো হয়ে যায়। টেকসই সমাধান হলো এন্ডপয়েন্ট বদলালে ব্যতিক্রমটি হালনাগাদ করা এবং তা সংকীর্ণ রাখা: এক পিয়ার ঠিকানা, এক পরিবহন পোর্ট। ঠিকানা বদল টিকিয়ে রাখার মতো চওড়া পরিসর অসংশ্লিষ্ট ট্রাফিকও বের করতে যথেষ্ট চওড়া।
যখন কিল সুইচ সার্ভার হোস্টে চলে
একই নির্ভরতা অন্যপ্রান্তেও আছে, আর সেখানে এটি মিস করা সহজ। যদি আপনার VPN সার্ভার হিসেবে থাকা মেশিনে কিল সুইচসহ ডেস্কটপ ক্লায়েন্ট চলে, বা ল্যাপটপ থেকে কপি করা ফায়ারওয়াল প্রোফাইল থাকে, তার ফেলে দেওয়ার নিয়মগুলো টানেল শেষ করা সার্ভিসেও খাটে। ক্লায়েন্টের হ্যান্ডশেকের উত্তর ফেলে দেওয়া হয়, তাই সার্ভার সুস্থ দেখালেও এবং তার টানেল ইন্টারফেস অব্যবহৃত থাকলেও প্রতিটি ক্লায়েন্ট সংযোগে ব্যর্থ হয়।
সেই হোস্টে ফেলে দেওয়ার আগে তিনটি সংকীর্ণ গ্রহণ দরকার: ফিজিক্যাল ইন্টারফেসে শোনার পোর্ট, ডিক্রিপ্ট করা ট্রাফিকের জন্য টানেল ইন্টারফেস, এবং টানেল থেকে ক্লায়েন্টদের যেখানে পৌঁছানোর কথা সেখানে ফরওয়ার্ডিং। ইনস্টল করা সেটটি পড়ুন nft list ruleset, iptables -S, বা pfctl -sr দিয়ে, কিছু বদলানোর আগে, এবং মনে রাখুন সংরক্ষিত নিয়মসেট রিবুটেও টেকে, তাই সেখানকার ভুল সেটি তৈরি করা প্রসেসের চেয়ে বেশি দিন বাঁচে।
যে পুনরুদ্ধার-ক্রম মেশিনটি বন্ধ রাখে
প্রোফাইল থেকে বাইরের দিকে কাজ করুন। ক্লায়েন্ট যে পিয়ার ঠিকানা ও পোর্ট ব্যবহার করে তা পড়ুন, টানেল ছাড়া হোস্টনাম রিজলভ হয় কি না নিশ্চিত করুন, তারপর কেবল ফিজিক্যাল অ্যাডাপ্টারে সেই ঠিকানা ও পোর্টের জন্য একটি ব্যতিক্রম যোগ করুন। আবার সংযোগ করুন ও পাঠানোর কাউন্টার দেখুন; সম্পূর্ণ হ্যান্ডশেকই সংকেত যে দ্বিতীয় ধাপ ঠিক হয়েছে।
পরীক্ষার সময় ফেলে দেওয়ার বাকি নীতিমালা যথাস্থানে রাখুন। নিরীহ পরীক্ষা হলো অসংশ্লিষ্ট ডকুমেন্টেশন ঠিকানায় সংযোগের চেষ্টা করে দেখা যে এটি এখনো সময় শেষে ব্যর্থ হয়, যা দেখায় কিল সুইচ বন্ধ নয়, কাজ করছে। টানেল স্থির হলে ব্যতিক্রমটি কষাকষি করুন, এবং সুবিধা বলে ক্লায়েন্ট বাইনারির জন্য স্থায়ী সব-অনুমতি রেখে দেবেন না।
টানেল উঠে এলেও অ্যাপ্লিকেশন এখনো ব্যর্থ হলে বাকি ধাপগুলো এটি নয়: বিভক্ত DNS, MTU, এবং প্রতি-অ্যাপ্লিকেশন রাউটিং—প্রতিটি সংযুক্ত টানেলের সাথে ভাঙা ট্রাফিক দেয়, আর প্রতিটির প্রথম পরীক্ষা আলাদা।