সাইট-টু-সাইট বনাম রিমোট অ্যাক্সেস VPN: দুটি আসলে কী যুক্ত করে
একটি গেটওয়ে যুক্ত করে, অন্যটি ডিভাইস যুক্ত করে। ট্রাফিক সিলেক্টরগুলিকে রুটের সঙ্গে তুলনা করুন, অ্যাড্রেসিং পরিকল্পনা করুন, তারপর একটি বাস্তব হোস্ট থেকে ফরওয়ার্ডিং ও পলিসি পরীক্ষা করুন।
দুটি ডিজাইনকেই VPN বলা হয় এবং তারা ভিন্ন সমস্যার সমাধান করে। সাইট-টু-সাইট টানেল দুটি গেটওয়ে যুক্ত করে, তাই তাদের পেছনের প্রতিটি হোস্ট কিছু ইনস্টল না করেই অপর দিকের অনুমোদিত ঠিকানায় পৌঁছাতে পারে। রিমোট-অ্যাক্সেস টানেল পৃথক ডিভাইসগুলিকে একটি নেটওয়ার্কের সঙ্গে যুক্ত করে, একবারে একটি ক্লায়েন্ট। তুলনাটি গুরুত্বপূর্ণ, কারণ বেশিরভাগ ডিপ্লয়মেন্ট ভুল হয় একটি কনফিগার করে অন্যটির আচরণ প্রত্যাশা করার ফলে, এবং উপসর্গ সাধারণত এমন একটি সেবায় টাইমআউট যেখানে টানেল সত্যিই পৌঁছেছিল।
দুটি ডিজাইন, দুটি সীমা
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
কোনো ডিজাইনই LAN ব্রডকাস্ট ডোমেইন প্রসারিত করে না। দূরের দিকের ডিভাইসগুলি স্থানীয় ডিসকভারি তালিকায় দেখা যায় না, এবং সেগুলি উপস্থিত হবে বলে আশা করা হলো প্রথম অনুমান যা বাদ দিতে হবে। আপনি ইচ্ছাকৃতভাবে প্রকাশ করা প্রাইভেট DNS নাম যেকোনো ডিসকভারি প্রোটোকলের চেয়ে বেশি পূর্বানুমেয়, এবং সেগুলি সরবরাহকারী পরিবর্তনেও টিকে থাকে।
এক সাইটে 10.10.0.0/24 এবং অন্য সাইটে 10.20.0.0/24 নিন। গেটওয়ে A-এর একটি রুট বা ট্রাফিক সিলেক্টর দরকার যা 10.20.0.0/24 প্রিফিক্সটি টানেলে পাঠায়, আর গেটওয়ে B-এর দরকার তার আয়না প্রতিরূপ। এরপর দুই দিকের হোস্টগুলি সাধারণ IP সংযোগ ব্যবহার করে এবং টানেলের অস্তিত্ব কখনো জানে না। এই অদৃশ্যতাই বৈশিষ্ট্য, এবং এজন্য ব্যর্থতাগুলি টানেলের ত্রুটির বদলে সাধারণ নেটওয়ার্ক ত্রুটির মতো দেখায়।
পলিসি-ভিত্তিক আর রুট-ভিত্তিক একই টানেল নয়
পলিসি-ভিত্তিক IPsec ডিপ্লয়মেন্টে, সমঝোতাকৃত ট্রাফিক সিলেক্টরগুলি ঠিক কোন উৎস ও গন্তব্য জোড়া সুরক্ষিত তা নির্ধারণ করে। যদি একটি গেটওয়ের পিছনে নতুন সাবনেট দেখা দেয় এবং কোনো সিলেক্টর তা কভার না করে, টানেল চালু থাকে এবং নতুন সাবনেটটি কেবল বহন করা হয় না। রুট-ভিত্তিক ডিজাইনে একটি ইন্টারফেস ট্রাফিক গ্রহণ করে এবং রাউটিং টেবিল সিদ্ধান্ত নেয়, যা প্রিফিক্স যোগ করাকে টানেলের পুনর্বার সমঝোতার বদলে রুট পরিবর্তন বানায়।
StrongSwan উভয় দৃশ্যই সরাসরি দেখায়, এবং সেগুলি একসঙ্গে পড়াই বলে দেয় আপনি বাস্তবে কোন মডেল ডিপ্লয় করেছেন।
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'যে সিলেক্টর তালিকায় আপনার প্রয়োজনীয় প্রিফিক্স বাদ পড়েছে তা কোনো প্যাকেট ক্যাপচার ছাড়াই ব্যর্থতার ব্যাখ্যা দেয়, আর ভুল ইন্টারফেসের দিকে নির্দেশ করা রুট ফেরার পথে আয়না-ব্যর্থতার ব্যাখ্যা দেয়। কিছু পুনঃসমঝোতা করার আগে দুটিই পড়ুন, কারণ কী পুনর্নবীকরণ এমন সিলেক্টর যোগ করবে না যা আপনি কখনো কনফিগার করেননি।
টানেলের আগেই অ্যাড্রেসিং পরিকল্পনা করুন
ওভারল্যাপিং রেঞ্জ হলো সেই ডিজাইন ভুল যা কনফিগারেশন দিয়ে ঠিক করা যায় না। যদি দুই সাইটই 192.168.1.0/24 ব্যবহার করে, তবে 192.168.1.50 দরকার এমন হোস্টের দুটি প্রার্থী থাকে এবং বেছে নেওয়ার কোনো উপায় থাকে না। টানেল প্রমাণীকরণ করবে, সিকিউরিটি অ্যাসোসিয়েশনগুলি প্রতিষ্ঠিত হবে, আর রাউটিং সিদ্ধান্ত তবুও ভুল বা অস্পষ্ট থাকবে।
তিনটি সৎ বিকল্পের একটি বেছে নিন: একটি সাইট পুনঃসংখ্যায়িত করুন, গেটওয়েতে ওভারল্যাপিং রেঞ্জ অনুবাদ করুন যাতে প্রতিটি দিক আলাদা প্রিফিক্স দেখে, অথবা সেই হোস্টগুলির জন্য সরাসরি রাউটিং ছেড়ে দিয়ে সেবাটি অন্য উপায়ে প্রকাশ করুন। প্রতিটির একটি খরচ আছে, এবং দুই বছরের দিগন্তে প্রথমটিই সাধারণত সবচেয়ে সস্তা। টানেল তৈরির আগেই সিদ্ধান্ত নিন, কারণ পরে পরিবর্তনটি পুরোনো ঠিকানা থাকা প্রতিটি ডিভাইসকে স্পর্শ করবে।
MTU প্রশ্নটিও আগেভাগে ঠিক করুন। টানেল ব্যবহারযোগ্য পেলোড কমায়, এবং ফ্র্যাগমেন্টেশনের উপর নির্ভর করা ডিজাইন গেটওয়েতে MSS স্থির করা ডিজাইনের চেয়ে ভিন্নভাবে আচরণ করে।
ফরওয়ার্ডিং ও পলিসি টানেলের বাইরে থাকে
গেটওয়েকে টানেল ইন্টারফেস ও LAN ইন্টারফেসের মধ্যে প্যাকেট ফরওয়ার্ড করতে ইচ্ছুক হতে হবে, এবং দুই দিকেরই সেবাটি অনুমোদন করে এমন পলিসি দরকার। লিনাক্সে এগুলি দুটি আলাদা সেটিং, সঙ্গে ফায়ারওয়াল নিয়ম যা ঠিক করে ফরওয়ার্ড হওয়া প্রবাহ আদৌ অনুমোদিত কি না।
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTগ্রহণকারী হোস্ট একটি তৃতীয় স্তর যোগ করে: তার নিজের ফায়ারওয়ালকে এখনও দূরবর্তী সাবনেটের একটি ক্লায়েন্ট গ্রহণ করতে হবে। যে ফাইল সার্ভার কেবল তার স্থানীয় /24 অনুমোদন করে সে 10.20.0.7 থেকে আসা ফরওয়ার্ড হওয়া ট্রাফিক প্রত্যাখ্যান করবে, টানেল যতই সুস্থ দেখাক না কেন, এবং সেই প্রত্যাখ্যানকে রাউটিং ব্যর্থতা হিসেবে পড়া সহজ।
গেটওয়ে থেকে নয়, হোস্ট থেকে পরীক্ষা করুন
গেটওয়ে নিজেই পাঠানো ping ফরওয়ার্ড হওয়া ব্যবহারকারী ট্রাফিকের চেয়ে ভিন্ন উৎস ঠিকানা ও ভিন্ন পলিসি অনুসরণ করতে পারে। এতে এটি দুর্বল পরীক্ষা হয় এবং মাঝে মাঝে বিভ্রান্তিকর: অ্যাপ্লিকেশন ব্যর্থ হলে এটি সফল হয়, বা অ্যাপ্লিকেশন কাজ করলে এটি ব্যর্থ হয়।
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullএকটি বাস্তব হোস্ট, বাস্তব উৎস ঠিকানা এবং অ্যাপ্লিকেশন যে বাস্তব প্রোটোকল ব্যবহার করে তা ব্যবহার করুন। তারপর ফেরার পথটি আলাদাভাবে পড়ুন, কারণ ফেরার রুট ছাড়া কাজ করা সামনের দিক এমন টাইমআউট তৈরি করে যা ব্লক করা সেবার মতোই দেখায়।
আপনি যে প্রশ্নের উত্তর দিচ্ছেন সেই অনুযায়ী ডিজাইন বেছে নিন: আপনি নেটওয়ার্ক যুক্ত করছেন, নাকি ডিভাইস ভর্তি করছেন? বাকি সবকিছু, কোন সরবরাহকারী কনফিগার করবেন তাও, সেই উত্তর থেকেই আসে।