Azure پوائنٹ ٹو سائٹ جڑتا ہے مگر کوئی نجی وسیلہ جواب نہیں دیتا
جڑنا صرف یہ بتاتا ہے کہ ٹنل اوپر آ گئی۔ دیکھیں گیٹ وے کیا لے جا سکتا ہے، پتہ جگہوں کا موازنہ کریں، پھر نام حل کریں اور خدمت خود آزمائیں۔
جڑا ہوا ہونا ٹنل کی حالت ہے، رسائی کے بارے میں بیان نہیں۔ پوائنٹ ٹو سائٹ کلائنٹ IKE مکمل کر سکتا ہے، پتہ لے سکتا ہے اور پھر بھی کہیں نہیں پہنچ سکتا، کیونکہ گیٹ وے صرف ان نیٹ ورکس کے لیے ٹریفک آگے بھیجتا ہے جنہیں VNet پہلے سے جانتا ہے۔ یہ پانچ جانچیں ترتیب سے کریں اور پہلی ناکامی پر رکیں۔ آگے چھلانگ لگانا وہ طریقہ ہے جس سے DNS مسئلہ ایک گھنٹے تک فائروال مسئلہ سمجھا جاتا ہے۔
ترتیب فہرست سے زیادہ اہم ہے۔
جانچ 1: طے کریں کہ ٹنل کو کیا لے جانا ہے
Azure VPN Gateway ٹنل ختم کرتا ہے اور VNet سے تعلق رکھنے والا ٹریفک آگے بھیجتا ہے؛ یہعام انٹرنیٹ اخراج نہیں ہے۔ اگر صارفین توقع رکھتے ہیں کہ ان کی براؤزنگ Azure سے باہر جائے گی، تو کسی بھی کلائنٹ سیٹنگ سے پہلے ہی ڈیزائن غلط ہے۔ split tunneling فعال کریں تاکہ مقامی انٹرنیٹ مقامی راستے پر رہے، اور جب واقعی مقررہ اخراجی پتہ درکار ہو تو NAT انسٹانس یا سائٹ ٹو سائٹ ٹنل استعمال کریں۔
کچھ بھی جانچنے سے پہلے لکھیں کہ کلائنٹ کو کہاں پہنچنا چاہیے۔ اس فہرست کے بغیر ہر جزوی نتیجہ پیش رفت جیسا لگتا ہے۔
جانچ 2: سرٹیفکیٹ سے پہلے پتہ جگہوں کا موازنہ کریں
اوورلیپ کا فیصلہ وسیع رینجوں پر ہوتا ہے، اس لیے سب نیٹ سطح پر مختلف دکھنے والے دو نیٹ ورک بھی ٹکرائیں گے اگر ان کے بنیادی بلاک اوورلیپ ہوں۔ گیٹ وے سب نیٹ مخصوص اور SKU کے لیے کافی بڑا ہونا چاہیے، اور کلائنٹ پتہ پول VNet یا peering کے ذریعے پہنچنے والی کسی چیز سے نہیں ٹکرانا چاہیے۔ منصوبہ بدلیں اور دوبارہ تعینات کریں، کیونکہ تلافی کے لیے راستے شامل کرنا ایسی ٹنل بناتا ہے جو کچھ منزلوں کے لیے کام کرتی ہے اور دیگر کے لیے ناقابلِ وضاحت طور پر نہیں۔ یہاں پروویژننگ بلند آواز میں ناکام ہوتی ہے، اور یہی اچھی صورت ہے۔
توثیق اگلا دروازہ ہے۔ سرٹیفکیٹ، RADIUS اور Entra ID پروفائل آپس میں بدلے نہیں جا سکتے، اور ہر ایک کے لیے کلائنٹ پیکج مختلف ہے۔
جانچ 3: اندر سے نجی نام حل کریں
کلائنٹ اپنا حل کنندہ رکھتا ہے جب تک ڈاؤن لوڈ شدہ پروفائل VNet کے DNS سرور نہ رکھتا ہو، اور یہ فہرست ڈاؤن لوڈ کے وقت ہی شامل کر دی جاتی ہے۔ VNet کے اندر ایک forwarder شامل کریں، اسے VNet کا DNS سرور مقرر کریں، پھر کلائنٹ پیکج دوبارہ ڈاؤن لوڈ کر کے درآمد کریں۔ پرانا پیکج دوبارہ استعمال کرنا صرف پرانی حل کنندہ فہرست جانچتا ہے۔
پہلے پتہ جانچیں، کیونکہ یہ ایک ہی قدم میں روٹنگ کو نام دینے سے الگ کرتا ہے: Test-NetConnection 10.20.1.4 -Port 3389۔
اگر پتہ جواب دے اور نام نہ دے، تو حل کنندہ سے براہِ راست پوچھیں Resolve-DnsName files.corp.example -Server 10.20.0.4۔ اگر دونوں ناکام ہوں تو خرابی DNS میں نہیں ہے اور آپ کو DNS ترتیبات میں ترمیم بند کر دینی چاہیے۔ 168.63.129.16 پر Azure پلیٹ فارم DNS صرف VNet کے اندر سے جواب دیتا ہے، اس لیے باہر کا کلائنٹ اس پتے کو حل کنندہ کے طور پر استعمال نہیں کر سکتا۔
جانچ 4: ٹنل کے پیچھے کی خدمت آزمائیں
صحت مند ٹنل اور بند پورٹ کلائنٹ کی طرف سے یکساں دکھتے ہیں۔ مہمان فائروال دیکھیں، پھر سب نیٹ یا NIC پر نیٹ ورک سیکیورٹی گروپ، پھر یہ کہ خدمت نجی پتے پر سن رہی ہے یا صرف loopback پر۔ انٹرنیٹ کی طرف قاعدہ کھولنے کے بجائے کلائنٹ پول کو بطور ماخذ اجازت دیں، اور یاد رکھیں کہ Azure Files کے لیے SMB کو نجی endpoint کا راستہ ٹنل سے گزارنا ضروری ہے۔ جب کوئی وسیلہ IP سے جواب دے مگر نام سے نہ دے، تو گیٹ وے چھونے کے بجائے جانچ 3 پر واپس جائیں۔
کام کے دوران ایک جدول تہوں کو الگ رکھتا ہے:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
جانچ 5: بڑھانے سے پہلے پروفائل درج کریں
ٹکٹ میں گیٹ وے کی قسم، ٹنل کی قسم، توثیق کا طریقہ اور کلائنٹ کا آپریٹنگ سسٹم لکھیں۔ سرٹیفکیٹ والا IKEv2 پروفائل اور RADIUS پروفائل مختلف وجوہات سے ناکام ہوتے ہیں، اور دوسری ٹنل قسم کے لیے بنایا گیا کلائنٹ صرف اس وقت جڑتا ہے جب گیٹ وے ہم آہنگ پروٹوکول پیش کرے۔
چھوٹی ٹیم کے لیے پائیدار ڈیزائن ایک VNet، ایک DNS forwarder اور دستاویزی split-tunnel کلائنٹ ہے۔ اگر ضرورت مقررہ عوامی اخراج ہے تو اپنے زیرِ کنٹرول فائروال پر سائٹ ٹو سائٹ ٹنل ختم کریں اور انٹرنیٹ ٹریفک وہاں روٹ کریں، بجائے اس کے کہ پوائنٹ ٹو سائٹ گیٹ وے سے وہ کام مانگیں جس کے لیے وہ کبھی بنایا ہی نہیں گیا۔