Linux VPN کلائنٹ کو پرانی ڈیوائس کے پروٹوکول سے ہم آہنگ کریں

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

دور کا سرا کیا شائع کرتا ہے اسے ریکارڈ کریں

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

ڈیوائس کا مینوئل اور اس کے اپنے فائر وال قواعد اس کے لاگ ان صفحے پر لکھے پروٹوکول نام سے زیادہ قابل اعتماد ہیں۔ IPsec کی تشہیر کرنے والی ڈیوائس صرف IKEv1 بول سکتی ہے، اور کوئی فرم ویئر ریلیز جسے کسی نے لاگو نہیں کیا وہی ہو سکتی ہے جو آخر میں IKEv2 شامل کرے۔ ڈیٹا راستے اور سیٹ اپ پورٹ دونوں کی تصدیق کریں، کیونکہ یہیں پرانا سامان اور جدید نیٹ ورک فرق پڑتے ہیں۔ اس مرحلے میں غلطی کا مطلب ہے اپنے کلائنٹ کو ایسی خصوصیت کے خلاف ڈیبگ کرنا جو دوسرے سرے کے پاس کبھی نہیں تھی۔

PPTP: pppd میں ترمیم سے پہلے GRE ثابت کریں

Linux پر PPTP کوئی ڈیمون نہیں جسے آپ شروع کرتے ہیں بلکہ pppd کی کال ہے، اور کنکشن کے پیرامیٹر ایک نامزد peer فائل میں رہتے ہیں جسے pppd بلائے جانے پر پڑھتا ہے۔ ڈسٹری بیوشنز اسے اب بھی پیک کرتی ہیں، حالانکہ پروٹوکول کی معلوم کمزوریاں اسے کسی بھی حساس چیز کے لیے نامناسب بناتی ہیں، اس لیے اسے صرف ایسی ڈیوائس کے لیے سختی سے رکھیں جو اور کچھ پیش نہ کرے۔ کلائنٹ کے بات چیت کرتے وقت GRE پر نظر رکھیں، اندازے کی بجائے مختصر کیپچر سے۔ سب سے زیادہ وقت ضائع کرنے والی ناکامی تصدیق نہیں بلکہ گمشدہ ڈیٹا راستہ ہے۔

pppd call branch-office
tcpdump -ni any proto gre -c 5

اگر سیٹ اپ مکمل ہو جائے اور لنک کبھی ٹریفک نہ ڈھوئے تو اسناد کو چھونے سے پہلے GRE راستے پر شک کریں۔ کلاؤڈ سیکیورٹی گروپس کو پروٹوکول 47 کے لیے واضح قاعدہ درکار ہے، اور کچھ نیٹ ورک اسے بغیر کسی نظر آنے والی غلطی کے مکمل بلاک کر دیتے ہیں۔ اسی نیٹ ورک سے جانچیں جو آپ واقعی استعمال کریں گے، کسی ایسی لیب سے نہیں جو سب کچھ اجازت دیتی ہے۔

L2TP/IPsec: ایک موزوں تجویز دس کوششوں کو ہرا دیتی ہے

ڈیسک ٹاپ ڈائیلاگ کی بجائے ڈیمون لاگ پڑھیں، کیونکہ ڈائیلاگ کئی مختلف ناکامیوں کو ایک پیغام میں سمو دیتا ہے۔ NO_PROPOSAL_CHOSEN خرابی پہلے مرحلے کی ہے: کلائنٹ نے ایسی انکرپشن، ہیش یا Diffie-Hellman گروپ پیش کیا جو سرور قبول نہیں کرے گا۔ فہرست بنائیں کہ ڈیوائس کس چیز کی حمایت کرتی ہے اور اس سے موزوں ایک تجویز لکھیں، کیونکہ بے ترتیب امتزاج عموماً وہی خرابی زیادہ آہستہ دیتے ہیں۔ ڈیسک ٹاپ پر عملی کلائنٹ NetworkManager L2TP پلگ ان ہے جس کے نیچے strongSwan یا Libreswan ہو۔

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

XAuth کے ساتھ جارحانہ IKEv1، اور پورٹل کا معاملہ

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

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

strongSwan کے پرانے ریلیز xauth=client استعمال کرتے تھے جہاں ورژن 5 leftauth2=xauth استعمال کرتا ہے، اس لیے نقل شدہ اسنیپٹ صرف نحو کی وجہ سے ناکام ہو سکتا ہے۔ TLS پورٹل کے لیے، AnyConnect پروٹوکول بولنے والا openconnect Cisco اور زیادہ تر نئے نام والی مصنوعات سنبھالتا ہے، اور اسے TUN ڈیوائس اور اسے تشکیل دینے کے اختیارات درکار ہیں۔ پورٹل کا پتہ بالکل ویسے ہی دیں جیسے براؤزر دکھاتا ہے، ڈیوائس کے متوقع کسی بھی راستے سمیت، پھر اس کے پیچھے کچھ جانچنے سے پہلے مختص شدہ پتہ دیکھیں۔ انٹرفیس پہلے سے بنانا سیٹ اپ کے دوران ایک قسم کی حیرت ختم کرتا ہے۔

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

جڑیں، پھر مقررہ ترتیب میں تصدیق کریں

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

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

اگر کوئی مرحلہ ناکام ہو تو اگلا جانچنے کے بجائے وہیں رک جائیں، کیونکہ ٹوٹے راستے کے نیچے DNS کی ناکامی آپ کو کچھ نہیں سکھاتی۔ تجربہ کرنے سے پہلے کام کرنے والے پروفائل کی نقل محفوظ کریں، کیونکہ مٹائی گئی کنکشن فائل کھونا آسان اور دوبارہ بنانا تھکا دینے والا ہے۔ تجویز کی اقدار کو اسی نوٹ میں رکھیں جس میں ڈیوائس کا ماڈل اور فرم ویئر ورژن ہو، کیونکہ بکس بدلنے پر وہی نوٹ منتقلی اور آثار قدیمہ کے منصوبے کے درمیان فرق ہے۔