Pi-এর হটস্পট ক্লায়েন্টরা TUN VPN-এর মাধ্যমে হোম LAN-এ পৌঁছায় না

যে হটস্পট ক্লায়েন্টরা ঠিকানা পায় কিন্তু হোম শেয়ার খুলতে পারে না, তাদের অনুপস্থিত জিনিসটি সেতু নয়, ফেরত মার্গ। TUN পথ, প্রিফিক্স মালিকানা ও NAT অনুসরণ করুন।

স্থানীয় Wi-Fi ও Ethernet ক্লায়েন্টরা Pi-এর হটস্পটে যুক্ত হয়, এর DHCP পরিসর থেকে ঠিকানা নেয় এবং কোনো অভিযোগ ছাড়াই ইন্টারনেট পৃষ্ঠা লোড করে। তারপর একই ক্লায়েন্টরা হোম LAN-এ ফাইল শেয়ার বা ওয়েব UI খুললে সময় শেষ হয়ে যায়, অথচ Pi নিজে টানেলের মাধ্যমে ওই LAN-এ পৌঁছায়। ওয়্যারলেস স্তরে কিছুই ভাঙা নেই। যা অনুপস্থিত তা হলো একটি রুটেড চুক্তি: হটস্পট প্রিফিক্সকে TUN ইন্টারফেসে বহন করতে হবে, এবং হোম দিকের কিছুকে জানতে হবে কীভাবে সেখানে উত্তর পাঠাতে হয়। একটি প্যাকেটও পুরো যাত্রা শেষ করার আগে দুই অর্ধই থাকতে হবে।

তিনটি আলাদা কাজে তিনটি সংযুক্তি

একটি Linux Ethernet ব্রিজ গন্তব্য MAC ঠিকানা অনুযায়ী ফ্রেম ফরওয়ার্ড করে। OpenVPN TUN মোডে IP প্যাকেট বহন করে এবং এতে কোনো MAC স্তরই নেই, তাই স্থানীয় ব্রিজ যোগ করলে টানেল কখনোই পোর্ট হিসেবে যুক্ত হয় না। কার্নেল TUN/TAP ডকুমেন্টেশন এই বিভাজন ব্যাখ্যা করে: TAP ডিভাইস Ethernet ইন্টারফেসের মতো দেখায়, TUN ডিভাইস নয়। দুই স্থানীয় পোর্ট ব্রিজ করে পরে রাউটিং করে এমন নকশা একটি রাউটার, ইন্টারফেসের নাম যাই বলুক।

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

মডেমকেও ক্লায়েন্ট ব্রিজের বাইরে রাখুন। PPP সংযুক্তি ভিন্ন লেবেল পরা Ethernet ডিভাইস নয়, এবং pppd-এর নথিভুক্ত ডিফল্ট-রুট যুক্তি IPCP আলোচনার পরে চলে এবং ওই লিংক পড়ে গেলে তার রুট প্রত্যাহার করে। DHCP টেমপ্লেট কপি করে প্রতিটি usb0-কে ppp0 নাম দেওয়া গেটওয়ে, মেট্রিক বা জীবনচক্র সম্পর্কে কিছুই প্রমাণ করে না।

কোনো কনফিগ সম্পাদনার আগে প্রিফিক্সগুলো বেছে নিন

ওভারল্যাপিং প্রিফিক্স ফায়ারওয়াল নিয়মের চেয়ে বেশি সন্ধ্যা নষ্ট করে, কারণ ওভারল্যাপ টানেল সুস্থ থাকলেও রুট অনুসন্ধানকে ভুল ইন্টারফেসে পাঠায়। Pi-তে যা ইতিমধ্যে আছে তা তালিকাভুক্ত করে শুরু করুন, তারপর ফলাফলকে চারটি আলাদা পুল হিসেবে পড়ুন।

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

প্রথম পুল হলো underlay ঠিকানা যা ক্যারিয়ার মডেমকে দিয়েছে; এটি ক্লায়েন্টমুখী সব পরিকল্পনার বাইরে থাকতে হবে। দ্বিতীয়টি হলো সার্ভারের বেছে নেওয়া টানেল সাবনেট, প্রায়ই নিজের একটি ব্যক্তিগত /24। তৃতীয়টি হটস্পট ব্রিজ, আর চতুর্থটি হলো আপনি যে হোম প্রিফিক্সে পৌঁছাতে চান। এই পথনির্দেশে হটস্পট 172.28.90.0/24 পায়, ব্রিজ 172.28.90.1-এ থাকে, এবং হোম সার্ভিস LAN 192.168.77.0/24 ধরে রাখে, যা কনজিউমার রাউটার যে ডিফল্ট 192.168.1.0/24 ও 10.0.0.0/24 নিয়ে আসে এবং 100.64.0.0/10 ক্যারিয়ার পরিসর এড়িয়ে যায়।

হটস্পটের DHCP পরিসরে কেবল ব্রিজ ঠিকানাকেই গেটওয়ে হিসেবে ঘোষণা করুন, আর কিছু নয়। হটস্পট ক্লায়েন্টদের কখনো গেটওয়ে হিসেবে হোম ঠিকানা দেবেন না; ওই সেগমেন্টে তাদের লিংক-স্তরের পথ নেই।

প্রতিটি দিক তার মালিক পক্ষেই রাউট করুন

Pi-এর টানেলের মাধ্যমে হোম প্রিফিক্সের জন্য একটি রুট দরকার। সার্ভার মোডের সার্ভাররা সাধারণত ওই রুট পুশ করে, তাই আগে নিশ্চিত করুন ফরওয়ার্ডিং চালু আছে এবং কার্নেল tun0 থেকে হোম ঠিকানা সমাধান করে।

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

যদি ip route get এখনো underlay ইন্টারফেস রিপোর্ট করে, সেখানেই থামুন; পথের পরের কিছুই ভুল অনুসন্ধান ঠিক করতে পারে না।

হোম ডিভাইসগুলোর 172.28.90.0/24-এ কোনো রুট নেই, তাই তাদের উত্তর ডিফল্ট গেটওয়ে অনুসরণ করে রাউটারে মারা যায়। দুটি সমর্থিত সমাধান আছে। হয় হোম রাউটারে একটি স্ট্যাটিক রুট যোগ করুন যা হটস্পট প্রিফিক্সকে VPN সার্ভারের LAN ঠিকানায় পাঠায়, অথবা সার্ভার নিজেই গেটওয়ে হলে ক্লায়েন্ট প্রিফিক্স সার্ভারের নিজস্ব রাউটিং টেবিলে নিবন্ধন করুন। OpenVPN-এর মাল্টি-ক্লায়েন্ট মোডে ক্লায়েন্ট-নির্দিষ্ট ডিরেক্টরি ওই সংযোগ বহন করে: ক্লায়েন্ট সার্টিফিকেটের সাধারণ নামে নামকরণ করা একটি ফাইল, যাতে iroute 172.28.90.0 255.255.255.0 এবং সার্ভার কার্নেলে তা ইনস্টল করা মিলিত route লাইন থাকে। সার্ভারে অনুমান করা কার্নেল রুট আর সার্ভারকে বলা যে কোন ক্লায়েন্ট প্রিফিক্সের মালিক, একই কথা নয়।

এটা কাজ করাতে হোম নেটওয়ার্কের DHCP সেবা VPN সার্ভারে সরাবেন না। পুরো বাড়ির জন্য ডিফল্ট গেটওয়ে বদলানো একটি ব্যক্তিগত ফেরত রুট যোগ করার চেয়ে অনেক বড় পরিবর্তন, এবং এটি DNS, ঠিকানা সংরক্ষণ ও নতুন লিজ উপেক্ষা করা প্রতিটি ডিভাইসকে ব্যর্থতায় টেনে নেয়।

ফায়ারওয়াল নিয়ে অনুমান না করে ফরওয়ার্ডিং খুলুন

ফরওয়ার্ডিং চালু থাকা মানে প্যাকেট পার হতে অনুমোদিত নয়। ব্রিজ থেকে টানেলে ট্রাফিক এখনো ফিল্টার নিয়মে ধাক্কা খায়, এবং ডিফল্ট-ড্রপ ফরওয়ার্ড নীতি হটস্পট ট্রাফিক ফেলে দেয় যখন Pi-এর নিজের ট্রাফিক চলতে থাকে, যা ঠিক উপরের বিভক্ত লক্ষণ তৈরি করে।

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 থেকে tun0 পর্যন্ত একটি গ্রহণ নিয়ম ও মিলিত উত্তর দিক, এবং সোর্স পুনর্লিখন করতে পারে এমন postrouting নিয়ম খুঁজুন। চেইন নীতি drop হলে এবং কোনো নিয়ম না মিললে, নীতি accept-এ উল্টানোর বদলে সংকীর্ণ গ্রহণগুলো যোগ করে আবার পরীক্ষা করুন।

অনুবাদ একটি নীতি-পছন্দ, কোনো বাধ্যবাধকতা নয়। হোম LAN-এর দিকে সোর্স NAT প্রতিটি হটস্পট ক্লায়েন্টকে Pi-এর টানেল ঠিকানার মতো দেখায়, যা হোম লগে প্রতি-ক্লায়েন্ট অ্যাট্রিবিউশন হারায় এবং মূল সোর্স প্রত্যাশা করে এমন সেবা ভাঙে। NAT ছাড়া রাউটিং ক্লায়েন্ট ঠিকানা দৃশ্যমান রাখে কিন্তু উপরের ফেরত রুটের উপর নির্ভর করে। একটি বেছে নিন এবং DNS ও IPv6-কে একইভাবে সামলান, কারণ ভাঙা IPv6 পথের পাশে কাজ করা IPv4 পথ ব্রাউজারে এখনো অর্ধ-ভাঙা হিসেবেই পড়া হয়।

যাত্রা যাচাই করুন, তারপর সেটি ইচ্ছাকৃতভাবে ভাঙুন

হটস্পট ক্লায়েন্ট থেকে পরীক্ষা করুন, কখনো Pi থেকে নয়, কারণ Pi-এর নিজের ট্রাফিক ফরওয়ার্ড ও ফেরত—দুই পথই এড়িয়ে যায়। একজন ক্লায়েন্ট হোম সেবায় পৌঁছাতে চেষ্টা করার সময় দুই ইন্টারফেসই দেখুন।

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

দুটি ক্যাপচার একসঙ্গে পড়ুন। br0-এ অনুরোধ যা কখনো tun0-এ দেখা যায় না, বোঝায় Pi ফরওয়ার্ড করছে না বা রুট অন্য জায়গায় যায়। tun0-এ উত্তরহীন অনুরোধ বোঝায় হোম দিকে ফেরত রুট নেই বা সার্ভার প্যাকেট ফিল্টার করেছে। tun0-এ উত্তর যা আর কখনো br0-এ দেখা যায় না, বোঝায় উল্টো ফিল্টার নিয়ম অনুপস্থিত, যেখানে টানেল নিখুঁত দেখায় আর ক্লায়েন্ট তবু কিছুই দেখে না।

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

নকশাটি কেবল তখনই গ্রহণ করুন যখন একজন হটস্পট ক্লায়েন্ট হোম নাম সমাধান করতে, TCP সেবা খুলতে এবং একবার মডেম পুনঃসংযোগ জুড়ে সেশন জীবিত রাখতে পারে। যদি কোনো অ্যাপ্লিকেশন সত্যিই হোম সেগমেন্টে Ethernet-স্তরের আবিষ্কার দরকার করে, স্থানীয় ব্রিজকে ব্রিজড বলে বর্ণনা করে ব্রডকাস্ট আসার অপেক্ষা না করে সমর্থিত Layer 2 নকশা বেছে নিন।

সম্পর্কিত নিবন্ধ