VPN-এর জন্য UFW ব্যতিক্রম যখন এন্ডপয়েন্টের ঠিকানা বদলায়

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

টানেল আবার সংযুক্ত হয়, তারপর কিছুই বের হয় না

গন্তব্য ঠিকানার নাম নেওয়া একটি আউটবাউন্ড নিয়ম একটি তাৎক্ষণিক ছবি, আর DNS-এর উত্তর তা নয়। প্রদানকারী ঠিকানা ঘোরালে ক্লায়েন্টের নতুন পিয়ারের দিকে পাঠানো প্যাকেট কিছুর সঙ্গে মেলে না এবং ডিফল্ট নিষেধাজ্ঞায় ফেলে দেওয়া হয়। এরপর ক্লায়েন্ট সময় শেষ হওয়ার কথা জানায়, যা সার্ভারের সমস্যার মতো শোনায়, ফায়ারওয়ালের নয়।

সর্বজনীন অনুসন্ধান যে ঠিকানা ফেরত দেয় তা পিন করে রাখলে আজ কাজ করে আর কাল ভাঙা থাকে। এটি এককালীন সম্পাদনা, রক্ষণাবেক্ষণের নীতি নয়।

আপনি যে ব্যতিক্রমটি সত্যিই চান তা বর্ণনা করুন

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

নিচের কমান্ডটি তারযুক্ত আপলিংকে একটি IPv4 UDP এন্ডপয়েন্টের আকৃতি দেখায়। দুটি মানই আপনার স্থাপনার বিপরীতে যাচাই করা মান দিয়ে বদলান।

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

ঐ অনুমতি একই পোর্টে ইচ্ছামতো গন্তব্য দেয় না, শ্রোতা তৈরি করে না এবং TCP ঢাকে না। UFW-এর ম্যানুয়াল পৃষ্ঠা বর্ণনা করে কীভাবে ঠিকানা, ইন্টারফেস ও প্রোটোকল একটি নিয়ম সংকুচিত করে, এবং সেই সংকোচনই পুরো বিষয়।

এটিকে একটি ওয়ার্কফ্লো হিসেবে সতেজ করুন

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

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

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

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

পুরনো অনুমতিটি সচেতনভাবে প্রত্যাহার করুন

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

আপলিংক Ethernet থেকে Wi-Fi-তে বদলালে, ট্রান্সপোর্ট বদলালে, বা কোনো সেবা একাধিক ঠিকানায় ঘুরলে পুরো পর্যালোচনা পুনরাবৃত্তি করুন। ইন্টারফেস-নির্দিষ্ট নিয়মের নেটওয়ার্ক বদলের পর মেলা বন্ধ করা উচিত, এবং সেই আচরণ সঠিক যদিও তা পতনের মতো দেখায়।

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