د GCP مجازی ماشین چې څو NIC لري: ولې ځوابونه له غلط انٹرفیس څخه وځي

د Compute Engine VM سره دویم انټرفیس نښلول هغه ته بله شبکه ییزه اړیکه ورکوي، نه سمیټریک بیرته راتګ لار۔ مېلمه لا هم خپل انټرفیس او سرچینه آدرس له خپلو لارو او قواعدو څخه غوره کوي۔ بیا Google Cloud د VPC روټینګ او فایر وال پالیسي د هغه انټرفیس شاوخوا پلي کوي چې پیکټ له هغه وتلی وي۔ کله چې دا دوه پرېکړې سره سمون نه خوري، غوښتنې په یو NIC راځي او ځوابونه له بل څخه وځي، او څانګه نیم خلاص خبرې اترې ویني۔

لاره په پنځو ګامونو ووهئ او ناسمونکی به د پالیسۍ قاعده لیکلو مخکې ښکاره شي۔

ګام 1: د کلاوډ NICونه د مېلمه وسیلو سره وتړئ

کلاوډ انټرفیسونه nic0، nic1 او نور نوموي، او مېلمه د وسیلو هغه نومونه ویني چې اړتیا نه لري سره سمون وخوري۔ له هر څه مخکې د انسټانس میټاډاټا یا د انټرفیس خپل آدرس څخه نقشه حل کړئ۔ د DHCP عادي ډیفالټ لار له nic0 سره تړلې ده، نو ځکه انټرنیټ ته لاره ډېری وخت په ناڅاپي ډول ګټي۔ د اټکل شوي وسیلې نوم په اساس پالیسي لیکل هغه لار ده چې سمه قاعده په غلط انټرفیس لګېږي۔

آدرسونه، د وسیلو نومونه او هغه VPC چې هر یو پکې دی ولیکئ۔ هغه درې ستونی نقشه د هر راتلونکي ګام انپټ دی۔

ګام 2: دوه روټینګ پرېکړې ونوموئ

لومړۍ پرېکړه د مېلمه ده: د دې پیکټ لپاره کوم انټرفیس او کوم سرچینه آدرس۔ دویمه د کلاوډ ده: د VPC لارې او فایر وال پالیسي د هغه انټرفیس شاوخوا څه اجازه ورکوي۔

هغه لار چې د VPN مخامخ VPC کې ښکاري د هغه NIC غوره کوونکې مېلمه لار نه شي۔ د کلاوډ لار بیانوي چې شبکه څه رسولای شي، په داسې حال کې چې د مېلمه لار پرېکړه کوي چې پیکټ څه کوي۔

ګام 3: د بیرته راتګ لارې پالیسي غوره کړئ

د څانګې د پریفکسونو د یوې کوچنۍ، ثابتې ټولګې لپاره په مېلمه کې روښانه منزل لارې ساده ترین بیان دی: هغو پریفکسونو ته ځوابونه د VPN مخامخ انټرفیس څخه وځي۔ کله چې څو خدمتونه په قصد سره جلا سیمه ییز سرچینه آدرسونه کاروي، د سرچینې پر بنسټ قواعد چې د هر انټرفیس لپاره جدول غوره کوي هر ځواب په سم زمینه کې ساتي۔ د څو انټرفیسونو مستندات د NIC نومول او د ډیفالټ لار چلند بیانوي چې دا ډیزاینونه پرې تکیه کوي۔

هر جدول ته سمې نښلول شوې لارې او راتلونکي ټوپونه، او همدارنګه هغه منزلونه چې ترې پوښتل کېږي اړین دي۔ هغه قاعده چې نیمګړي جدول ته اشاره کوي د بیرته راتګ لارې ډیزاین نه دی۔ د هغه NIC لپاره مستند شوې دروازه وکاروئ، د سبنيټ بڼې څخه د Ethernet دروازه جوړولو پر ځای۔

ګام 4: د مېلمه خپل فلټرونه وګورئ

وګورئ چې سرور چېرته اورېدل کوي او ځواب کومه سیمه ییزه سرچینه لېږدوي۔ په ټولو آدرسونو اورېدونکی د روټینګ پالیسي نه باطلوي، نو ټولو آدرسونو ته نښلول د هغه انټرفیس په اړه چې ځواب ترې وځي هېڅ نه بدلوي۔

په Linux کې، د موخې ډیزاین پر وړاندې د معکوسې لارې تصدیق بیاکتنه کړئ۔ هغه په نړیواله توګه د لومړي ګام په توګه بندول د روټینګ باګ د جعل خطر سره بدلوي، او هغه نامساوي پټوي چې تاسو یې لټول۔

ګام 5: د هرې لارې لپاره یوه بهیر وازموئ

اجازه ورکړل شوې څانګې غوښتنه او نااړونده انټرنیټ غوښتنه جلا جلا تصدیق کړئ، هر یوه د خپل ریښتیني سرچینې او منزل سره۔ کله چې شئ دواړو انټرفیسونو کې ثبت کړئ، ځکه ګټوره شاهد هغه ده چې کوم انټرفیس ځواب وړی۔ بیا تایید کړئ چې د کلاوډ خوا پالیسي هغه لاره درناوی کړې چې تاسو ډیزاین کړې۔ یوه بریالۍ غوښتنه یو بهیر ثابتوي، نه سمیټریک ډیزاین۔

دوه ازموینې په خپلو یادښتونو کې جلا وساتئ، ځکه دوی جلا لارې او جلا فایر وال قواعد کاروي۔

دویم NIC تاسو ته څه نه درکوي

دویم انټرفیس شبکه ییزه اړیکه او بله آدرس زیاتوي۔ هغه اتوماتیک سمیټریک روټینګ نه زیاتوي او د فایر وال پالیسي نه تیریږي۔ هغه ته د روټینګ سمون په سترګه کتل هغه دلیل دی چې ولې څو NIC لرونکي ډیزاینونه هغه قواعد جمع کوي چې وروسته هیڅوک یې تشریح نه شي کولای۔

که VM باید د نورو ماشینونو ټرافیک وړاندې ولېږي، هغه روټر رول په روښانه ډول پلان کړئ، په شمول د هغه کلاوډ ترتیباتو چې لېږد ته اجازه ورکوي او د مېلمه فلټرونه چې ورسره ځي۔