د VPN د پای ټکي نوم د خصوصي خدمت له نوم سره: دوه مالکین

دوه نومونه کولی شي یوه څانګه بیان کړي او په بشپړ توګه بېلو پوښتنو ځواب ووايي۔ vpn.branch.example لیرې ملګري ته وایي چې VPN پای ټکی چېرته ومومي، او باید د کوم تونل له رامنځته کیدو دمخه حل شي۔ inventory.branch.example مجاز کاروونکي ته وایي چې خصوصي اپلیکیشن چېرته اوسیږي، او یوازې د تونل له پورته کیدو وروسته اهمیت لري۔ د یوه ساتنه د بل لپاره هېڅ نه کوي۔

د دواړو له ډیبګ کولو دمخه دواړو ریکارډونو ته نوم ورکړئ

دواړه د خپلو مالکینو سره ولیکئ۔ د پای ټکي لپاره ولیکئ چې عامه پته څوک تازه کوي او VPN کلاینټ خپل ځواب څنګه تازه کوي۔ د خدمت لپاره ولیکئ چې د خصوصي پتې مالک څوک دی، کوم زون ریکارډ ساتي او کوم حل کوونکي باید د هغه لپاره ځواب ووایي۔

دا لنډه لیست په دې برخه کې تر ټولو عام غلط تشخیص بندوي: د یوې فعالې څانګې تونل بیا پیلول ترڅو هغه ریکارډ سم شي چې په بشپړه توګه د هغه په دننه کې اوسیږي۔ تونل د خدمت نوم لپاره ترانسپورت دی؛ دا د هغه واک نه دی۔

کله چې بدلون وړاندیز شي، وپوښتئ چې د دوو ریکارډونو کوم یو ته لاس ورکوي۔ که څوک ځواب نشي ویلی، بدلون د مهالویش لپاره چمتو نه دی۔

پای ټکی باید د کوم تونل له رامنځته کیدو دمخه حل شي

فرض کړئ چې د څانګې انټرنیټ اړیکه نوې عامه پته ترلاسه کوي۔ د پای ټکي تازه کوونکی نوې پته خپروي، او لیرې VPN تطبیق باید بدل شوی ځواب ولولي۔ کوم حل کوونکی چې دا ځواب ورکوي باید پرته له تونل لاسرسي وړ وي، که نه کلاینټ د هغه نوم پسې منډې وهي چې یوازې د هغه شي سره د نښلیدو وروسته یې حل کولی شي چې نه یې مومي۔

دا د پیل تکیه د روښانه ویلو وړ ده، ځکه چې کله ټول داخلي حل کوونکي د VPN شاته وي، په ناڅاپي ډول یې جوړول اسانه دي۔ د پای ټکي پلټنې لپاره د تونل دمخه لار وساتئ، او د دې پرځای چې فرض کړئ نوی ځواب سمدلاسه اخیستل کیږي، د کلاینټ د بیا نښلیدو چلند تایید کړئ۔

متحرک DNS هم هغه حدود لري چې د ریکارډ تازه کول یې نه شي تیرولی۔ د ریکارډ تازه کول هیڅ د اور دیوال پورټ نه خلاصوي، هیڅ NAT نقشه نه جوړوي او د هیچا هویت نه ثابتوي۔ خپره شوې پته چې پورټ یې بند وي هغه کلاینټ ورکوي چې سم حل کیږي او بیا هم له هیچا سره نښلیدلی نه شي۔

په پای کې، فعال کلاینټ کولی شي تر بیا نښلیدو پورې کیش شوې پای ټکی وکاروي۔ په خپلو یادښتونو کې خپرول، کیش او د بیا نښلیدو تګلاره جلا کړئ، ترڅو زوړ ملګری خراب تازه کوونکی ونه ګڼل شي۔

د خدمت نوم بیانوي چې اپلیکیشن چېرته اوسیږي

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

دلته دوه تازه کولو میتودونه یوځای کیږي۔ RFC 2136 په زون کې د DNS ریکارډونو د زیاتولو او ړنګولو پروتوکول تعریفوي، پداسې حال کې چې یو سوداګریز متحرک DNS چمتو کوونکی د بل هدف لپاره بشپړ توپیر لرونکې HTTP API وړاندې کولی شي۔ د یوه کارول دا نه مانا چې بل ستاسو په چاپیریال کې شته۔ د هغه پر ضد د تازه کوونکي لیکلو دمخه وګورئ چې ستاسو زون واقعا کوم میتود مني۔

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

دواړه لارې جلا ازموئ

پای ټکی له تونل بهر او خدمت له هغه دننه وګورئ، او پایلې د دوو خپلواکو حقیقتونو په توګه وساتئ:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

که لومړنۍ پوښتنه پاتې راشي، ستونزه په عامه خپرولو یا د تونل دمخه حل لار کې ده، او هیڅ داخلي بدلون به مرسته ونه کړي۔ که دوهمه پته بیرته راوګرځوي خو دریمه د تونل له لارې هیڅ لار نه ښیي، DNS پوړ سم دی او د لیږد تګلاره نه ده۔

د هرې پتې بدلون وروسته جوړه چل کړئ، او ولیکئ چې کوم ریکارډ وخوځید۔ هغه سپارل چې یوازې وایي «DNS تازه شو» بل انجینر د دې په اټکل کولو کې پرېږدي چې د دوو ژوند دورو څخه کوم یو واقعا چلیږي۔