VPN آن ہونے پر کلاؤڈ فائر وال کون سا پتہ دیکھتا ہے
مکمل ٹنل اس ماخذ پتے کو بدل دیتا ہے جو آپ کا ڈیٹا بیس دیکھتا ہے۔ اجازت فہرست، نجی راستہ یا منقسم ٹنل منتقل کریں، اسناد نہیں۔
وہ ڈیٹا بیس جو VPN جڑنے سے پہلے کام کرے اور بعد میں ناکام ہو جائے، شاذ و نادر ہی اسناد کا مسئلہ ہوتا ہے۔ کلاؤڈ فائر وال ماخذ پتوں کا موازنہ کرتے ہیں، اور مکمل ٹنل ٹھیک وہی پتہ بدل دیتا ہے جس کا وہ موازنہ کر رہے تھے۔ آپ کے لیپ ٹاپ کے بھیجنے اور سرور کے وصول کرنے کے بارے میں آپ کا خیال اور حقیقت کے درمیان فرق ہی پوری خرابی ہے، اور اسے ایک ہی قدم میں ناپا جا سکتا ہے۔
ماخذ پتہ کیا بنتا ہے
مکمل ٹنل میں ہر پیکٹ VPN گیٹ وے سے باہر جاتا ہے، اس لیے سرور آپ کے گھریلو کنکشن کے بجائے گیٹ وے کا اخراجی پتہ دیکھتا ہے۔ اگر راستے میں کوئی فارورڈ پراکسی ہو تو اسی کا پتہ پہنچتا ہے۔ دونوں جائز ماخذ ہیں، اور آپ کے اصل قاعدے میں درج پتہ ان میں سے کوئی نہیں۔
Azure SQL کے سرور سطح اور ڈیٹا بیس سطح کے فائر وال قواعد منطقی سرور تک پہنچنے والے کلائنٹ پتے کا موازنہ کرتے ہیں، جو مکمل ٹنل کے بعد اخراجی پتہ ہوتا ہے۔ ایک ہی پتے کی اجازت دینے والا AWS سیکیورٹی گروپ بھی ایسا ہی برتاؤ کرتا ہے۔ پیکٹ تصدیق سے پہلے ہی خارج کر دیا جاتا ہے، چنانچہ ملنے والی غلطی اجازت کے مسئلے کے بجائے نیٹ ورک کی ناکامی جیسی لگتی ہے۔ لوگ پاس ورڈ دوبارہ مقرر کرنے لگتے ہیں، اس کی وجہ یہی ہے۔
اجازت فہرست کہاں طے ہوتی ہے
وہ قاعدہ پڑھیں جو ناکام ہونے والے راستے سے میل کھاتا ہے، وہ قاعدہ نہیں جو آپ کو یاد ہے کہ آپ نے بنایا تھا۔ اس کا دائرہ، پورٹ، پروٹوکول اور یہ کہ کیا اس کی جانچ کسی شناختی تصدیق سے پہلے ہوتی ہے، نوٹ کریں۔
پھر طے کریں کہ کون سی تہہ اس فیصلے کی جائز مالک ہے۔ پتے کا قاعدہ بتاتا ہے کہ ٹریفک کہاں سے آتا ہے۔ نجی اختتامی نقطہ بتاتا ہے کہ کیا سروس نجی راستے سے قابل رسائی ہے۔ منقسم ٹنل کی استثنا بتاتی ہے کہ کون سے مقامات ٹنل سے گزرتے ہیں۔ یہ بدلے نہیں جا سکتے، اور ٹنل بدلنے پر ہر ایک مختلف طور پر ناکام ہوتا ہے۔
تین مرمت، تین تہیں
نیچے دیا ہر اختیار بہاؤ کو مختلف وجہ سے درست کرتا ہے، اور غلط چننے سے ایسا کنکشن بنتا ہے جو اگلی گیٹ وے تبدیلی تک کام کرتا ہے۔
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
اخراجی پتہ شامل کرنا سب سے چھوٹی تبدیلی اور سب سے نازک ہے، کیونکہ نیا گیٹ وے یا مختلف علاقہ اسے خاموشی سے باطل کر دیتا ہے۔ ٹنل کی تعریف کے ساتھ پتہ درج کریں تاکہ دونوں ساتھ چلیں۔ عارضی وسیع رینج ایک تشخیص ہے، مرمت نہیں؛ اسے یوں ہی رہنے دینا ہی وہ راستہ ہے جس سے اندرونی سروسز کھلی رہ جاتی ہیں۔
منظم پلیٹ فارم ٹنل میں شامل کیوں نہیں ہو سکتا
Heroku، AppHarbor یا CloudBees جیسے اطلاقی پلیٹ فارم آپ کا کوڈ ایسے ماحول میں چلاتے ہیں جہاں tun یا tap ڈیوائس نہیں اور اسے بنانے کا اختیار بھی نہیں۔ ان کا داخلی ماڈل HTTP ہے، کوئی من مانی سننے والا ساکٹ نہیں۔ VPN بائنری لانے والا buildpack بھی انٹرفیس رکھنے کی جگہ نہیں پاتا۔ قابل عمل طریقے یہ ہیں: وہ مستقل اخراجی پتہ جس کی ڈیٹا بیس اجازت دے سکے، پلیٹ فارم کی پیش کردہ نجی کنکشن پروڈکٹ، یا DMZ میں HTTPS کے ذریعے پہنچنے والی پراکسی۔
وہ پراکسی اپنی تصدیق اور لاگنگ والا رسائی راستہ ہے۔ یہ پلیٹ فارم کو آپ کے VPN کا رکن نہیں بناتی، اور اس طرح بیان کرنے سے ایسے قواعد بنتے ہیں جن کا کوئی آڈٹ نہیں کر سکتا۔
ناکام کلائنٹ سے تصدیق کریں
دوبارہ جڑیں اور کلائنٹ کا عین راستہ دہرائیں۔ سروس جو ماخذ پتہ درج کرتی ہے، کلائنٹ جو ڈیٹا بیس کے نام کے لیے روٹ چنتا ہے، اور اصل استفسار کا نتیجہ اسی ترتیب سے جانچیں۔ گیٹ وے سے کیا گیا ٹیسٹ ثابت کرتا ہے کہ گیٹ وے کام کرتا ہے، جو کبھی شک میں نہیں تھا۔ اگر کنکشن اب تصدیق شدہ ہو اور استفسار پھر بھی ناکام ہو، تو باقی مسئلہ ڈیٹا بیس کی اجازت ہے۔
ٹنل بدلنے پر ہر بار ان قواعد کا جائزہ لیں۔ بدلا ہوا گیٹ وے یا نئی اخراجی رینج اطلاقی ترتیب میں کسی بھی تبدیلی کے بغیر راستہ توڑ دیتی ہے۔