App Engine آپ کے VPN ڈیٹا بیس تک پہنچ سکتا ہے: کیا ہم آہنگ ہونا چاہیے

یہ دعویٰ کہ App Engine Standard Cloud VPN کے ذریعے نجی ڈیٹا بیس تک نہیں پہنچ سکتا، پلیٹ فارم کی پچھلی نسل کی باقیات ہے۔ Standard انسٹینسز کو کچھ دوسرے رن ٹائمز کی طرح VPC کا مقامی پتہ نہیں ملتا، لیکن وہ آپ کے نیٹ ورک میں موجود Serverless VPC Access کنیکٹر کے ذریعے egress بھیج سکتے ہیں۔ ایک بار وہ راستہ موجود ہو، Cloud VPN اور دور کا فائر وال کنیکٹر کی ٹریفک کو کسی بھی دوسرے ماخذ کی طرح دیکھتے ہیں۔ ناکام ہونے والی چیز شاذ و نادر ہی خود صلاحیت ہوتی ہے۔ یہ تین ترتیبات میں سے ایک ہے جو کبھی ہم آہنگ نہیں ہوئیں۔

پرانا جواب کہاں سے آیا

کنیکٹرز سے پہلے، عملی جواب واقعی یہ تھا کہ Standard صرف عوامی اینڈ پوائنٹس سے بات کر سکتا ہے، اور ٹیمیں اس سے بچنے کے لیے پراکسی VM یا کسی اور رن ٹائم پر منتقل ہو گئیں۔ پلیٹ فارم بدلا، لوک کہانی نہیں۔ آن لائن بہت سی مشورے اب بھی اس دور کی عکاسی کرتے ہیں جب egress کا کوئی آپشن ہی نہیں تھا۔

اصلاح سننے سے زیادہ تنگ ہے۔ Standard نجی نیٹ ورک تک پہنچ سکتا ہے، لیکن صرف معاون egress انضمام کے ذریعے، اور صرف ان منزلوں تک جو وہ انضمام واقعی پکڑتا ہے۔

پہلے egress راستہ منتخب کریں

سروس سے منسلک کنیکٹر ہی اس کی ٹریفک کو VPC میں داخل کرتا ہے۔ کنیکٹر کی دستاویزات علاقائی پیشگی شرط اور egress ترتیبات کی فہرست دیتی ہیں؛ کنیکٹر سروس کے علاقے میں ہونا چاہیے اور تعینات کرنے والی شناخت کے لیے قابل استعمال ہونا چاہیے۔

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only نجی منزلوں کو VPC میں بھیجتا ہے اور باقی سب کچھ عام انٹرنیٹ راستے پر چھوڑ دیتا ہے، جو عام طور پر ڈیٹا بیس کنکشن کو درکار ہوتا ہے۔ all-traffic بیرونی ٹریفک کو VPC کے ذریعے وسیع پیمانے پر دھکیلتا ہے، اس لیے عام انٹرنیٹ کالز بھی VPC کی NAT اور فائر وال حیثیت وراثت میں پاتی ہیں۔

فائل کو مقامی طور پر ترمیم کرنا تعینات کرنے تک کچھ نہیں بدلتا۔ چلتی ہوئی ورژن وہی ترتیب برقرار رکھتی ہے جس کے ساتھ بنی تھی۔

ماخذ کا پتہ کنیکٹر ہے، آپ کا لیپ ٹاپ نہیں

زیادہ تر ڈیبگنگ وقت یہیں جاتا ہے۔ دور دراز VPN گیٹ وے اور ڈیٹا بیس فائر وال کو VPC کے اندر کنیکٹر کی مختص کردہ حد قبول کرنی ہوتی ہے، نہ آپ کے دفتر کا پتہ اور نہ سروس کا عوامی egress پتہ۔ ایک بھی اصول لکھنے سے پہلے وہ حد کنسول میں تلاش کریں۔

دو اور جگہوں کو متفق ہونا چاہیے۔ VPC روٹ ٹیبل کو دور دراز ڈیٹا بیس نیٹ ورک کی طرف راستہ درکار ہے، اور دور دراز فریق کو کنیکٹر کی حد کے لیے واپسی راستہ درکار ہے۔ اگر ٹنل ٹریفک سلیکٹرز استعمال کرتی ہے تو تصدیق کریں کہ کنیکٹر کی حد طے شدہ دائرے میں ہے۔ صرف دور سے مقامی سمت میں موجود راستہ عام کوتاہی ہے، اور یہ پنگ گزرنے دیتا ہے مگر TCP ہینڈ شیک کبھی مکمل نہیں کرتا۔

صرف VM سب نیٹ قبول کرنے والی ٹنل کنیکٹر کے پیکٹ بغیر کسی مفید غلطی پیغام کے گرا دیتی ہے، اسی لیے ڈیٹا بیس کا ٹائم آؤٹ اسناد کے مسئلے جیسا لگتا ہے۔

DNS الگ راستے سے سفر کرتا ہے

نجی ڈیٹا بیس کا ہوسٹ نام کنیکٹر کی پہنچ والے نیٹ ورک کے اندر حل ہونا چاہیے، Cloud DNS پیئرنگ یا VPC کے قابل استعمال فارورڈنگ زون کے ذریعے۔ آپ کے ورک سٹیشن پر اسے حل کرنا تعینات سروس کے بارے میں کچھ ثابت نہیں کرتا، کیونکہ آپ کا لیپ ٹاپ وہ ریزولور استعمال نہیں کرتا۔

اگر نام VPC کے اندر سے عوامی پتے پر حل ہو تو آپ غلط فائر وال ڈیبگ کرنے والے ہیں۔

URL Fetch کنیکٹر استعمال نہیں کرتا

egress ترتیب رن ٹائم کے عام بیرونی ساکٹ ڈھانپتی ہے، اور پرانی URL Fetch سروس اس راستے کا حصہ نہیں۔ urlfetch کے ذریعے جاری درخواست ترتیب کچھ بھی کہے کنیکٹر کو نظر انداز کرتی ہے۔ جب ناکام کال کسی پرانی لائبریری میں ہو جو اب بھی URL Fetch استعمال کرتی ہے، تو حل یہ ہے کہ اس کال کو معیاری HTTP کلائنٹ پر منتقل کریں۔

ڈیٹا بیس ڈرائیور کے لیے یہ شاذ و نادر ہی مسئلہ ہوتا ہے، لیکن یہ کلاسک وجہ ہے کہ ایک ہی سروس سے ایک اینڈ پوائنٹ کام کرتا ہے اور دوسرا نہیں۔

ایک تنگ کوئری سے تصدیق کریں

تعینات کریں، پھر دور دراز فریق کو دیکھتے ہوئے تعینات ورژن سے ایک مجاز ڈیٹا بیس آپریشن چلائیں۔ ڈیٹا بیس یا VPN گیٹ وے جو ماخذ پتہ لاگ کرے وہ کنیکٹر کا ہونا چاہیے۔ اگر نہیں، تو درخواست کبھی VPC میں داخل نہیں ہوئی اور کوئی ٹنل ترتیب اسے درست نہیں کرے گی۔ کنسول میں آپ کی تلاش کردہ حد سے موازنہ کریں؛ عدم مطابقت عام طور پر یہ معنی رکھتی ہے کہ دوسرا کنیکٹر ورژن کو خدمت دے رہا ہے۔

VPC کے اندر VM سے کامیاب کوئری ثابت کرتی ہے کہ راستہ موجود ہے۔ یہ ثابت نہیں کرتی کہ سروس نے اسے منتخب کیا۔