ARM بلڈ آپ کے Raspberry Pi کے لیے FortiClient سپورٹ نہیں ہے

Raspberry Pi پر VPN کلائنٹ چلانا اور اس پر FortiClient کا سپورٹ یافتہ ہونا ایک جیسی بات نہیں۔ اس گفتگو میں تین دعوے مل جاتے ہیں: وینڈر ایک پلیٹ فارم کو اہل قرار دیتا ہے، کوئی پروسیسر کے لیے بائنری بناتا ہے، اور گیٹ وے اس کلائنٹ کے پروٹوکول اور رجسٹریشن کی اجازت دیتا ہے۔ تین میں سے ایک مل جانے سے باقی دو کے بارے میں کچھ معلوم نہیں ہوتا۔ انہیں اسی ترتیب سے انجام دیں اور جہاں ایک ناکام ہو وہیں رک جائیں، کیونکہ وہی آپ کو حل کرنا ہے۔

پہلا مرحلہ: اپنے عین پیکیج کے لیے ریلیز نوٹ کی قطار پڑھیں

سپورٹ کے بیانات ورژن سے بندھے ہوتے ہیں، اس لیے اس پیکیج کے ریلیز نوٹس سے شروع کریں جسے آپ کی تنظیم منظور کرتی ہے۔ ٹھوس مثال کے طور پر، FortiClient Standalone 7.4.7 کا جدول GNOME کے ساتھ Ubuntu 22.04 اور 24.04، Red Hat 9 اور CentOS Stream 9 کی فہرست دیتا ہے۔ اس کی Linux پروسیسر شرط Intel یا مساوی کے طور پر لکھی گئی ہے۔

Raspberry Pi OS ان فہرست شدہ Linux ماحول میں سے ایک نہیں۔ یہ ہر FortiClient ایڈیشن کے بارے میں فیصلہ یا آئندہ ریلیز کے بارے میں پیش گوئی نہیں؛ یہ اس دستاویز کی اس قطار کے بارے میں بیان ہے۔ جس ورژن کو آپ واقعی تعینات کرنا چاہتے ہیں اس کا میٹرکس پڑھیں۔

Windows یا macOS قطاروں کے پروسیسر نوٹ Linux قطار میں نہ لائیں۔ وینڈر ہر ایڈیشن اور ہر ریلیز کے لیے پلیٹ فارم دستاویز کرتے ہیں، اور ایک قطار پر لاگو نوٹ دوسری کے لیے ثبوت نہیں۔

دوسرا مرحلہ: تصدیق کریں کہ Pi کیا چلا رہا ہے

کسی بھی ڈاؤن لوڈ سے پہلے تین کمانڈز مقامی حقائق طے کرتی ہیں:

uname -m
cat /etc/os-release
dpkg --print-architecture

پہلی کرنل کی ساخت بتاتی ہے، دوسری تقسیم اور ریلیز، اور تیسری وہ صارف جگہ ساخت جس کے لیے پیکیجز بنائے جاتے ہیں۔ 64 بٹ کرنل کے ساتھ 32 بٹ صارف جگہ ممکن ہے، اور یہ بدل دیتا ہے کہ آپ کو کون سا پیکیج چاہیے۔

پھر دیکھیں کہ اس پلیٹ فارم کے لیے واقعی کیا دستیاب ہے۔ Debian trixie کے شائع شدہ پیکیج جدول میں openfortivpn کی arm64 اور armhf بلڈز شامل ہیں۔ یہ اس تقسیم میں ساخت کی دستیابی قائم کرتا ہے۔ یہ قائم نہیں کرتا کہ Fortinet کسی اخذ شدہ تقسیم پر FortiClient کو اہل قرار دیتا ہے، اور نہ یہ کہ آپ کی تنظیم کا گیٹ وے کلائنٹ کو قبول کرتا ہے۔

پرانی ریلیز کے کیش شدہ پیکیج یا فورم تھریڈ کی ناکام بلڈ رپورٹ کے بجائے سپورٹ یافتہ پیکیجز اور موجودہ ریلیز دستاویزات استعمال کریں۔ اگر گرافیکل فرنٹ اینڈ ہو تو اسے الگ اہل قرار دیں: چلتی کمانڈ لائن بلڈ یہ ثابت نہیں کرتی کہ ایڈیٹر، خفیہ ذخیرہ اور ڈیسک ٹاپ ریپر کی نگرانی برقرار ہے۔

تیسرا مرحلہ: کلائنٹ کو قصوروار ٹھہرانے سے پہلے گیٹ وے چیک کریں

Upstream openfortivpn کو PPP اور TLS کلائنٹ کے طور پر بیان کرتا ہے جو pppd شروع کرتا ہے۔ یہ مخصوص عمل درآمد ہے، اور اسے گیٹ وے کی طرف سے موزوں موڈ درکار ہے۔ سرور کا برانڈ نام پروٹوکول معاہدہ نہیں۔

گیٹ وے کی ریلیز اور فعال رسائی طریقہ، منظور شدہ ہوسٹ نام اور اس کا اعتماد مواد، اور سروس کا مطلوبہ شناختی ورک فلو جمع کریں، بشمول کوئی دوسرا عنصر اور ڈیوائس پوسچر جانچ۔ منظم تعیناتی میں ایسے رجسٹریشن مراحل درکار ہو سکتے ہیں جنہیں انجام دینے کا تیسرے فریق کے کلائنٹ کے پاس کوئی طریقہ نہیں۔

کنکشن اس اکاؤنٹ سے آزمائیں جو آپ کو جاری کیا گیا، منتظم کے اکاؤنٹ سے نہیں، کیونکہ رجسٹریشن اور پالیسی عام طور پر صارف سے منسلک ہوتی ہیں:

sudo openfortivpn vpn.example.com:443 -u <username>

صرف ایگزٹ کوڈ نہیں، ناکامی پڑھیں۔ سرٹیفکیٹ خرابی، PPP ٹائم آؤٹ اور پالیسی مسترد ہونا تین مختلف مسائل ہیں، اور ان میں سے صرف ایک ARM کے بارے میں ہے۔

چوتھا مرحلہ: معاہدے کے اندر رہتے ہوئے ڈیوائس پر اسے قبول کریں

حقیقی نجی وسیلہ، سرنگ کے ذریعے DNS حل، اور نیٹ ورک ٹوٹنے کے بعد دوبارہ جڑنے کے ساتھ سیٹ اپ قبول کریں۔ پھر تصدیق کریں کہ جو منزل ناقابل رسائی رہنی چاہیے وہ اب بھی ناکام ہوتی ہے، کیونکہ صرف رسائی پالیسی کے درست ہونے کا ثبوت نہیں۔

چار حقائق ایک ساتھ لکھیں: OS ریلیز، صارف جگہ ساخت، کلائنٹ پیکیج ورژن، اور گیٹ وے موڈ۔ چاروں کے بغیر اگلا شخص نہیں بتا سکتا کہ سیٹ اپ سپورٹ یافتہ ہے یا صرف کام کر رہا ہے۔

اگر آجر ایسا منظم FortiClient ماحول مانگے جو Pi پورا نہ کر سکے، تو منظور شدہ اینڈ پوائنٹ یا منظور شدہ رسائی ہوسٹ طلب کریں۔ ہم مرتبہ کی توثیق بند نہ کریں، پوسچر جانچ کی نقل نہ کریں، اور ایک مشین کے لیے تنظیم کا گیٹ وے نہ بدلیں۔ جو نتیجہ لکھنا ہے وہ یہ ہے کہ کون سا سپورٹ یافتہ امتزاج مجاز ہے، یہ نہیں کہ بند ماخذ سافٹ ویئر کبھی ARM کو نشانہ نہیں بنا سکتا۔