Hairpin NAT: ولې د VPN پای ټکی له داخله ناکامېږي

د VPN سرور چې له ګرځنده شبکې ځواب ورکوي خو له کاناپې نه ناکامېږي، معمولاً د سند ستونزه نه ده. د LAN دننه کارن له روټر څخه غواړي چې هغه بسته وژباړي چې منزل یې د روټر خپله عامه پته ده، یعنې بسته باید ووځي او سمدلاسه بېرته راشي. دا حرکت hairpinning بلل کېږي، او ډېر روټرونه یا یې نه پلي کوي یا یوازې هغه وخت کوي چې چکباکس فعال وي. همدا دباندې ازموینه بریالۍ کېدل ګډوډي رامنځته کوي، ځکه ثابتوي چې اورېدونکی او د لېږد قاعده سم دي.

بسته وځي او بېرته راځي

بسته تعقیب کړئ. کارن عامه نوم حل کوي، عامه پتې ته نښلېږي، او د روټر د منزل NAT منزل داخلي سرور ته بیا لیکي. د سرور ځواب د کارن LAN پتې ته خطاب شوی، نو د روټر د LAN انټرفیس له لارې بېرته ځي، پرته له دې چې هغه NAT قاعده چې سرچینه به یې بېرته ژباړله هېڅکله تېره کړي.

اوس کارن له هغې پتې څخه بسته ترلاسه کوي چې هېڅکله ورته څه نه دي لېږلي، او غورځوي یې. همدا ناهمغړیتوب ټول خرابي ده.

RFC 4787 په دې حالت کې د NAT له اړخه تمه کېدونکی چلند بیانوي، او لنډه نسخه دا ده چې په عمل کې اختیاري دی حتی هغه ځای چې په تیوري کې ټاکل شوی. ځینې روټرونه دا تنظیم NAT loopback بولي، نور یې hairpin NAT یا NAT reflection بولي، او ځینې هېڅ نه ښیي. هغه روټر چې دا نلري غلط تنظیم شوی نه دی؛ هغه عادي کار کوي، او سمون بل ځای ته اړه لري. له ناکامې ځایي ازموینې مه پایله اخلئ چې عامه لېږد قاعده غلطه ده.

کتنه 1: دواړه لارې جدا ازموئ

له LAN دباندې، په هغه پروفایل سره ونښلئ چې ریښتینی کارن به یې کاروي او تایید کړئ چې ناسته جوړېږي. له داخله، په هماغه پروفایل سره عامه پتې ته ونښلئ او دقیقه تېروتنه او وخت ولیکئ.

دقیقه ځایي ازموینه کوربه نوم ساتي او یوازې پته بدلوي: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ غوښتنه عامه پتې ته لېږي او په هماغه وخت کې سم سرور نوم وړاندې کوي. دا د نوم حل ستونزه د ژباړې ستونزې څخه جلا کوي، او کله چې هماغه نوم له کافي څخه کار وکړي، دواړه په اسانۍ ګډوډېږي. یادونه وکړئ چې کارن په TCP نښلون کې ناکامېږي که وروسته په TLS کې، ځکه لومړی ژباړې ته او دویم هویت ته اشاره کوي.

کتنه 2: ولولئ چې سرور څه ویني

تر ټولو ګټوره کتنه د سرور لید دی. په VPN کوربه کې د کارن LAN پتې او د روټر LAN پتې ته فلټر شوی نیول چل کړئ، بیا ځایي هڅه تکرار کړئ. که هېڅ ونه رسیږي، بسته له ژباړې ژوندی نه دی وتلی.

که نښلون د کارن پتې پر ځای د روټر LAN پتې څخه راشي، hairpinning پېښېږي او سرچینه بیا لیکل شوې ده. دا کارکوونکې ترتیبه ده، خرابي نه ده.

کتنه 3: پرته له دې چې دباندې لار ته لاس ووهئ سم یې کړئ

درې ملاتړ شوي بڼې شته، د اغېزې د وړانګې په زیاتېدونکي ترتیب. تر ټولو تنګه ووېشل شوی DNS دی: داخلي ریکارډ خپور کړئ تر څو هماغه سرور نوم د LAN کارنانو لپاره داخلي پتې ته حل شي، چې عامه لاره په بشپړه توګه پرېږدي. بل د روټر مستند loopback یا reflection اختیار فعالول دي، که وي، او یوازې په دې خدمت یې پلي کول. تر ټولو پراخه د روټر پر سر source-NAT قاعده ده چې له LAN څخه راغلی ټرافیک سرور ته بیا لیکي تر څو ځواب د روټر له لارې بېرته راشي؛ په Linux روټر کې دا د سرور پتې او پورټ سره سمون لرونکې MASQUERADE قاعده POSTROUTING ده. درېواړه دباندې لاره نه لمس کوي، او همدا ځانګړنه باید وساتل شي.

د ځایي لارې دباندې لارې ته د ورته کولو لپاره نااړونده پورټ لېږد مه پراخوئ، او د ستونزې د تېښتې لپاره خدمت بل پورټ ته مه وړوئ. دواړه بدلونونه بدلوي چې دباندې نړۍ چېرته رسېدلی شي، یوازې د داخلي نړۍ لیدل شوي شی سمول.

ووېشل شوي DNS یوه تله لري چې یادول یې ارزښت لري. کوربه نوم په خپل سري IP بدلول بدلوي چې کارن څه تصدیقوي، نو داخلي ریکارډ باید لا هم د سند نوم سره سمون ولري.

کتنه 4: وروسته دواړه لارې تایید کړئ

دباندې هڅه له LAN دباندې تکرار کړئ، داخلي هڅه په هماغه پروفایل تکرار کړئ، او تایید کړئ چې د سرور لاګ یوه بریا او یوه چوپتیا نه، بلکې دوه جلا بریالۍ ناستې ښیي. بیا وګورئ چې نور کارنان لا هم اورېدونکي ته رسېږي او شخصي سرچینو ته لارې نه دي بدلې شوې.

ریکارډ لنډ وساتئ: هر کارن کومه پته کارولې، سرور څه لیدلي، او له درېیو سمونونو کوم پلي شوی. د RFC 4787 hairpinning غوښتنې دلته هغه مرجع ده چې له NAT څخه څه تمه کېږي، او تشریح کوي چې ولې پرته له دې ځانګړنې روټر نورمال چلند کوي. هغه ځایي ناکامي چې دباندې نړۍ تکرارولی نه شي، تر هغو چې خلاف یې ثابت شي د ژباړې پوښتنه ده، نو همداسې یې ازموئ.