Mac-এ PF VPN লক: একটি সাইট নীতি, বিতরণযোগ্য ফিচার নয়
Packet Filter বিতরণকৃত পণ্যের জন্য সমর্থিত API নয়। নিয়মের সেটকে একটি মালিক দিন, প্রতিটি ব্যতিক্রমের নাম দিন এবং রূপান্তরগুলি পরীক্ষা করুন।
এটি আপনার Mac-এ কাজ করে, তাই মনে হয় এটি ব্যবহারকারীদের হাতে দেওয়া যায়। এই ধারণাটিই প্রথমে ছাড়তে হবে। Apple-এর TN3165 স্পষ্টভাবে বলে যে Packet Filter সাধারণভাবে বিতরণ করা পণ্যের জন্য সমর্থিত API নয়, এবং এটি বিশেষাধিকারপ্রাপ্ত, নিয়ন্ত্রিত সাইট প্রশাসনকে যুক্তিসঙ্গত ক্ষেত্র হিসেবে উপস্থাপন করে। তাই PF-এর উপর নির্মিত VPN লক একটি মালিকসহ স্থানীয় পরিচালন নীতি, কোনো অ্যাপের ভিতরে বিতরণযোগ্য ফিচার নয়।
PF কোনো প্যাকেজিং পৃষ্ঠ নয়
এই পার্থক্য তাত্ত্বিক নয়। PF-এর উপর নির্ভরশীল একটি বিতরণকৃত পণ্য Apple যেকোনো পরিবর্তন করে তা উত্তরাধিকারসূত্রে পায়, অন্য কোনো টুলের সঙ্গে প্রতিটি সংঘর্ষও যা নিয়ম লেখে, এবং এই ব্যবস্থা চলতে থাকবে বলে কোনো সমর্থন প্রতিশ্রুতি পায় না। যে সাইট নিজের মেশিন নিজে পরিচালনা করে তার সম্পর্ক ভিন্ন: সে নির্ভরতাটি নথিভুক্ত করতে পারে, প্রতিটি OS সংস্করণের বিরুদ্ধে পরীক্ষা করতে পারে এবং রক্ষণাবেক্ষণ মেনে নিতে পারে।
কিছু ইনস্টলেশন পরামর্শ এমন একটি সীমা অতিক্রম করে যা নাম দেওয়া উচিত। একটি অ্যাঙ্কর লোড করার জন্য সম্পূর্ণ সিস্টেম নিয়মের সেট পুনর্লিখন করা, Apple-এর সিস্টেম লঞ্চ কনফিগারেশন সম্পাদনা করা, বা System Integrity Protection নিষ্ক্রিয় করা পুনরায় ব্যবহারযোগ্য রেসিপির জন্য গ্রহণযোগ্য প্রয়োজনীয়তা নয়। যদি প্রকাশিত কোনো নির্দেশিকায় এগুলির যেকোনোটি দরকার হয়, তবে সেটি একটি ল্যাব বর্ণনা করছে, স্থাপনযোগ্য নীতি নয়।
সিনট্যাক্সের আগে বের হওয়ার উদ্দেশ্য লিখুন
একটি কীওয়ার্ড বাছার আগেই ঠিক করুন কী অনুমোদিত। সাধারণত তিনটি পথ থাকা দরকার: VPN ক্লায়েন্টের নিজের সার্ভারে পরিবহন, টানেলের ভিতরে সুরক্ষিত অ্যাপ্লিকেশন ট্র্যাফিক, এবং যেসব সেটআপ বা স্থানীয় সেবার সত্যিই সরাসরি পথ দরকার।
প্রতিটি প্রস্তাবিত ব্যতিক্রমকে একটি গন্তব্য, একটি পরিবহন এবং একটি মালিক দিন। একটি এন্ডপয়েন্টে সব পোর্ট অনুমোদন করা টানেল যে একমাত্র পরিবহন ব্যবহার করে তার চেয়ে অনেক বেশি অনুমতি দেয়, এবং অতিরিক্ত এক্সপোজার আসে কেউ সিদ্ধান্ত না নিয়েই যে তা থাকা উচিত। পাবলিক রিজলভার অনুমোদন করা আরও বন্ধুত্বপূর্ণ পোশাকে একই ফাঁদ: এটি টানেল বন্ধ থাকলেও সরাসরি DNS পথ তৈরি করে, তাই নাম অনুসন্ধান এখনও ফাঁস হয়।
| Path | Destination | Owner |
|---|---|---|
| VPN transport | Gateway address, one UDP port | Network team |
| Tunnel traffic | Internal prefixes | Application owner |
| Resolver exception | Named internal resolver | Security team |
ব্যতিক্রমের জন্য দরকারি পরীক্ষা হলো আপনি কি সেই ব্যক্তির নাম বলতে পারেন যে এটি চেয়েছে এবং যে ব্যর্থতা এটি প্রতিরোধ করে। যদি দুটির কোনোটির উত্তর না থাকে, তবে নিয়মটি সম্ভবত একটি ভুল কনফিগারেশনের ঘুরপথ যা না হলে অদৃশ্য থেকে যেত।
utun নম্বর কোনো পরিচয় নয়
MacOS টানেল ইন্টারফেস তৈরি করে utun ডিভাইস হিসেবে, এবং আপনার VPN-এ বরাদ্দ নম্বরটি স্থিতিশীল নয় রিবুট, পুনঃসংযোগ বা অন্য কোনো ক্লায়েন্টের উপস্থিতি জুড়ে। কয়েকটি অনুমিত নম্বরের তালিকা করা নিয়ম কোনো নীতি নয়; এটি এক বিকেলের একটি স্ন্যাপশট।
নিয়মটিকে এমন কিছুতে নোঙর করুন যা অভীষ্ট প্রদানকারীকে শনাক্ত করে: টানেল যে ঠিকানা পরিকল্পনা বরাদ্দ করে, ইন্টারফেসের মালিক প্রক্রিয়াটি, বা VPN ক্লায়েন্ট নিজেই যে কনফিগারেশন রক্ষণাবেক্ষণ করে। তারপর লিখে রাখুন সেই শনাক্তকরণ কীভাবে কাজ করে, কারণ এক বছর পরে নিয়মটি পর্যালোচনা করা ব্যক্তির আপনার শেল ইতিহাস থাকবে না।
লোড করা নীতিকে আরোপণযোগ্য করুন
অ্যাঙ্করের নাম নিয়ম সংগঠিত করে; এটি প্রমাণ করে না যে কার্যকর নীতি আপনার উদ্দিষ্ট জিনিস। অ্যাঙ্করগুলির মধ্যে অগ্রাধিকার, অন্য সফটওয়্যার লোড করা নিয়ম, এবং বিদ্যমান অবস্থা—সবই ফলাফল বদলাতে পারে। সেই মেশিনে PF-এর অন্য মালিকের সঙ্গে কার্যকর সেটটি পর্যালোচনা করুন, এবং কনফিগারেশনের মতো একই জায়গায় মালিকানা নথিভুক্ত করুন। ভিন্ন অনুমানে ভিন্ন অ্যাঙ্কর সম্পাদনা করা দুই মালিকই সাধারণত লকে ফুটো তৈরির পথ।
নিয়মের সেটটি সাইটের সমর্থিত কনফিগারেশন পথে রাখুন, সংস্করণ করুন, এবং কোন macOS সংস্করণ পরীক্ষা করা হয়েছে তা লিখুন। হাতে প্রয়োগ করা এবং একজনের মনে রাখা পরিবর্তন রক্ষণাবেক্ষণাধীন অবকাঠামো নয়, ফাইলের শিরোনাম যা-ই বলুক।
সংযুক্ত অবস্থা নয়, রূপান্তরগুলি পরীক্ষা করুন
টানেল চালু থাকার সময় নেওয়া স্ক্রিনশট প্রায় কিছুই প্রমাণ করে না। বরং অবস্থাগুলির মধ্য দিয়ে হাঁটুন: কোনো সংযোগের আগে স্টার্টআপ, কাজ করা টানেল, সতর্কতা ছাড়া পড়ে যাওয়া টানেল, ইচ্ছাকৃত সংযোগ বিচ্ছিন্ন, এবং Wi-Fi থেকে হটস্পটে যাওয়া। প্রতিটি অবস্থার নিজস্ব উত্তর আছে, এবং আকর্ষণীয়গুলি সুখী পথ নয়, ব্যর্থতাগুলি।
প্রতিটি অবস্থায় ইচ্ছাকৃতভাবে কী পৌঁছানো যায় তা লিখুন। IPv4 এবং IPv6 আলাদাভাবে পরীক্ষা করুন, নাম সমাধান পরীক্ষা করুন, এবং রূপান্তরের আগে ইতিমধ্যে প্রতিষ্ঠিত একটি প্রবাহ অন্তর্ভুক্ত করুন, কারণ বিদ্যমান সংযোগ সবসময় নতুন নীতি অনুসরণ করে না। টানেল বন্ধ থাকলে ব্যর্থ হওয়া ব্রাউজার একটি তথ্যবিন্দু, অন্য সব পথ অবরুদ্ধ থাকার প্রমাণ নয়।
সবশেষে, এমন একটি পুনরুদ্ধার পদ্ধতি রাখুন যা আপনি যে নেটওয়ার্ক পথ বদলাচ্ছেন তার উপর নির্ভর করে না। স্থানীয় স্টোরেজে একটি জানা-ভালো কনফিগারেশন এবং তা লোড করার নথিভুক্ত উপায় একটি লককে নীতিতে পরিণত করে; সেগুলি ছাড়া একটি খারাপ সংশোধন প্রশাসককে সেই মেশিন থেকে বের করে দেয় যা সুরক্ষিত হওয়ার কথা ছিল।