AWS سے Azure سائٹ VPN: پہلے واپسی کا راستہ لکھیں
دو کلاؤڈز کے درمیان جڑی ہوئی سرنگ تب تک کچھ ثابت نہیں کرتی جب تک ہر ورک لوڈ سب نیٹ دور دراز کے سابقے کی طرف روٹ نہ کرے۔ منصوبہ ترتیب سے مکمل کریں، پھر سروس کی جانچ کریں۔
سرنگ اوپر آئے گی۔ عام طور پر ایسا ہی ہوتا ہے، کیونکہ IKE کو صرف مماثل تجاویز اور قابل رسائی ہم منصب پتہ درکار ہوتا ہے۔ اس کے بعد جو ناکام ہوتا ہے وہ واپسی کا راستہ ہے: AWS ورک لوڈ پیکٹ سرنگ میں بھیجتا ہے، لیکن Azure کی طرف کوئی نہیں جانتا کہ 10.10.0.0/16 کا جواب کیسے دیا جائے، یا Azure کا راستہ ایسی جدول میں ہے جو ورک لوڈ سب نیٹ استعمال نہیں کرتا۔ کسی بھی کنسول کو چھونے سے پہلے راستوں کا منصوبہ لکھیں، اور سرنگ کام کا سب سے کم دلچسپ حصہ بن جائے گی۔
مرحلہ 1: پتوں کا منصوبہ منجمد کریں
ٹھوس اقدار کے ساتھ کام کریں۔ AWS ورک لوڈ 10.10.0.0/16 کے اندر 10.10.1.20 پر ہے اور 10.20.0.0/16 کے اندر 10.20.1.30 پر Azure سروس تک TCP 443 چاہتا ہے۔ دونوں حدود ایک دوسرے پر نہیں چڑھنی چاہئیں، اور قبولیت کی جانچ سروس جوڑی ہے، سرنگ نہیں۔
باقی کچھ بھی کرنے سے پہلے وہ چار حقائق لکھیں، کیونکہ ہر اگلا مرحلہ انہی کے خلاف جانچا جاتا ہے۔
مرحلہ 2: ہر سرے کا مالک گیٹ وے نام دیں
AWS Site-to-Site VPN ورچوئل پرائیویٹ گیٹ وے یا ٹرانزٹ گیٹ وے پر ختم ہو سکتا ہے، اور یہ الگ روٹنگ مالکان ہیں۔ Azure اپنا منظم VPN Gateway اور الگ سے گاہکوں کے خود چلائے جانے والے VM پر مبنی آلات فراہم کرتا ہے۔ نوٹ کریں کہ آپ کے پاس کون سی جوڑی ہے، کیونکہ ہر امتزاج میں اگلا ہاپ مختلف ہوتا ہے۔
منظم گیٹ وے کے لیے، ایسا راستہ نقل نہ کریں جو اندازہ لگائے گئے نجی آلے کے پتے کی طرف اشارہ کرے۔ آلے کے لیے، یہ نہ سمجھیں کہ کلاؤڈ میں راستوں کا پھیلاؤ مہمان آپریٹنگ سسٹم کو ترتیب دیتا ہے، کیونکہ ایسا نہیں کرتا۔
یہاں غلطی کرنے سے ایسا منصوبہ بنتا ہے جو مکمل دکھتا ہے اور پیکٹ ایسے پتے پر بھیجتا ہے جو کبھی جواب نہیں دیتا۔
مرحلہ 3: ہر ورک لوڈ کا واقعی استعمال ہونے والا راستہ لکھیں
نیچے کی ہر حد الگ تلاش ہے، اور ان میں سے کسی ایک کا راستہ پیکٹ کے لیے راستہ نہیں ہے۔ سرنگ کے فعال ہونے سے پہلے جدول اپنی اقدار سے بھریں۔
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS میں، ورک لوڈ سب نیٹ کی روٹ جدول BGP یا سرنگ صحت مند ہونے کے بعد بھی آپ ہی کو اپ ڈیٹ کرنی ہے؛ روٹنگ کا جائزہ اسے کنکشن کا حصہ مانتا ہے۔ Azure میں، صارف کی متعین کردہ روٹ جدول ورچوئل نیٹ ورک کے بجائے سب نیٹ سے منسلک ہوتی ہے، اس لیے مؤثر راستہ VNet بلیڈ میں نہیں، ورک لوڈ NIC پر دیکھیں۔
منظم Azure گیٹ وے گیٹ وے پھیلاؤ کے ذریعے دور دراز کا سابقہ سیکھ سکتا ہے، اور UDR اس فیصلے کو کالعدم کر سکتا ہے۔ UDR اس وقت شامل کریں جب وجہ ہو، عادتاً نہیں۔ شامل کریں تو آلے کا پتہ گھڑنے کے بجائے گیٹ وے کے VPN راستے کے لیے شائع کردہ اگلے ہاپ کی طرف رجوع کریں۔ پھر NIC پر مؤثر راستے دوبارہ پڑھیں، کیونکہ فیصلہ واقعی وہیں ہوتا ہے۔
مرحلہ 4: دائرہ کار ملائیں
BGP کے لیے، ہر فریق جو اعلان کرتا ہے اس کا موازنہ دوسرے فریق نے واقعی جو سیکھا اس سے سابقہ بہ سابقہ کریں۔ مستقل روٹنگ کے لیے، ترتیب دی گئی دور دراز حدود کا موازنہ مرحلہ 3 میں لکھے ورک لوڈ راستوں سے کریں۔
خفیہ نگاری پر متفق IKE رشتہ اس بات کا ثبوت نہیں کہ کسی فریق نے 10.10.0.0/16 یا 10.20.0.0/16 سیکھا۔ دو سرنگیں اوپر ہو سکتی ہیں جبکہ ایک فریق آپ کے منصوبہ بند /16 کے بجائے صرف ایک /24 کا اعلان کر رہا ہو۔ سابقہ روٹنگ جدول میں دیکھیں، سرنگ کی حالت میں نہیں۔ عدم مطابقت بعد میں ایک چلتی سب نیٹ اور ایک کبھی جواب نہ دینے والی سب نیٹ کی صورت میں ظاہر ہوتی ہے۔
مرحلہ 5: سروس کی جانچ اصل ماخذ سے کریں
AWS سیکیورٹی گروپس اور نیٹ ورک ACL، Azure NSG، اور راستے میں کسی بھی آلے کے فلٹر میں مطلوبہ بہاؤ کی اجازت دیں۔ پھر 10.10.1.20 سے منظور شدہ سروس پتے اور پورٹ پر ایک کنکشن کھولیں اور تصدیق کریں کہ جواب اسی ماخذ پر واپس آتا ہے۔
کلاؤڈ سیکیورٹی گروپس اور NSG دونوں stateful ہیں، اس لیے مسترد شدہ واپسی پیکٹ روٹنگ کی علامت ہے، الٹی سمت میں لکھنا بھولا ہوا قاعدہ نہیں۔
کسی بھی گیٹ وے سے ping کچھ طے نہیں کرتا۔ گیٹ وے پتے پر ICMP کنٹرول پلین کے راستے کی مشق کراتا ہے، ورک لوڈ کو درکار فارورڈ شدہ TCP سروس کی نہیں۔
رول بیک اور ریکارڈ
سرنگ کے شناختی نشانوں کے ساتھ راستوں کے مالکان درج کریں اور تبدیلی سے پہلے کی روٹ جدولیں محفوظ رکھیں۔ اگر تبدیلی ہٹانی ہو، تو سرنگ توڑنے سے پہلے ورک لوڈ راستے ہٹا دیں، تاکہ کوئی سب نیٹ ایسے اگلے ہاپ کی طرف نہ دیکھتا رہے جو اب موجود نہیں۔
پھر بعد میں سب نیٹ کی منتقلی یا spoke کے جوڑنے کے لیے اپ ڈیٹ کرنے کی ایک متعین جگہ ہوتی ہے، بجائے اس چلتی سرنگ کے جو ایسے راستے کا الزام اٹھاتی ہے جو کبھی اس کا نہیں تھا۔