سائٹ سے سائٹ VPN یا دور دراز رسائی: دونوں کیا جوڑتے ہیں
ایک گیٹ ویز کو جوڑتا ہے، دوسرا آلات کو جوڑتا ہے۔ ٹریفک سلیکٹرز کا راستوں سے موازنہ کریں، ایڈریسنگ کی منصوبہ بندی کریں، پھر کسی حقیقی ہوسٹ سے فارورڈنگ اور پالیسی جانچیں۔
دونوں ڈیزائنوں کو VPN کہا جاتا ہے اور وہ مختلف مسائل حل کرتے ہیں۔ سائٹ سے سائٹ ٹنل دو گیٹ ویز کو جوڑتی ہے، اس لیے ان کے پیچھے ہر ہوسٹ بغیر کچھ انسٹال کیے دوسری طرف کے اجازت یافتہ پتوں تک پہنچ سکتا ہے۔ دور دراز رسائی کی ٹنل انفرادی آلات کو ایک نیٹ ورک سے جوڑتی ہے، ایک وقت میں ایک کلائنٹ۔ یہ موازنہ اہم ہے کیونکہ زیادہ تر تعیناتی غلطیاں ایک کو کنفیگر کرکے دوسرے کے رویے کی توقع کرنے سے ہوتی ہیں، اور علامت عام طور پر ایسی سروس میں وقت ختم ہونا ہے جہاں ٹنل واقعی پہنچی تھی۔
دو ڈیزائن، دو سرحدیں
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
کوئی بھی ڈیزائن LAN براڈکاسٹ ڈومین کو نہیں بڑھاتا۔ دور والے جانب کے آلات مقامی دریافت فہرست میں ظاہر نہیں ہوتے، اور ایسی توقع کرنا پہلا مفروضہ ہے جسے چھوڑنا چاہیے۔ آپ جو نجی DNS نام جان بوجھ کر شائع کرتے ہیں وہ کسی بھی دریافت پروٹوکول سے زیادہ قابلِ اندازہ ہیں، اور سپلائر بدلنے پر بھی قائم رہتے ہیں۔
ایک سائٹ پر 10.10.0.0/24 اور دوسری پر 10.20.0.0/24 لیں۔ گیٹ وے A کو ایسا راستہ یا ٹریفک سلیکٹر درکار ہے جو 10.20.0.0/24 سابقہ ٹنل میں بھیجے، اور گیٹ وے B کو اس کا آئینہ دار عکس درکار ہے۔ پھر دونوں طرف کے ہوسٹ عام IP رابطہ استعمال کرتے ہیں اور کبھی نہیں جانتے کہ ٹنل موجود ہے۔ یہی نظر نہ آنا خصوصیت ہے، اور اسی لیے ناکامیاں ٹنل کی غلطیوں کے بجائے عام نیٹ ورک غلطیوں جیسی دکھتی ہیں۔
پالیسی پر مبنی اور راستے پر مبنی ایک ہی ٹنل نہیں ہیں
پالیسی پر مبنی IPsec تعیناتی میں، طے شدہ ٹریفک سلیکٹرز بالکل متعین کرتے ہیں کہ کون سے ماخذ اور منزل کے جوڑے محفوظ ہیں۔ اگر کسی گیٹ وے کے پیچھے نیا ذیلی نیٹ ورک ظاہر ہو اور کوئی سلیکٹر اسے نہ ڈھانپے، تو ٹنل چلتی رہتی ہے اور نیا ذیلی نیٹ ورک محض منتقل نہیں ہوتا۔ راستے پر مبنی ڈیزائن میں انٹرفیس ٹریفک وصول کرتا ہے اور روٹنگ جدول فیصلہ کرتا ہے، جو سابقہ شامل کرنے کو ٹنل کی دوبارہ گفت و شنید کے بجائے راستے کی تبدیلی بنا دیتا ہے۔
StrongSwan دونوں نظریے براہِ راست دکھاتا ہے، اور انہیں اکٹھا پڑھنا ہی یہ جاننے کا طریقہ ہے کہ آپ نے واقعی کون سا ماڈل تعینات کیا۔
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'وہ سلیکٹر فہرست جس میں آپ کا مطلوبہ سابقہ چھوٹ گیا ہو، بغیر کسی پیکٹ کیپچر کے ناکامی کی وضاحت کرتی ہے، اور غلط انٹرفیس کی طرف اشارہ کرنے والا راستہ واپسی کے راستے پر آئینہ دار ناکامی کی وضاحت کرتا ہے۔ کچھ بھی دوبارہ طے کرنے سے پہلے دونوں پڑھیں، کیونکہ کلید کی تجدید وہ سلیکٹر شامل نہیں کرے گی جو آپ نے کبھی کنفیگر نہیں کیا۔
ٹنل سے پہلے ایڈریسنگ کی منصوبہ بندی کریں
اوورلیپنگ رینج وہ ڈیزائن غلطی ہے جو کنفیگریشن سے درست نہیں ہو سکتی۔ اگر دونوں سائٹیں 192.168.1.0/24 استعمال کریں، تو 192.168.1.50 درکار ہوسٹ کے پاس دو امیدوار ہوتے ہیں اور چننے کا کوئی طریقہ نہیں۔ ٹنل تصدیق کرے گی، سیکیورٹی ایسوسی ایشنز قائم ہوں گی، اور روٹنگ کا فیصلہ پھر بھی غلط یا مبہم رہے گا۔
تین ایماندار آپشنز میں سے ایک چنیں: ایک سائٹ کی دوبارہ نمبرنگ کریں، گیٹ وے پر اوورلیپنگ رینج کا ترجمہ کریں تاکہ ہر فریق مختلف سابقہ دیکھے، یا ان ہوسٹس کے لیے براہِ راست روٹنگ چھوڑ دیں اور سروس کو کسی اور طریقے سے شائع کریں۔ ہر ایک کی لاگت ہے، اور دو سال کے افق میں پہلا عام طور پر سب سے سستا ہوتا ہے۔ ٹنل کے وجود سے پہلے فیصلہ کریں، کیونکہ بعد میں یہ تبدیلی پرانے پتے والے ہر آلے کو متاثر کرے گی۔
MTU کا مسئلہ بھی جلدی حل کریں۔ ٹنل مفید پے لوڈ کم کرتی ہے، اور فریگمنٹیشن پر انحصار کرنے والا ڈیزائن گیٹ ویز پر MSS مقرر کرنے والے ڈیزائن سے مختلف برتاؤ کرتا ہے۔
فارورڈنگ اور پالیسی ٹنل سے باہر ہیں
گیٹ وے کو ٹنل انٹرفیس اور LAN انٹرفیس کے درمیان پیکٹ فارورڈ کرنے کے لیے تیار ہونا چاہیے، اور دونوں سمتوں کو ایسی پالیسی درکار ہے جو سروس کی اجازت دے۔ Linux میں یہ دو الگ سیٹنگز ہیں، نیز وہ فائر وال قواعد جو فیصلہ کرتے ہیں کہ فارورڈ شدہ بہاؤ بالکل اجازت یافتہ ہے یا نہیں۔
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTوصول کرنے والا ہوسٹ تیسری پرت شامل کرتا ہے: اس کے اپنے فائر وال کو اب بھی دور دراز ذیلی نیٹ ورک سے کلائنٹ قبول کرنا ہوگا۔ جو فائل سرور صرف اپنا مقامی /24 اجازت دیتا ہے وہ 10.20.0.7 سے فارورڈ شدہ ٹریفک مسترد کرے گا، چاہے ٹنل کتنی ہی صحت مند دکھے، اور اس مسترد ہونے کو روٹنگ کی ناکامی کے طور پر پڑھنا آسان ہے۔
گیٹ وے سے نہیں، ہوسٹ سے جانچیں
خود گیٹ وے کی بھیجی ہوئی ping فارورڈ شدہ صارف ٹریفک سے مختلف ماخذ پتہ اور مختلف پالیسی اختیار کر سکتی ہے۔ اس سے یہ کمزور جانچ بنتی ہے اور کبھی کبھی گمراہ کن بھی: یہ کامیاب ہوتی ہے جبکہ ایپ ناکام ہو، یا ناکام ہوتی ہے جبکہ ایپ کام کر رہی ہو۔
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullحقیقی ہوسٹ، حقیقی ماخذ پتہ اور وہی حقیقی پروٹوکول استعمال کریں جو ایپ استعمال کرتی ہے۔ پھر واپسی کا راستہ الگ سے پڑھیں، کیونکہ واپسی راستے کے بغیر کام کرنے والی آگے کی سمت ایسا وقت ختم ہونا پیدا کرتی ہے جو بلاک شدہ سروس جیسا ہی دکھتا ہے۔
ڈیزائن اس سوال کے مطابق چنیں جس کا آپ جواب دے رہے ہیں: آپ نیٹ ورک جوڑ رہے ہیں یا آلات قبول کر رہے ہیں؟ باقی سب، بشمول یہ کہ کون سا سپلائر کنفیگر کرنا ہے، اسی جواب سے نکلتا ہے۔