VPN গেটওয়ের পিছনে Wi-Fi অ্যাক্সেস পয়েন্ট: একটি LAN রাখুন

ওয়্যারলেস ক্লায়েন্টরা VPN-এর পিছনে থাকতে পারে, অথচ অ্যাক্সেস পয়েন্ট টানেল সম্পর্কে কিছুই জানে না। রেডিওকে গেটওয়ের LAN-এ ব্রিজ করুন, অ্যাড্রেসিং ও টানেল গেটওয়ের হাতে রাখুন, তাহলে Wi-Fi-এর প্রতিটি ডিভাইস একই পলিসি উত্তরাধিকারে পায়। বিকল্পটি, নিজস্ব গেটওয়ে সহ দ্বিতীয় রাউটেড সেগমেন্ট, ভিন্ন ব্যর্থতার ধরনসহ ভিন্ন এক নকশা।

দুটোকে গুলিয়ে ফেলা হয় কারণ দুটোই ইন্টারনেট ও আপনার ডিভাইসের মাঝে একটি বক্স রাখে। কোনটি কী মালিকানা রাখে তা তুলনা করাই বেছে নেওয়ার দ্রুততম উপায়।

Wi-Fi-এর সামনে VPN বসানোর দুই উপায়

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

internet
  -> vpn-capable gateway: routing, tunnel, dns, failure policy
  -> bridged access point: radio onto the same lan
  -> wifi clients

চাহিদা যদি হয় ওয়্যারলেস ডিভাইস তারযুক্ত ডিভাইসের মতো একই টানেল ব্যবহার করবে, তবে ব্রিজড বেছে নিন। আপনি যদি বিচ্ছিন্ন করা যায় এমন সেগমেন্ট চান, বা দ্বিতীয় বক্সটি আগেই রাউটার হিসেবে থাকে, তবে রাউটেড বেছে নিন।

ব্রিজড বিন্যাস আসলে কী বদলায়

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

রেডিও টানেল থেকে এসবের কিছুই স্বয়ংক্রিয়ভাবে উত্তরাধিকারে পায় না। এটি কেবল এমন স্তর যোগ করা বন্ধ করে যা সেটিকে ঢেকে দিত।

দ্বিতীয় রাউটেড সেগমেন্ট কোথায় মানায়

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

সাধারণ ভুল হলো দুর্ঘটনাক্রমে রাউটেড সংস্করণটি বানানো—এমন একটি রাউটার পুনর্ব্যবহার করে যেটি এখনো নিজের DHCP ও অনুবাদ চালায়। তাতে দ্বিগুণ অনুবাদ আর এমন পলিসি তৈরি হয় যা কেউ অনুসরণ করতে পারে না।

গেটওয়ে থেকে নয়, Wi-Fi ক্লায়েন্ট থেকে পরীক্ষা করুন

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

ip -4 addr show wlan0
ip route get 1.1.1.1
curl -sS https://api.ipify.org; echo
traceroute -n -m 4 1.1.1.1

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

প্রতিটি বক্সের ভূমিকা, তার ঠিকানা ও DHCP কর্তৃপক্ষ লিখে রাখুন। তিন লাইনের একটি চিত্রই যথেষ্ট, আর তা নিয়ম কোথায় বসবে তা নিয়ে বেশিরভাগ বিতর্ক মিটিয়ে দেয়।