শাখার একটি সাবনেট হেডকোয়ার্টারের SonicWall ইন্টারনেট এক্সিট দিয়ে রুট করুন

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

সিলেক্টর দিয়ে শুরু করুন, রুট দিয়ে নয়

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

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

শাখার নীতি যোগ করুন, তারপর তার ক্রম রক্ষা করুন

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

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

হেডকোয়ার্টারে পথটি শেষ করুন

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

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

টানেল পড়ে গেলে গ্রুপ কী করবে তা ঠিক করুন

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

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

তিনটি ক্লায়েন্ট থেকে যাচাই করুন, তারপর পরিচ্ছন্নভাবে রোলব্যাক করুন

কেন্দ্রীয় গেটওয়েতে পিং ভুল জিনিস পরীক্ষা করে, কারণ এটি ফায়ারওয়াল থেকে উৎপন্ন হয়, নির্বাচিত ক্লায়েন্ট থেকে নয়। বরং ডিভাইস থেকে পরীক্ষা করুন, এবং সেগুলোর তিনটি পরীক্ষা করুন: একটি নির্বাচিত ডিভাইস, একটি সাধারণ ডিভাইস যা স্থানীয় থাকা উচিত, এবং একটি যা স্থানীয় সেবার ওপর নির্ভর করে।

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

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

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