Azure میں VPN ڈیواج کے ساتھ VM واپسی کا راستہ کیوں کھو دیتا ہے
Azure VM میں موجود VPN ڈیواج کے لیے ضروری ہے کہ UDR، نیٹ ورک کارڈ کا فارورڈنگ جھنڈا اور مہمان کی پالیسی ہم آہنگ ہوں۔ ایک برانچ درخواست کو تینوں سے گزاریں۔
VPN ڈیواج چلانے والا Azure VM دو خودمختار فیصلہ سازی نظاموں کے اندر رہتا ہے۔ Azure طے کرتا ہے کہ پیکٹ کس سب نیٹ سے باہر نکلتا ہے، روٹ جدولوں اور نیٹ ورک کارڈ کی فارورڈنگ ترتیب کے ذریعے۔ ڈیواج کا اپنا آپریٹنگ سسٹم طے کرتا ہے کہ ڈکرپٹ شدہ پیکٹ آگے بھیجے یا نہیں۔ مکمل طور پر اوپر آ جانے والا سرنگ پھر بھی دوسرے نظام میں ناکام ہو سکتا ہے، اور ایسی بیشتر تعیناتیاں وہیں رک جاتی ہیں۔
ایک راستے کے تین مالکان
ایک برانچ نیٹ ورک لیں 192.168.50.0/24 اور ایک ورک لوڈ سب نیٹ لیں 10.0.10.0/24، ڈیواج اس پتے پر ہے 10.0.0.4 اپنے ہی سب نیٹ میں۔ ایک درخواست تین الگ ترتیبات کو چھوتی ہے۔
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
زیادہ تر تنظیموں میں ہر قطار کی ملکیت مختلف ٹیم کے پاس ہوتی ہے، اسی لیے یہ خرابی عام طور پر ایک کے بجائے تین ٹکٹوں کی شکل میں آتی ہے۔
وہ راستہ جو ڈیواج کی طرف اشارہ کرتا ہے
ورک لوڈ سب نیٹ کے ساتھ روٹ جدول منسلک کریں اور برانچ سابقے کو Virtual appliance قسم کا اگلا ہاپ دیں 10.0.0.4 بطور پتہ۔ ڈیواج کا قابل رسائی نجی پتہ استعمال کریں، کبھی نہیں اس کا عوامی VPN داخلہ نقطہ۔ اگلا ہاپ ایسا پتہ ہونا چاہیے جہاں ورک لوڈ سب نیٹ پہلے ہی پہنچ سکتا ہو۔ ورک لوڈ کی باقی روٹنگ کو ویسے ہی رہنے دیں، الا یہ کہ آپ نے دانستہ طور پر طے شدہ راستہ بدلنے کا فیصلہ کیا ہو۔
ڈیواج کو اس کے اپنے سب نیٹ میں رکھیں اور یقینی بنائیں کہ برانچ ٹریفک کو ڈیواج کی طرف بھیجنے والا راستہ ڈیواج کے اپنے خارجی راستے کو بھی نہ پکڑے۔ ایسا لوپ صفر جوابات والی صحت مند سرنگ جیسا لگتا ہے، اور رات 2 بجے اسے ڈیبگ کرنا نہایت تکلیف دہ ہے۔
وہ نیٹ ورک کارڈ جھنڈا جسے سب بھول جاتے ہیں
Azure میں ہر نیٹ ورک کارڈ کے لیے IP فارورڈنگ ترتیب موجود ہے، اور وہ بطور طے شدہ بند ہے۔ یہ اس لیے ہے کہ فارورڈ کرنے والا کارڈ ایسے پیکٹ وصول کرتا ہے جو کسی اور کو بھیجے گئے ہوں، اور انہیں خاموشی سے گرا دینا باقی سب کے لیے محفوظ طے شدہ عمل ہے۔
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true اسے ایک انٹرفیس کے لیے آن کرتا ہے۔ Microsoft کی نیٹ ورک کارڈ پر فارورڈنگ کی ہدایات ہر منسلک کارڈ پر یہ ترتیب مانگتی ہیں جو ٹریفک فارورڈ کرتا ہے، اس لیے ایک ہی کارڈ والے ڈیواج کو بھی یہ اسی کارڈ پر مقرر کرنا ہوگا۔
جھنڈا کوئی راستہ نہیں اور کوئی فائر وال قاعدہ نہیں۔ اسے آن کرنا صرف اجازت دیتا ہے اور کچھ نہیں۔
مہمان ڈکرپٹ شدہ پیکٹ کے ساتھ کیا کرتا ہے
سرنگ ختم ہونے کے بعد ڈیواج کا اپنا اسٹیک اگلا فیصلہ کرتا ہے۔ Linux مہمان میں IPv4 فارورڈنگ رن ٹائم ترتیب ہے، اور sysctl -w net.ipv4.ip_forward=1 اگلی بوٹ تک رہتی ہے۔ اسے اس کے بجائے ایک فائل میں /etc/sysctl.d/ محفوظ کریں۔ وینڈر ڈیواج کا اپنا متبادل ہوتا ہے، اور وینڈر پلیٹ فارم میں چسپاں کی گئی Linux ہدایات عام طور پر کچھ بھی نہیں کرتیں۔
مہمان کی فائر وال پالیسی پھر الگ ہے، اور ورک لوڈ کا نیٹ ورک سیکیورٹی گروپ بھی۔ VM کے عوامی پتے تک UDP 500 اور 4500 کی اجازت سرنگ کی حفاظت کرتی ہے؛ یہ نہیں بتاتی کہ کوئی ڈکرپٹ شدہ برانچ درخواست ورک لوڈ پورٹ تک پہنچ سکتی ہے یا نہیں۔
ایک درخواست اور اس کا جواب ٹریس کریں
ایک اجازت شدہ بہاؤ چنیں اور اسے شروع سے آخر تک ٹریس کریں۔ برانچ کو راستہ درکار ہے 10.0.10.0/24 سائٹ کنکشن کے ذریعے، ڈیواج کو ورک لوڈ سب نیٹ تک رسائی کا راستہ درکار ہے، اور ورک لوڈ سب نیٹ کو برانچ کی طرف واپسی کا راستہ درکار ہے۔
ڈیزائن برانچ کے ماخذ پتے کو محفوظ رکھتا ہے یا اس کا ترجمہ کرتا ہے، یہ جلدی طے کریں۔ NAT بدل دیتا ہے کہ ورک لوڈ کیا دیکھتا ہے، اس لیے اس کے رسائی قواعد کو وہی ماڈل بیان کرنا چاہیے جو آپ نے واقعی چنا ہے، نہ کہ کوئی اندازہ شدہ گیٹ وے پتہ۔
کامیاب مصافحہ اس زنجیر کی ایک کڑی ثابت کرتا ہے۔ راستہ اس وقت مکمل ہوتا ہے جب جواب اسی ڈیواج کے ذریعے واپس آئے اور ورک لوڈ کی اپنی پالیسی اسے اجازت دے۔