স্প্লিট টানেলিং বনাম কোম্পানির নীতি: কোন নিয়ম জেতে

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

চেকবক্স নিয়ে তর্ক করার আগে নির্ধারণ করুন নীতিটি কোন বৈশিষ্ট্য রক্ষার জন্য আছে।

নিয়মের পিছনের বৈশিষ্ট্য

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

চতুর্থ দল এন্ডপয়েন্ট পোস্টচার প্রয়োগ করে: ডিস্ক এনক্রিপশনের অবস্থা, প্যাচের মাত্রা, এজেন্টের স্বাস্থ্য। টানেল ভাগ করলে এসব বদলায় না, কিন্তু এজেন্টের নিজের ট্রাফিক এড়ানো বাইপাস বদলাতে পারে।

এগুলো চারটি ভিন্ন দাবি, আর প্রতিটি ভিন্ন ব্যতিক্রমে ভাঙে। পরিবর্তন প্রস্তাবের আগে দাবিটি পড়ুন, কারণ যিনি লিখেছেন তিনি সঙ্গে সঙ্গে বলতে পারবেন কোনটি প্রযোজ্য। ভুলটিকে সন্তুষ্ট করা পরিবর্তন কিছুই কিনে না।

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

পরীক্ষাগুলো ক্রমে চালান

নিচের ক্রমটি ব্যতিক্রমটিকে সত্যিই ব্যর্থ হওয়া ক্ষুদ্রতম জিনিসে সীমিত করে। যে পরীক্ষাটি টেকে না সেখানেই থামুন, কারণ পরের কোনো সমাধান আগের ঘাটতি পূরণ করতে পারে না।

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

প্রতিটি উত্তর একটি তথ্য, আর ব্যতিক্রমের অনুরোধে তথ্যই দরকার। VPN বিরক্তিকর কি না তা নিয়ে তর্ক তার মধ্যে নয়। কথাবার্তা শুরুর আগে উত্তরগুলো লিখে রাখুন।

সংকীর্ণ ব্যতিক্রম চান

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

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

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

ব্যতিক্রমটিকে টেকসই করুন

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

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

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

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