د یو کلاوډ خدمت لپاره اصلي TLS، SSH لیږد یا VPN

پوښتنه په ندرت سره دا ده چې آیا د دوو کلاوډ ماشینونو ترمنځ څه شی باید کوډ شي؛ پوښتنه دا ده چې تاسو کوم انټرفیس کوډ کوئ او څوک د چا هویت ګوري۔ زه دا خبرې له خدمت څخه پیلوم نه د شبکې له ډیاګرام څخه، ځکه خدمت مخکې له مخکې پوهیږي چې څه ته اړتیا لري۔ درې پولې ډېری قضیې پوښي: د اپلیکیشن خپل TLS، د SSH له لارې لیږدول شوی یو TCP پورټ، او یوه رغړه شوې پوښ چې هر ګډونوال ته یو پته ورکوي۔ دوی د ځواک له مخې نه، بلکې د دې له مخې درجه بندي کیږي چې د ستونزې څومره برخه پوښي۔

له خدمت سره پیل وکړئ، نه له شبکې سره

له پروسې بهر لاړ شئ۔ کوم پروتوکول خبرې کوي، کلاینټ کوم نوم تاییدوي، او څوک اصلاً اجازه لري چې اړیکه پرانیزي؟ دا درې ځوابونه انتخابونه له هرې پرتله کولو جدول څخه ګړندي لرې کوي، او د خدمت خپله ترتیب معمولاً په څو دقیقو کې ورته ځواب وایي۔

یو کوچنی داخلي API واخلئ چې مخکې له مخکې په 8443 پورټ کې HTTPS وړاندې کوي، د api.internal.example لپاره د سند سره۔ په هوسټ کې ss -ltnp ښیي چې له کوم شي سره تړل شوی، او openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example ښیي چې سند د هغه نوم لپاره معتبر دی چې کلاینټ به یې واقعاً کاروي۔ که دواړه روغ وي، خدمت کولی شي خپل جریان وساتي او یوازې رسیدل پاتې کیږي۔ دا د شبکې جوړولو څخه ډېره کوچنۍ ستونزه ده۔

ګام 1: آیا خدمت ځان ساتي؟

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

کوډ کول او رسیدل جلا کنټرولونه پاتې کیږي، او د دوی یوځای کول هغه ځای دی چې دا انتخاب غلط کیږي۔ په نامحدود عامه اوریدونکي کې TLS خدمت لا هم د هرچا له خوا د اړیکې هڅې مني، نو اوریدونکی او د شبکې قواعد باید د دې حقیقت څخه خپلواکه وي چې بار ساتل شوی۔ بیا انحصارونه وګورئ، ځکه چې د TLS پرمخ API د کشف پای ټکي، د ادمین پورټ یا څنګ کې د لوی لیږد کانال په اړه هیڅ نه وایي۔ هر یو یې خپل ځواب ته اړتیا لري، او یو ناساته ورور د ټولې پولې افسانې کولو لپاره کافي دی۔

ګام 2: آیا یو TCP پورټ ټوله اړتیا ده؟

کله چې اړتیا واقعاً یو TCP پورټ وي، لیږد ترټولو کوچنی کار کوونکی شی دی۔ د SSH محلي لیږد هغه پورټ د مخکې موجود تصدیق شوي اړیکې له لارې وړي۔

بڼه ssh -N -L 8443:127.0.0.1:8443 [email protected] ده، او مهم تفصیل هدف پته ده: 127.0.0.1 په لرې اړخ کې حل کیږي، نو خدمت ته اړیکه ستاسو له لیپ ټاپ څخه نه، بلکې له بستیون څخه پرانیستل کیږي۔ محلي اوریدونکی په تنګ ډول د -L 127.0.0.1:8443:... په توګه وتړئ ترڅو په ناڅاپي ډول خدمت خپل محلي شبکه کې خپور نه کړئ۔ د سرور په اړخ کې، د کلاینټ د ښه چلند باور کولو پرځای محدود کړئ چې حساب څه لیږدولی شي۔ PermitOpen، AllowTcpForwarding local او GatewayPorts no اصلي هغه درې تنظیمات دي چې یو عمومي ریلې په ځانګړي کانال بدلوي۔

تړون په دواړو لورو کې تنګ دی۔ SSH خپل کانال ساتي، او له بستیون څخه بل اپلیکیشن ته بل ټوپ خپله ساتنه غواړي۔ هغه خدمت چې یوازې د بستیون په loopback اوریدل کوي، د بلې شبکې له لارې رسیدونکي خدمت څخه بشپړ توپیر لري، او لیږد دا نه بدلوي۔ د تونل د هغوی بدیل ګڼلو پرځای د اپلیکیشن تصدیق او TLS ګوتې وساتئ۔

دا د یو مالک سره د یوې اړیکې لپاره ښه کار کوي۔ په لویه کچه دا یو سیستم کیږي: محلي پورټ ټکرونه، څارنه، د کیلي ګردش او دا پوښتنه چې څوک د بیا پیل وروسته لیږد بیا پیلوي۔

ګام 3: آیا لارښوونه ریښتینې اړتیا ده؟

هغه لیست د ترټولو کوچني انتخاب صادقانه بیه ده، او له همدې امله ټیمونه په پای کې یو څو هیر شوي شالید کمانډونه په مدیریت شوي شي بدلوي۔ بدلون په اتوماتيک ډول VPN نه دی۔ که اړتیا لا هم یو TCP پورټ وي، د مستند مالک سره څارل شوی لیږد د پوښ څخه ارزانه چلېږي او په هغو لارو ناکام کیږي چې تاسو یې وینئ۔ د ښکلا اندازه کولو دمخه عملیاتي مالکیت اندازه کړئ۔

لارښوونه هغه وخت سم ځواب کیږي چې لارښوونه اړتیا وي۔ ډېر اپلیکیشنونه چې عادي IP اړیکې ته اړتیا لري، پروتوکولونه چې TCP لیږد یې نشي وړلی، یا خدمتونه چې د هوسټونو ترمنځ ځي، ټول یوه خوا ته اشاره کوي۔

پوښ ګډونوالو ته پته او لار ورکوي، بیا ریښتینې کار پیل کیږي: نه تکراري حدونه، د لارې مالکیت، DNS، ثبت، لغوه کول او کله چې سیال ورک شي څه پیښیږي۔ له دې څخه هیڅ د پتې سره نه راځي۔ په پوښ کې منل شوی سیال هم په هدف کې د هر عملیات لپاره په اتوماتيک ډول واکمن نه دی، نو د خدمت کچې تصدیق پاتې کیږي۔

له هغې وروسته څه لرئ

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

دا سفر هلته پای ته رسیږي چېرته چې پیل شو، د خدمت سره۔ هغه پوله وټاکئ چې ریښتینی ترافیک پوښي او هغه سیالان تاییدوي چې تاسو یې تاییدول غوښتل، بیا ولیکئ چې لاسرسی څنګه نوی، څارل او لرې کیږي۔ د OpenSSH حواله هغه ځای دی چې د تنګ تړون ژمنې دمخه د لیږد انتخابونه تایید کړئ۔ که تاسو د لرې کولو ګام په یوه جمله نشئ تشریح کولی، پوله له ستونزې لویه ده۔