VPN-এর পিছনে IoT সেন্সর বসানোর আগে ঠিকানা নিয়ে তিনটি সিদ্ধান্ত
তিনটি ঠিকানা তিনটি কাজ করে: সার্বজনীন হাব, প্রমাণিত সাইট পিয়ার এবং সেন্সরের নিজস্ব ব্যক্তিগত ঠিকানা। সার্বজনীন কিছু বরাদ্দ করার আগে প্রতিটি পরিকল্পনা করুন।
প্রতিটি IoT-জুড়ে-VPN পরিকল্পনায় তিনটি ঠিকানা জড়িয়ে যায়, আর সেগুলো একই ধরনের সিদ্ধান্ত নয়। একটি হলো দূরবর্তী অপারেটর কীভাবে টানেলের প্রান্ত খুঁজে পায়, একটি হলো সাইট কীভাবে প্রমাণ করে যে সে-ই সাইট, আর একটি হলো সেন্সরের সেবা আসলে কোথায় শোনে। এই ক্রমে উত্তর দিন, আর নকশা প্রায় নিজেই বেরিয়ে আসবে। একটিমাত্র প্রশ্ন হিসেবে উত্তর দিন, আর আপনি পৌঁছে যাবেন এমন ডিভাইসে সার্বজনীন ঠিকানা বরাদ্দ করতে, যাদের কখনোই তা দরকার ছিল না। আউটবাউন্ড সাইট টানেলের পিছনে থাকা সেন্সর অনুমোদিত অপারেটরের কাছে পৌঁছানো যায়, সেন্সরের দিকে কোনো ইনবাউন্ড নিয়ম ছাড়াই।
শুরু করুন কে শুরু করে তা দিয়ে
কে ডায়াল করে তা প্রায় সবকিছুই নির্ধারণ করে। সাইট যখন হাবে ডায়াল করে, সাইটের কোনো ইনবাউন্ড পৌঁছানোর ক্ষমতা দরকার হয় না, আর হাবের দরকার হয় এমন নাম বা ঠিকানা যা সাইট রিজলভ করতে পারে। এই একটি পছন্দই স্থির সার্বজনীন ঠিকানা-বিতর্কের বেশিরভাগ অংশ শুরু হওয়ার আগেই সরিয়ে দেয়।
এরপর তিনটি ভূমিকা পরিষ্কারভাবে আলাদা হয়, আর নিচের সারণিটি সিদ্ধান্তের সবচেয়ে সংক্ষিপ্ত রূপ।
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
প্রতিটি সারির মালিক আলাদা, আর এটাই আসল কথা। হাব কারও যিনি VPN সেবা চালান, সাইট পিয়ার নেটওয়ার্ক দলের, আর সেন্সরের ঠিকানা কারও যিনি ডিভাইসটির মালিক।
হাবের ঠিকানা বুটস্ট্র্যাপ, গন্তব্য নয়
রক্ষণাবেক্ষণ করা সার্বজনীন ঠিকানায় রিজলভ হওয়া একটি নাম হাবের জন্য যথেষ্ট। DNS রেকর্ড প্রান্তটি সরে গেলে তাকে অনুসরণ করতে পারে, প্রতিটি সাইট কনফিগারেশন হাতে সম্পাদনা না করেই। DNS যা করে না তা হলো পৌঁছানোর ক্ষমতা তৈরি করা বা পুরোনো উত্তর ক্যাশ করা ক্লায়েন্টকে রিফ্রেশ করা, আর এসব আলাদা সমস্যা, আলাদা সমাধান।
হাব ছাড়া সাইট-থেকে-সাইট টানেল চালালে একই যুক্তি ভিন্ন আকারে খাটে: এক পক্ষের পৌঁছানো যায় এমন প্রান্ত দরকার, অথবা দুই পক্ষই তৃতীয় পক্ষকে ডায়াল করে। কাউকে তবুও ওই ঠিকানার ও তার নবায়নের মালিক হতে হয়।
সাইট পিয়ার হলো প্রিফিক্স জুড়ে দেওয়া একটি পরিচয়
পিয়ার প্রথমে পরিচয়, দ্বিতীয়ে প্রিফিক্স। WireGuard-এর ভাষায় পিয়ার একটি কী জোড়া ধরে রাখে এবং হাবের AllowedIPs এন্ট্রি সেই কী-কে সাইটের প্রিফিক্সে বেঁধে দেয়। IKEv2-এর ভাষায় একটি সার্টিফিকেট বা আগে-ভাগ-করা কী সাইটকে চিহ্নিত করে এবং তার ট্রাফিক সিলেক্টর বলে দেয় সে কী বহন করতে পারে। যেকোনো একটি অর্ধেক আলাদাভাবে বদলালে ব্যবস্থাটি ভেঙে যায়, তাই ঠিকানা বদলকে কখনোই পরিচয় বদল হিসেবে গণ্য করা উচিত নয়।
কী বা সার্টিফিকেটের মালিকানা সাইটের হাতে রাখুন, হাব অপারেটরের হাতে নয়, যাতে সরবরাহকারী বদল পরিচয় বদলে পরিণত না হয়।
প্রিফিক্স হলো সেই অংশ যা মানুষ পরিকল্পনা করতে ভুলে যায়। হাবকে সেন্সর সাবনেটকে সঠিক পিয়ারের সঙ্গে যুক্ত করতে হয়, আর অপারেটরের ক্লায়েন্টের এর জন্য একটি রুট দরকার; যে রুট কেবল ক্লায়েন্টে থাকে তা ট্রাফিককে এমন টানেলে পাঠায় যা নিঃশব্দে তা ফেলে দেয়। কী-এর ফিঙ্গারপ্রিন্টের পাশে সাইট রেকর্ডে প্রিফিক্সটি লিখুন, যাতে প্রতিস্থাপিত গেটওয়ে অলক্ষ্যে ভিন্ন কভারেজ নিয়ে উঠে আসতে না পারে।
সেন্সরের ঠিকানা অ্যাপ্লিকেশনের
সাইটের পরিকল্পনা থেকে একটি ব্যক্তিগত ঠিকানাই যথেষ্ট, আর তার দরকার সার্বজনীন পৌঁছানো নয়, স্থিতিশীলতা: একটি DHCP সংরক্ষণ, একটি স্থির বরাদ্দ, বা সাইটের নিজের জোনে একটি নাম। ডিভাইসটি যদি পুনঃসংখ্যায়িত করা না যায়, সাইট গেটওয়েতে অনুবাদ একটি বৈধ উত্তর, যতক্ষণ অনুবাদটি নথিভুক্ত এবং ফেরত ট্রাফিক তা অনুসরণ করে।
আরও একটি অভ্যাস ধরে রাখা উচিত: সেন্সরের হোস্টে পরবর্তী-হপ ক্ষেত্রে কখনোই সার্বজনীন হাবের ঠিকানা পেস্ট করবেন না। VPN নিজের পথ বসায়, আর একটি সার্বজনীন প্রান্তের সঙ্গে সাধারণ ইথারনেট সন্নিবেশ একটি কল্পকথা যা বিশ্বাসযোগ্য দেখতে কনফিগারেশন তৈরি করে।
উত্তরগুলোই সেই অর্ধেক যা বাদ পড়ে। ডিভাইসকে তার উত্তর টানেলের দিকে ফেরত পাঠাতে হয়, হয় অপারেটরের ক্লায়েন্টের দিকে একটি রুট দিয়ে, নয় যে গেটওয়ে অনুরোধটি অনুবাদ করেছে তার মধ্য দিয়ে। ভুল ডিফল্ট গেটওয়ে থাকা সেন্সর অনুরোধ গ্রহণ করে এবং শূন্যে উত্তর দেয়, আর ফরওয়ার্ডিং নোট ব্যাখ্যা করে কেন আগমন ও উত্তর রাউটিং এক নয়, দুটি প্রয়োজন।
সিদ্ধান্ত নিন, তারপর সীমা লিখুন
কেউ সংযোগ করার আগেই অ্যাক্সেস সীমা লিখে রাখুন। গেটওয়েকে IoT সেগমেন্টে এবং অপারেটরের প্রয়োজনীয় নির্দিষ্ট সেবায় সীমিত রাখুন, কারণ কাজ করা রুট দুর্ঘটনাক্রমে সাধারণ অ্যাক্সেস হয়ে যাওয়ার প্রবণতা রাখে। শুধু-পড়ার মনিটরিং আর কনফিগারেশন কর্তৃত্বকে আলাদা পরিচয়সহ আলাদা ভূমিকা হিসেবে রাখুন, এবং চুক্তি শেষে কে অ্যাক্সেস সরাবে তার নাম লিখুন।
অনুমোদন নেটওয়ার্ক মালিকের, আর DMZ-এ থাকা কোনো অ্যাক্সেস নীতি নয়।
স্থাপনার পরের পরীক্ষাটি নীরস এবং চূড়ান্ত: অনুমোদিত প্রিফিক্সের ভিতরে একটি অনুরোধ যা সফল হয়, গেটওয়েতে একটি কাউন্টার যা বাড়ে, এবং প্রিফিক্সের বাইরে একটি ইচ্ছাকৃত প্রচেষ্টা যা ব্যর্থ হয়।