Raspberry Pi VPN গেটওয়ে: একটি নেটওয়ার্ক পোর্ট নাকি আলাদা ক্লায়েন্ট পোর্ট
একটি Pi পোর্ট নির্বাচিত ক্লায়েন্টদের সেবা দিতে পারে, নয়তো দ্বিতীয় পোর্ট ডিভাইসগুলোকে ভেতরে আটকে রাখতে পারে। বিচ্ছিন্নতা, ব্যর্থতার নীতি আর DNS-এর মালিকানা দেখে লেআউট বেছে নিন।
আপনার কাছে একটি Raspberry Pi, একটি কাজ করা বহির্গামী VPN প্রোফাইল এবং দুটি ডিভাইস আছে যা দিয়ে ইন্টারনেটে পৌঁছানো উচিত। পুরো নির্মাণ নির্ধারণ করে যে প্রশ্নটি তা কোনো গাইড অনুসরণ করা নয়, বরং আপনার কতটা বিচ্ছিন্নতা দরকার। একটি পোর্ট Raspberry Pi-কে ওই ডিভাইসগুলোর পাশে রাউটারের LAN-এ বসতে এবং অতিরিক্ত গেটওয়ে হিসেবে কাজ করতে দেয়; দ্বিতীয় পোর্ট আপনাকে সেগুলো এমন সেগমেন্টে রাখতে দেয় যেখানে Raspberry Pi একমাত্র বেরোনোর পথ। এই পছন্দের পরের সবকিছু — DHCP, ফায়ারওয়ালের পরিধি, DNS, বিচ্ছিন্নতার ঘটনা — তা থেকেই আসে।
দুটি লেআউট আসলে কোথায় আলাদা
দুটি নকশাই রাউটিং করে। পার্থক্য হলো তারে আর কে দাঁড়িয়ে আছে এবং আপনার নীতি ভুল হলে কী হয়।
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
আসল অক্ষ হলো বিচ্ছিন্নতা। লেআউট A পরামর্শমূলক: যে ডিভাইস DHCP-প্রদত্ত গেটওয়ে উপেক্ষা করে রাউটার বেছে নেয়, সেটি এখনও কাজ করে, এনক্রিপশন ছাড়াই। লেআউট B টোপোলজি দিয়ে বলবৎ হয়, কারণ বেছে নেওয়ার মতো অন্য কোনো পরবর্তী হপ নেই।
লেআউট A: বিদ্যমান LAN-এ Raspberry Pi অতিরিক্ত গেটওয়ে হিসেবে
ধরুন ISP রাউটার 192.168.50.1, Raspberry Pi 192.168.50.2, এবং নির্বাচিত ক্লায়েন্টরা Raspberry Pi-র দিকে ইঙ্গিত করে। গুরুত্বপূর্ণ হলো, দুটি ভিন্ন প্যাকেট প্রবাহ একটি কেবল ভাগ করে। ক্লায়েন্টের ভেতরের প্যাকেট Raspberry Pi-তে পৌঁছে এবং টানেল দিয়ে বেরোতে হবে; VPN সহকর্মীর কাছে Raspberry Pi-র নিজের এনক্রিপ্টেড প্যাকেট একই কেবল দিয়ে রাউটারের দিকে বেরোতে হবে। তারা একই ইন্টারফেসে বিপরীত দিকে চলে এবং ভিন্ন ব্যবহার দরকার।
Raspberry Pi-কে তার ঠিকানা দিন ইনস্টল করা নেটওয়ার্ক ম্যানেজারের মাধ্যমে, পুরোনো ইন্টারফেস-ফাইল রেসিপির মাধ্যমে নয় যা ডিভাইসটির জন্য এর সঙ্গে লড়াই করে। তারপর ক্লায়েন্ট ঠিক করুন: একটি ডিভাইসে স্ট্যাটিক গেটওয়ে, বা একটি DHCP রিজার্ভেশন যা 192.168.50.2 রাউটার হিসেবে দেয়। দুটি ডিভাইসের জন্য রাউটারের পুরো DHCP স্কোপ বদলাবেন না, এবং ধরে নেবেন না যে ক্লায়েন্ট এই অপশন মানে — যাচাই করুন।
দুর্বলতাটি কাঠামোগত, সারানোর মতো নয়। ওই সেগমেন্টের যেকোনো ক্লায়েন্ট 192.168.50.1-এর দিকে ইঙ্গিত করে এনক্রিপশন ছাড়া বেরোতে পারে, আর দ্বিতীয় ইন্টারফেস বা সেলুলার রেডিও থাকা ডিভাইস আপনার বলবৎ করার পথ সম্পূর্ণ ছেড়ে যায়। যদি এই বাক্যটি সংশ্লিষ্ট ডিভাইসের জন্য অগ্রহণযোগ্য হয়, তাহলে উত্তর আপনার কাছে আছে: লেআউট B ব্যবহার করুন।
লেআউট B: আলাদা পোর্ট ডিভাইসগুলোকে ভেতরে আটকে রাখে
এখানে Raspberry Pi আপলিংকে 192.168.50.2 রাখে গেটওয়ে 192.168.50.1 সহ, এবং সংযুক্ত ডিভাইসগুলোর জন্য দ্বিতীয় ইন্টারফেসে 10.20.0.1/24 নেয়। এখন Raspberry Pi দুটি নেটওয়ার্কের রাউটার, আর সংযুক্ত সেগমেন্টের ঠিক একটি বেরোনোর পথ আছে।
প্রতিশ্রুত হওয়ার আগে রেঞ্জটি বাকি সবকিছুর সঙ্গে মিলিয়ে দেখুন: টানেলের নিজের সাবনেট, অন্য সাইট-থেকে-সাইট প্রিফিক্স, এবং VPN দিয়ে পৌঁছনোর মতো সবকিছু। দূরবর্তী LAN-এর সঙ্গে সংঘর্ষকারী 10.20.0.0/24 সেই অর্ধ-কাজ করা ফল দেয় যা নির্ণয় করতে একটি সন্ধ্যা লেগে যায়। যদি দ্বিতীয় পোর্ট USB অ্যাডাপ্টার হয়, নিশ্চিত করুন এটি সমর্থিত, এবং নেটওয়ার্ক ম্যানেজারে এর নাম পিন করুন যাতে রিবুটের পর পুনর্বিন্যাস আপনার LAN ঠিকানা সরিয়ে না দেয়।
DHCP লিসেনার শুধু ওই ইন্টারফেসে চালান। আপলিংকে উত্তর দেওয়া সার্ভার ISP রাউটারের সঙ্গে প্রতিযোগিতা করে এবং আপনার সেগমেন্টের ঠিকানা বাড়ির বাকি অংশকে দিয়ে দেয়। এটি LAN ইন্টারফেসে বেঁধে দিন, ঘোষিত রেঞ্জে সীমাবদ্ধ রাখুন, এবং Raspberry Pi-র নিজের ঠিকানা পুলের বাইরে রাখুন।
ফরওয়ার্ডিং, অনুবাদ এবং ব্যর্থতায় বন্ধ হওয়ার নিয়ম
চারটি জিনিসকে প্রায়ই এক হিসেবে বর্ণনা করা হয়, অথচ তা নয়। ফরওয়ার্ডিং চালু করা (net.ipv4.ip_forward=1) কেবল কার্নেলকে বলে যে সে ইন্টারফেসের মধ্যে প্যাকেট সরাতে পারে; এটি নিজে কিছুই অনুমোদন করে না এবং কোনো পথের নিশ্চয়তা দেয় না। ইগ্রেস বেছে নেওয়া একটি রাউটিং সিদ্ধান্ত। প্যাকেট অনুমোদন করা forward চেইনে নীতির সিদ্ধান্ত। এর উৎস পুনর্লিখন করা postrouting সিদ্ধান্ত। যে নির্মাণ কেবল প্রথমটি করে, সে একটি Raspberry Pi দেয় যা আপলিংক দিয়ে ক্লায়েন্ট ট্রাফিক আনন্দে ফরওয়ার্ড করে।
অনুমতি সেই উৎসগুলোতে সীমাবদ্ধ করুন যা আপনি বোঝাচ্ছেন এবং যে ইন্টারফেসটি ট্রাফিকের ব্যবহার করা উচিত, আর ফিরতি পথ ও Raspberry Pi-র নিজের প্রয়োজনীয় গন্তব্যগুলো অন্তর্ভুক্ত করুন। তারপর টানেল ইগ্রেসে অনুবাদ করুন যদি প্রদানকারী আপনার LAN প্রিফিক্স আপনার দিকে ফিরে রাউট না করে। nftables ম্যানুয়াল ফরওয়ার্ডিং, লোকাল আউটপুট এবং উৎস-অনুবাদকে আলাদা কাজ হিসেবে দেখে, যা এখানে সঠিক মানসিক মডেল।
সাধারণ ব্যর্থতা হলো ফিজিক্যাল ইন্টারফেসে একটি প্রশস্ত masquerade নিয়ম। তখন ট্রাফিক ISP পথে ইন্টারনেটে পৌঁছায়, অথচ ক্লায়েন্টের দিক থেকে দেখতে হুবহু কাজ করা VPN-এর মতো। এটি কিছুই প্রমাণ করে না। অনুবাদকে ঘোষিত ইগ্রেসে বাঁধা রাখুন, এবং আপনার নিয়মগুলো হোস্ট যে ফায়ারওয়াল ইতিমধ্যে ব্যবহার করে সেখানেই রাখুন, একটি প্রতিদ্বন্দ্বী নিয়মসমষ্টি যোগ না করে যা একটি ভাগ করা postrouting চেইন পরিষ্কার করে দেয়।
তারপর টানেলের অনুপস্থিতি সামলান। প্রশস্ত ডিফল্ট রুট ইনস্টল করা একটি ক্লায়েন্ট প্রোফাইল মানে এইও যে টানেল পড়ে গেলে সাধারণ ডিফল্ট ফিরে আসতে পারে এবং ক্লায়েন্ট ট্রাফিক চুপচাপ আপলিংকে ফিরে যায়। যেখানে স্পষ্ট টেক্সটে ফিরে যাওয়া গ্রহণযোগ্য নয়, সেখানে forward নীতিকে ক্লায়েন্ট থেকে আপলিংক ট্রাফিক স্পষ্টভাবে প্রত্যাখ্যান করতে হবে, সেই অবস্থায় যখন VPN রুট চলে গেছে। এটি অনুমান নয়, প্রত্যাখ্যানের নিয়ম হিসেবে লিখুন। VPN সহকর্মীর কাছে Raspberry Pi-র নিজের এনক্রিপ্টেড পরিবহন আলাদা local-output প্রবাহ এবং অনুমোদিত থাকতে হবে, নইলে টানেল কখনও ফিরতে পারবে না।
DNS এবং IPv6-র নিজস্ব উত্তর দরকার
ক্লায়েন্টরা যদি Raspberry Pi-কে রিজলভার হিসেবে ব্যবহার করে, তারা একটি লোকাল লিসেনারে পৌঁছে এবং Raspberry Pi নতুন কোয়েরি শুরু করে। ওই আপস্ট্রিম কোয়েরি ক্লায়েন্টদের জন্য লেখা forward নিয়ম নয়, Raspberry Pi-র নিজের রুট অনুসরণ করে, তাই শুধু টানেল-নির্ভর ক্লায়েন্ট পথ আর সরাসরি বেরোনো রিজলভার — এটি কোনো ত্রুটি বার্তা ছাড়াই একটি লিক। সচেতনভাবে সিদ্ধান্ত নিন: টানেলের ওপর দিয়ে পৌঁছানো রিজলভার, নাকি লোকাল একটি যা সরাসরি হিসেবে মানেন, এবং Raspberry Pi-র নিজের আউটপুট নীতি সেই সিদ্ধান্তের সঙ্গে মিলিয়ে দিন।
IPv6 আবার আলাদা। IPv4-র জন্য forward নিয়ম IPv6 সম্পর্কে কিছুই সীমাবদ্ধ করে না, আর আপলিংকের রাউটার বিজ্ঞাপন Raspberry Pi-কে, এবং তার মধ্য দিয়ে সংযুক্ত সেগমেন্টকে, আপনার নীতি এড়িয়ে যাওয়া দ্বিতীয় ডিফল্ট দিতে পারে। হয় একই নীতিতে IPv6-কে নিজের সুরক্ষিত পথ দিন, নয়তো ক্লায়েন্ট সেগমেন্টে এটি স্পষ্টভাবে সীমাবদ্ধ করুন এবং তা বলুন।
বিশ্বাস করার আগে সীমানা পরীক্ষা করুন
চারটি আলাদা যাচাইয়ের পরেই নকশাটি গ্রহণ করুন, কারণ প্রলুব্ধকারী একক পরীক্ষা — একটি ক্লায়েন্টে ব্রাউজার খোলা — কয়েকটি ভাঙা অবস্থায় পাস করে।
নিশ্চিত করুন একটি বাস্তব ক্লায়েন্ট টানেল দিয়ে ইন্টারনেটে পৌঁছায়, তারপর নিশ্চিত করুন একই ক্লায়েন্ট টানেল বন্ধ থাকলে ইন্টারনেটে পৌঁছাতে পারে না। নিশ্চিত করুন DNS রিজোলিউশন কাজ করে এবং কোয়েরি আপনার ইচ্ছামতো জায়গা থেকে বেরোয়। নিশ্চিত করুন টানেল রিস্টার্টের পরেও Raspberry Pi-র নিজের পরিবহন কাজ করে, এবং পুনরুদ্ধারের জন্য মেশিন রিবুট দরকার হয় না। শেষে, যে ডিভাইসটি আপনি বাছেননি তা পরীক্ষা করুন: লেআউট A-তে সেটি স্বাভাবিকভাবে কাজ চালিয়ে যাবে, আর লেআউট B-তে সেটি ওই সেগমেন্টে আদৌ থাকবে না।
- দুটি পোর্ট আর একটি প্রত্যাখ্যান নিয়ম বলবৎ করে; একটি পোর্ট আর একটি DHCP অপশন পরামর্শ দেয়।
- ভুল ইন্টারফেসে অনুবাদ সাফল্যের মতো দেখায়, কিন্তু সাফল্য নয়।
- Raspberry Pi-র নিজের ট্রাফিক, DNS এবং IPv6 প্রত্যেকেরই একটি সিদ্ধান্ত দরকার, অনুমান নয়।