eBPF ট্রাফিক মনিটরিং

eBPF নেটওয়ার্ক ট্র্যাফিক টুলটি শেষ ডিভাইস বুট করার পর থেকে ডিভাইসে নেটওয়ার্ক ব্যবহার নিরীক্ষণের জন্য কার্নেল এবং ব্যবহারকারীর স্থান বাস্তবায়নের সংমিশ্রণ ব্যবহার করে। এটি ফোনের অবস্থার উপর নির্ভর করে নেটওয়ার্ক অ্যাক্সেস থেকে অ্যাপগুলিকে ব্লক করার জন্য সকেট ট্যাগিং, ফোরগ্রাউন্ড/ব্যাকগ্রাউন্ড ট্র্যাফিক পৃথকীকরণ এবং প্রতি-UID ফায়ারওয়ালের মতো অতিরিক্ত কার্যকারিতা প্রদান করে। টুল থেকে সংগৃহীত পরিসংখ্যান eBPF maps নামক একটি কার্নেল ডেটা কাঠামোতে সংরক্ষণ করা হয় এবং ফলাফলটি NetworkStatsService এর মতো পরিষেবাগুলি দ্বারা শেষ বুট থেকে স্থায়ী ট্র্যাফিক পরিসংখ্যান প্রদানের জন্য ব্যবহার করা হয়।

উদাহরণ এবং উৎস

ইউজারস্পেস পরিবর্তনগুলি মূলত system/netd এবং framework/base প্রকল্পগুলিতে হয়। AOSP তে ডেভেলপমেন্ট করা হচ্ছে, তাই AOSP কোড সর্বদা আপ টু ডেট থাকবে। উৎসটি মূলত system/netd/server/TrafficController* , system/netd/bpfloader এবং system/netd/libbpf/ এ অবস্থিত। কিছু প্রয়োজনীয় ফ্রেমওয়ার্ক পরিবর্তন framework/base/ এবং system/core করা হয়।

বাস্তবায়ন

অ্যান্ড্রয়েড ৯ দিয়ে শুরু করে, কার্নেল ৪.৯ বা তার উপরে চলমান এবং মূলত P রিলিজের সাথে পাঠানো অ্যান্ড্রয়েড ডিভাইসগুলিতে xt_qtaguid এর পরিবর্তে eBPF-ভিত্তিক নেটওয়ার্ক ট্র্যাফিক মনিটরিং অ্যাকাউন্টিং ব্যবহার করা আবশ্যক। নতুন অবকাঠামোটি আরও নমনীয় এবং আরও রক্ষণাবেক্ষণযোগ্য এবং কোনও আউট-অফ-ট্রি কার্নেল কোডের প্রয়োজন হয় না।

লিগ্যাসি এবং eBPF ট্র্যাফিক পর্যবেক্ষণের মধ্যে প্রধান নকশার পার্থক্যগুলি চিত্র 1 এ চিত্রিত করা হয়েছে।

লিগ্যাসি এবং eBPF ট্র্যাফিক পর্যবেক্ষণ নকশার পার্থক্য

চিত্র ১. লিগ্যাসি (বামে) এবং eBPF (ডানে) ট্র্যাফিক পর্যবেক্ষণ নকশার পার্থক্য

নতুন trafficController ডিজাইনটি কার্নেলের ভিতরে per- cgroup eBPF ফিল্টারের পাশাপাশি xt_bpf netfilter মডিউলের উপর ভিত্তি করে তৈরি। এই eBPF ফিল্টারগুলি ফিল্টারের মধ্য দিয়ে যাওয়ার সময় প্যাকেট tx/rx-এ প্রয়োগ করা হয়। cgroup eBPF ফিল্টারটি ট্রান্সপোর্ট লেয়ারে অবস্থিত এবং সকেট UID এবং ইউজারস্পেস সেটিং-এর উপর নির্ভর করে সঠিক UID-এর বিপরীতে ট্র্যাফিক গণনা করার জন্য দায়ী। xt_bpf নেট ফিল্টারটি bw_raw_PREROUTING এবং bw_mangle_POSTROUTING চেইনে সংযুক্ত এবং সঠিক ইন্টারফেসের বিপরীতে ট্র্যাফিক গণনা করার জন্য দায়ী।

বুট করার সময়, ইউজারস্পেস প্রসেস trafficController ডেটা সংগ্রহের জন্য ব্যবহৃত eBPF ম্যাপ তৈরি করে এবং সমস্ত ম্যাপকে sys/fs/bpf এ ভার্চুয়াল ফাইল হিসেবে পিন করে। তারপর privileged প্রসেস bpfloader প্রি-কম্পাইল করা eBPF প্রোগ্রামটিকে কার্নেলে লোড করে এবং সঠিক cgroup এর সাথে সংযুক্ত করে। সমস্ত ট্র্যাফিকের জন্য একটি একক রুট cgroup থাকে তাই ডিফল্টরূপে সমস্ত প্রক্রিয়াটি সেই cgroup এ অন্তর্ভুক্ত করা উচিত।

রান টাইমে, trafficController traffic_cookie_tag_map এবং traffic_uid_counterSet_map লিখে একটি সকেট ট্যাগ/আনট্যাগ করতে পারে। NetworkStatsService traffic_tag_stats_map , traffic_uid_stats_map এবং traffic_iface_stats_map থেকে ট্র্যাফিক পরিসংখ্যান ডেটা পড়তে পারে। ট্র্যাফিক পরিসংখ্যান সংগ্রহ ফাংশন ছাড়াও, trafficController এবং cgroup eBPF ফিল্টার ফোন সেটিংসের উপর নির্ভর করে নির্দিষ্ট UID থেকে ট্র্যাফিক ব্লক করার জন্যও দায়ী। UID-ভিত্তিক নেটওয়ার্কিং ট্র্যাফিক ব্লকিং বৈশিষ্ট্যটি কার্নেলের ভিতরে থাকা xt_owner মডিউলের প্রতিস্থাপন এবং traffic_powersave_uid_map , traffic_standby_uid_map এবং traffic_dozable_uid_map লিখে বিস্তারিত মোড কনফিগার করা যেতে পারে।

নতুন বাস্তবায়নটি লিগ্যাসি xt_qtaguid মডিউল বাস্তবায়ন অনুসরণ করে, তাই TrafficController এবং NetworkStatsService লিগ্যাসি অথবা নতুন বাস্তবায়নের মাধ্যমে চলবে। যদি অ্যাপটি পাবলিক API ব্যবহার করে, তাহলে ব্যাকগ্রাউন্ডে xt_qtaguid অথবা eBPF টুল ব্যবহার করা হোক না কেন, এতে কোনও পার্থক্য থাকা উচিত নয়।

যদি ডিভাইসের কার্নেলটি অ্যান্ড্রয়েড কমন কার্নেল 4.9 (SHA 39c856663dcc81739e52b02b77d6af259eb838f6 বা তার উপরে) এর উপর ভিত্তি করে তৈরি হয়, তাহলে নতুন eBPF টুলটি বাস্তবায়নের জন্য HAL, ড্রাইভার বা কার্নেল কোডে কোনও পরিবর্তন করার প্রয়োজন নেই।

আবশ্যকতা

  1. কার্নেল কনফিগারেশনে নিম্নলিখিত কনফিগারেশনগুলি চালু থাকতে হবে:

    1. CONFIG_CGROUP_BPF=y
    2. CONFIG_BPF=y
    3. CONFIG_BPF_SYSCALL=y
    4. CONFIG_NETFILTER_XT_MATCH_BPF=y
    5. CONFIG_INET_UDP_DIAG=y

    সঠিক কনফিগারেশন চালু আছে কিনা তা যাচাই করার সময় VTS কার্নেল কনফিগারেশন পরীক্ষা সহায়ক।

লিগ্যাসি xt_qtaguid অবচয় প্রক্রিয়া

নতুন eBPF টুলটি xt_qtaguid মডিউল এবং এটির উপর ভিত্তি করে তৈরি xt_owner মডিউল প্রতিস্থাপন করছে। আমরা অ্যান্ড্রয়েড কার্নেল থেকে xt_qtaguid মডিউলটি অপসারণ এবং এর অপ্রয়োজনীয় কনফিগারেশনগুলি অক্ষম করা শুরু করব।

অ্যান্ড্রয়েড ৯ রিলিজে, xt_qtaguid মডিউলটি সকল ডিভাইসে চালু থাকে, কিন্তু xt_qtaguid মডিউল proc ফাইলটি সরাসরি পড়া সকল পাবলিক API গুলিকে NetworkManagement Service-এ স্থানান্তরিত করা হয়। ডিভাইসের কার্নেল সংস্করণ এবং প্রথম API স্তরের উপর নির্ভর করে, NetworkManagement Service জানে যে eBPF টুলগুলি চালু আছে কিনা এবং প্রতিটি অ্যাপের নেটওয়ার্ক ব্যবহারের পরিসংখ্যানের জন্য সঠিক মডিউলটি বেছে নেয়। SDK লেভেল ২৮ এবং তার বেশি থাকা অ্যাপগুলিকে sepolicy দ্বারা xt_qtaguid proc ফাইল অ্যাক্সেস করা থেকে বিরত রাখা হয়।

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

অ্যান্ড্রয়েড ৯ রিলিজে, শুধুমাত্র অ্যান্ড্রয়েড ৯ রিলিজের সাথে লঞ্চ হওয়া ডিভাইসগুলিতেই নতুন eBPF বৈশিষ্ট্য থাকা প্রয়োজন। যেসব ডিভাইসে eBPF সরঞ্জাম সমর্থন করে এমন কার্নেল রয়েছে, আমরা অ্যান্ড্রয়েড ৯ রিলিজে আপগ্রেড করার সময় এটিকে নতুন eBPF বৈশিষ্ট্যে আপডেট করার পরামর্শ দিচ্ছি। এই আপডেটটি কার্যকর করার জন্য কোনও CTS পরীক্ষা নেই।

বৈধতা

আপনার নিয়মিত অ্যান্ড্রয়েড কমন কার্নেল এবং অ্যান্ড্রয়েড AOSP মেইন থেকে প্যাচ নেওয়া উচিত। নিশ্চিত করুন যে আপনার বাস্তবায়ন প্রযোজ্য VTS এবং CTS পরীক্ষা, netd_unit_test এবং libbpf_test পাস করে।

পরীক্ষামূলক

প্রয়োজনীয় বৈশিষ্ট্যগুলি চালু আছে কিনা এবং প্রয়োজনীয় কার্নেল প্যাচগুলি ব্যাকপোর্ট করা আছে কিনা তা নিশ্চিত করার জন্য কার্নেল net_tests আছে। পরীক্ষাগুলি Android 9 রিলিজ VTS পরীক্ষার অংশ হিসাবে একত্রিত করা হয়েছে। system/netd/ ( netd_unit_test এবং libbpf_test ) এ কিছু ইউনিট পরীক্ষা রয়েছে। নতুন টুলের সামগ্রিক আচরণ যাচাই করার জন্য netd_integration_test এ কিছু পরীক্ষা রয়েছে।

সিটিএস এবং সিটিএস যাচাইকারী

যেহেতু উভয় ট্র্যাফিক মনিটরিং মডিউলই অ্যান্ড্রয়েড ৯ রিলিজে সমর্থিত, তাই সমস্ত ডিভাইসে নতুন মডিউলটি প্রয়োগ করতে বাধ্য করার জন্য কোনও CTS পরীক্ষা নেই। কিন্তু ৪.৯ এর চেয়ে বেশি কার্নেল সংস্করণযুক্ত ডিভাইসগুলির জন্য যারা মূলত অ্যান্ড্রয়েড ৯ রিলিজ (অর্থাৎ প্রথম API স্তর >= ২৮) দিয়ে আসে, নতুন মডিউলটি সঠিকভাবে কনফিগার করা হয়েছে কিনা তা যাচাই করার জন্য GSI তে CTS পরীক্ষা রয়েছে। পুরানো UID মডিউলের সাথে সামঞ্জস্যপূর্ণ আচরণ যাচাই করতে TrafficStatsTest , NetworkUsageStatsTest এবং CtsNativeNetTestCases এর মতো পুরানো CTS পরীক্ষা ব্যবহার করা যেতে পারে।

ম্যানুয়াল পরীক্ষা

system/netd/ ( netd_unit_test , netd_integration_test এবং libbpf_test ) এ কিছু ইউনিট পরীক্ষা আছে। স্ট্যাটাসটি ম্যানুয়ালি চেক করার জন্য dumpsys সাপোর্ট আছে। dumpsys netd কমান্ডটি trafficController মডিউলের মৌলিক অবস্থা এবং eBPF সঠিকভাবে চালু আছে কিনা তা দেখায়। যদি eBPF চালু থাকে, তাহলে dumpsys netd trafficcontroller কমান্ডটি প্রতিটি eBPF মানচিত্রের বিস্তারিত বিষয়বস্তু দেখায়, যার মধ্যে ট্যাগ করা সকেট তথ্য, প্রতি ট্যাগের পরিসংখ্যান, UID এবং iface এবং মালিক UID মিল অন্তর্ভুক্ত থাকে।

পরীক্ষার স্থান

সিটিএস পরীক্ষাগুলি এখানে অবস্থিত:

VTS পরীক্ষাগুলি https://android.googlesource.com/kernel/tests/+/android16-qpr1-release/net/test/bpf_test.py এ অবস্থিত।

ইউনিট পরীক্ষাগুলি এখানে অবস্থিত: