ব্রিজ ছাড়া TAP: রাউটেড আপলিংকসহ একটি ভার্চুয়াল সেগমেন্ট

TAP Ethernet ফ্রেম অপারেটিং সিস্টেমের কাছে হস্তান্তর করে, যা বেশিরভাগ রিমোট-অ্যাক্সেস ডিজাইনের প্রয়োজনের চেয়ে বেশি সামর্থ্য এবং একটি ব্রিজের চেয়ে কম। কার্নেল এটি ঠিকানা দিতে পারে, এর মধ্য দিয়ে রাউট করতে পারে এবং কোনো ভৌত সেগমেন্টে না জুড়েই এতে ফায়ারওয়াল বসাতে পারে। এই বিন্যাসটি প্রথমে বোঝা উচিত: একটি বিচ্ছিন্ন ভার্চুয়াল Ethernet সেগমেন্ট, যার সার্ভার একটি বাস্তব LAN-এর দিকে রাউটার হিসেবে কাজ করে। এটি টানেলের ভেতরে দ্বিতীয় স্তরের আচরণ এবং বাইরে সাধারণ IP ফরওয়ার্ডিং দেয়, যা দুটি ভিন্ন প্রতিশ্রুতি। এর বাকিটা হলো নির্মাণ, রুট, ফেরার পথ এবং রোলব্যাক।

বিচ্ছিন্ন সেগমেন্ট তৈরি করুন

লিনাক্সে ইন্টারফেসটি তিনটি কমান্ড নেয়: এটি তৈরি করুন, এটি চালু করুন, আপনি যে সেগমেন্ট চান তার ভেতরে এটিকে একটি ঠিকানা দিন। অফিস LAN-এর সঙ্গে সংঘর্ষ করে না এমন একটি প্রিফিক্স বেছে নিন এবং তা লিখে রাখুন, কারণ কোনো হোস্ট উত্তর দেওয়া পর্যন্ত সংঘর্ষটি অদৃশ্য থাকে, যা থাকা উচিত নয়।

ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0

এখানে কিছুই ব্রিজ দাবি করে না, এবং পরে একটি যোগ করতে কিছুই বাধা দেয় না। কার্নেল TUN/TAP ডকুমেন্টেশন ইন্টারফেসটির নিজের বর্ণনা দেয়; ব্রিজের সদস্যপদ ও ফরওয়ার্ডিং নীতি পৃথক সিদ্ধান্ত, যা আপনি পরে নেন।

সীমানা পেরিয়ে রাউট করুন

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

রুট ও ফায়ারওয়াল নিয়মকে এক পরিবর্তন হিসেবে লিখুন, কারণ প্রতিটি আলাদাভাবে এমন অবস্থা তৈরি করে যা ক্লায়েন্টের দিক থেকে রাউটিং ব্যর্থতার মতো দেখায়।

ফেরার পথ ঠিক করুন

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

যা টাইপ করা দ্রুত তার ভিত্তিতে নয়, সচেতনভাবে বেছে নিন। একটি রাউটেড প্রিফিক্স সাধারণত অনুবাদের চেয়ে পরিষ্কার, এবং একটি ল্যাবের জন্য অনিয়ন্ত্রিত রাউটারকে নতুন প্রিফিক্স শেখানোর চেয়ে অনুবাদ সাধারণত ভালো।

ব্রডকাস্টের পরিধি সচেতনভাবে রাখুন

ভার্চুয়াল সেগমেন্টের ভেতরে DHCP, ডিসকভারি ও প্রতিবেশী ঘোষণা একটি সুইচের মতো আচরণ করে, কারণ এটি একই লিংক। রাউটেড সীমানার ওপারে তারা তা করে না, তাই অফিস DHCP ও সার্ভিস ডিসকভারির জন্য স্পষ্ট নকশা দরকার, TAP সেগুলো বোঝায় এমন ধারণা নয়। ইন্টারফেসের ধরন অন্য কোথাও থাকা সার্ভিসের জন্য রিলে নয়।

TAP বেছে নেওয়ার সৎ কারণ এটিই: ভার্চুয়াল সেগমেন্টের কোনো কিছুকে লিংক-লোকাল আচরণ দরকার। কিছুই না দরকার হলে, রাউটেড প্রিফিক্সসহ একটি TUN ডিভাইস ছোট, এবং ভাঙলে ব্যাখ্যা করারও কম থাকে।

যাচাই করুন, তারপর রোলব্যাক লিখুন

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

যদি প্রয়োজন সত্যিই দুই সাইট জুড়ে এক Ethernet সেগমেন্ট হয়, ব্রিজই সৎ উত্তর এবং ভিন্ন প্রভাব-ব্যাসার্ধের ভিন্ন নকশা। যদি প্রয়োজন নাগাল হয়, রাউটেড আপলিংকসহ বিচ্ছিন্ন সেগমেন্টটি পরে কম ব্যাখ্যা দিয়েই কাজটি করে।