Android VPN روٹنگ: main جدول سے پہلے پالیسی قواعد
Android کسی بھی منزل کی تلاش سے پہلے uid اور نشان کے قواعد سے روٹنگ جدول چنتا ہے، اس لیے main میں شامل راستہ کبھی جانچا ہی نہ جائے۔
Android پر main جدول میں شامل کردہ راستہ ہر فہرست میں درست دکھتا ہے اور پھر بھی ٹریفک نہیں اٹھاتا۔ وجہ یہ ہے کہ main جدول کئی اختیارات میں سے ایک ہے، اور سب سے پہلے اسی سے نہیں پوچھا جاتا۔ Android کی نیٹ ورکنگ سروس ایسے پالیسی قواعد بناتی ہے جو روٹنگ جدول کو ان معلومات سے چنتے ہیں جو منزل کے پتے میں نہیں ہوتیں — ایپ کا uid، پیکٹ پر لگا نشان، وہ انٹرفیس جس سے یہ آیا — اور منزل کی تلاش اس کے بعد، اسی جدول کے اندر ہوتی ہے جو ان قواعد نے چنا۔
مقررہ ترتیب میں تین فیصلے
باہر جانے والا پیکٹ تین الگ فیصلے کرتا ہے۔ پہلا، ایک پالیسی قاعدہ طے کرتا ہے کہ کون سا روٹنگ جدول لاگو ہوتا ہے۔ دوسرا، اس جدول کے اندر کا راستہ اگلی چھلانگ اور خارجی انٹرفیس طے کرتا ہے۔ تیسرا، netfilter ہک طے کرتے ہیں کہ پیکٹ بچے گا، بدلے گا یا ری ڈائریکٹ ہوگا۔
ترتیب اہم ہے کیونکہ ہر مرحلہ صرف اپنے ہی سوال کا جواب دے سکتا ہے۔ پیکٹ قبول کرنے والا فائر وال قاعدہ جدول نہیں چنتا، اور جس جدول کو کوئی قاعدہ نہیں چنتا اس میں شامل راستہ غیر موثر رہتا ہے۔ Android VPN کے بارے میں زیادہ تر الجھن تین میں سے ایک درست کرنے اور کوئی تبدیلی نہ دیکھنے سے آتی ہے، کیونکہ خرابی کسی دوسرے میں تھی۔
| Stage | Selector | What it cannot decide |
|---|---|---|
| Policy rule | uid range, mark, incoming interface | Which route exists inside the table |
| Route lookup | Destination prefix, longest match | Whether the packet is allowed out |
| Netfilter hook | Chain position, match conditions | Which table was selected |
نشانات ایک پیک شدہ فیلڈ ہیں، آپ کا اپنا لیبل نہیں
Android کئی حقائق کو ایک ہی نشان کی قدر میں پیک کرتا ہے: کون سا نیٹ ورک چنا گیا، کیا کسی ایپ نے واضح طور پر نیٹ ورک چنا، کیا ساکٹ VPN سے محفوظ ہے، اور اجازتوں سے متعلق بٹس۔ AOSP کا fwmark ہیڈر موجودہ درخت کے لیے وہ ترتیب بیان کرتا ہے، اور ترتیب پلیٹ فارم کی اندرونی بات ہے جو ریلیز کے درمیان بدلتی ہے۔
اسی لیے Android پر iptables -j MARK --set-mark کے ساتھ پوری نشان کی قدر لکھنا خطرناک ہے۔ یہ ٹیگ نہیں جوڑتا؛ یہ وہ نیٹ ورک انتخاب بدل دیتا ہے جو سسٹم پہلے ہی کر چکا ہے۔ پھر پیکٹ دوسرے قواعد سے میل کھاتا ہے، جو اس پر منحصر ہے کہ کون سے بٹس دوبارہ لکھے گئے، یہ دکھ سکتا ہے کہ VPN کام کرنے لگا، یا کسی غیر متعلق ایپ کا کنکشن چلا گیا۔
اگر نشانات کو چھونا ہی پڑے، تو پہلے موجودہ قدر پڑھیں اور ماسک استعمال کریں تاکہ صرف وہی بٹس بدلیں جو آپ سمجھتے ہیں:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11کنکشن کا نشان پیکٹ کے نشان سے الگ شے ہے، اور ان میں سے کوئی راستہ نہیں۔ جوابی پیکٹوں پر نشان بحال کرنا باہر جاتے وقت جدول چننے سے الگ مرحلہ ہے، اسی لیے یک طرفہ اصلاحات ایسے کنکشن بناتی ہیں جو کھلتے ہیں اور پھر اٹک جاتے ہیں۔
قواعد اور جدولوں کا مالک کون ہے
Android کی نیٹ ورک سروس، netd، قواعد اور ہر نیٹ ورک کے جدول بناتی ہے۔ AOSP RouteController وہ جگہ ہے جہاں VPN، فزیکل نیٹ ورک اور uid حدود کے لیے یہ قواعد جوڑے جاتے ہیں، اور اس کا زندگی کا دورانیہ کنفگ فائل کے بجائے نیٹ ورک واقعات سے بندھا ہے۔
اس کے دو نتائج ہیں۔ پہلا، ایک ڈیوائس پر ملنے والی ترجیحات اور جدول نمبرز بلڈ کی اندرونی تفصیلات ہیں، انٹرفیس نہیں: کسی دوسرے Android ورژن پر یکساں دکھنے والے نمبر کچھ اور مطلب رکھ سکتے ہیں۔ دوسرا، نیٹ ورک بدلنے پر حالت دوبارہ بنتی ہے، اس لیے آج root شیل سے شامل کردہ قاعدہ اگلی Wi-Fi تبدیلی کے بعد غائب ہو سکتا ہے۔
اس غیبت کو اکثر یوں رپورٹ کیا جاتا ہے کہ سسٹم راستے کو نظر انداز کر رہا ہے۔ درحقیقت ہوا یہ کہ جدول چننے والا قاعدہ اب موجود نہیں، اور جدول کے اندر کا راستہ اب پیکٹ کی نظر میں ناقابل رسائی ہے۔ جب دوبارہ جڑنے کے بعد کام کرتی کنفیگریشن کام کرنا چھوڑ دے، تو راستوں کی فہرست نہیں، قواعد کی فہرست دیکھیں۔
ہک کی ترتیب کے سوالوں کا کوئی عالمگیر جواب نہیں
iptables VPN روٹنگ سے پہلے چلتا ہے یا نہیں، یہ سوال پیکٹ کا راستہ بتائے بغیر جواب نہیں پا سکتا۔ مقامی طور پر بنایا گیا پیکٹ output ہک سے گزرتا ہے، جہاں نشان کی تبدیلی دوبارہ روٹنگ کی جانچ کو متحرک کرتی ہے — یہ دوسری تلاش ہے، پہلی کی بعد کی ترمیم نہیں۔ tether سے جڑے کلائنٹ سے آنے والا پیکٹ prerouting راستے سے گزرتا ہے اور اس کے بجائے آگے بھیجا جاتا ہے، اور اسے دیکھنے والی زنجیریں دوسری ہیں۔
چنانچہ ایک ہی قاعدہ کسی ایپ کی ٹریفک کے لیے موثر اور tether ٹریفک کے لیے پوشیدہ ہو سکتا ہے، اور صفر پر رکنے والا کاؤنٹر بتاتا ہے کہ پیکٹ نے کون سا راستہ لیا، یہ نہیں کہ قاعدہ غلط ہے۔ کسی بھی میچ کی شرط بدلنے سے پہلے کاؤنٹرز سے راستہ طے کریں۔
یہ وہ مرحلہ بھی ہے جہاں پالیسی روٹنگ کی غلطی دیکھنا مشکل ہو جاتا ہے۔ ایسے جدول کی طرف روٹنگ جو موجود ہے مگر منزل نہیں رکھتا، نیٹ ورک ناقابل رسائی پیدا کرتا ہے جو فائر وال ڈراپ جیسا لگتا ہے، جبکہ فائر وال ڈراپ ایسا ٹائم آؤٹ پیدا کرتا ہے جو روٹنگ بلیک ہول جیسا لگتا ہے۔
نظام کے اندر تشخیص کریں، یا اسے چھوڑ دیں
مجاز جائزے کے لیے کچھ بھی چھونے سے پہلے چار حقائق طے کریں: ایپ کا uid اور پروفائل، وہ نیٹ ورک جو Android نے اس کے لیے چنا، کیا VPN اس ایپ کو شامل کرتا ہے، اور کیا مسئلہ دونوں ایڈریس خاندانوں میں ہے۔ فی ایپ اخراج بغیر کسی روٹنگ خرابی کے VPN کام نہیں کر رہا کی بہت سی رپورٹوں کی وضاحت کرتا ہے۔
پھر وہ قواعد، ماسک اور جدول پڑھیں جو واقعی نافذ ہیں، اور نیٹ ورک کی تبدیلی کو مشاہدے کی کھڑکی میں رکھیں۔ اگر دوبارہ جڑنے کے دوران رویہ بدلے، تو آپ زیر انتظام زندگی کے دورانیے کو دیکھ رہے ہیں، گمشدہ راستے کو نہیں۔
عام ضروریات کے لیے معاون کنٹرول استعمال کریں: فی ایپ شمولیت اور اخراج VPN ایپلیکیشن میں، اور مخصوص راستہ چاہنے والی ہر چیز کے لیے پلیٹ فارم کا اپنا نیٹ ورک انتخاب۔ اگر کوئی مراعات یافتہ انضمام واقعی روٹنگ مشینری کے ساتھ تعاون کرے، تو اسی درست Android ورژن کے نفاذ کو ہدف بنائیں جس کی آپ معاونت کرتے ہیں اور اس کے زندگی کے دورانیے کو اس جزو کے ذریعے برقرار رکھیں جو اس کا مالک ہے۔ پلیٹ فارم زنجیروں کو فلش کرنا یا زیادہ ترجیحی قاعدہ داخل کرنا تشخیص کو دوسرا نیٹ ورک منیجر بنا دیتا ہے، اور فون اسی کے مطابق برتاؤ کرے گا۔