دواړه کمانډونه یو ځایي خدمت د Tailscale HTTPS نوم له لارې خپروي، او له هغه ماشین چې دوی پرې چلیږي نږدې ورته ښکاري۔ توپیر په دې کې دی چې وروسته څوک کولی شي URL ته ورسیږي، او همدا توپیر ټاکي چې ستاسو اپلیکیشن لا کوم کنټرولونه ته اړتیا لري۔ Serve لیدونکي د tailnet په داخل کې ساتي، او Funnel هغوی خلاص انټرنیټ ته لیږدوي۔ لومړی لیدونکي وټاکئ، بیا هغه کمانډ وټاکئ چې ورسره ځي۔

Serve ستاسو د tailnet په داخل کې یوې پوښتنې ته ځواب وایي

Serve یو ځایي پورټ پروکسي کوي یا ستاسو د tailnet په وسیلو ځایي منځپانګه وړاندې کوي، او د tailnet د لاسرسي قواعد لا هم پر هر غوښتنه پلي کیږي۔ په 3000 پورټ کې یو ډشبورډ په داسې HTTPS نوم کې د لاسرسي وړ کیږي چې یوازې ستاسو وسیلې یې حل کولی شي او ورسره نښلولی شي۔ دا د داخلي وسایلو لپاره سم ډیفالټ دی، ځکه لیدونکي دمخه د tailnet لخوا تصدیق شوي او تاسو کومه عامه سطحه نه زیاتوئ۔ URL د یو عادي وېبسایټ په څیر ښکاري، او همدا لامل دی چې خلک یې هماغسې ګڼي۔

Serve کولی شي هغه غوښتنو ته چې لیږدوي د هویت سرلیکونه هم ضمیمه کړي چې د tailnet کاروونکی تشریح کوي۔ که ستاسو اپلیکیشن پر هغو سرلیکونو د تصدیق په توګه باور لري، بیکاینډ له localhost سره وتړئ تر څو بل څه په مستقیم ډول ورته نه رسیږي؛ هغه بیکاینډ چې په یوې لارښوونې وړ پتې اورېدل کوي کولی شي داسې غوښتنې ترلاسه کړي چې هېڅکله د پروکسي له لارې نه دي تېرې شوې۔

Funnel لیدونکي خلاص انټرنیټ ته بدلوي

Funnel ټاکل شوی خدمت هر هغه چا ته خپروي چې URL لري، او لیدونکو ته کلاینټ، حساب یا ستاسو په tailnet کې غړیتوب ته اړتیا نشته۔ نو ځکه سرچینې ته هغه تصدیق، د کچې محدودیت او پیچونه اړین دي چې پر هر عامه خدمت به یې تطبیقوئ۔ عامه غوښتنې د Serve د tailnet هویت سرلیکونه نه لېږدوي، نو هغه اپلیکیشن چې پر هغو تکیه کړې وه د Funnel لاندې هېڅ د کاروونکي هویت نه لري۔ د بلې خپرولو کمانډ ټاکل ستاسو په ځای د تصدیق پوښتنې ته ځواب نه وایي۔

Funnel هم هغه محدودیتونه لري چې د زوړ خپریدو ټیوټوریل یې ممکن یاد نه کړي۔ دا TLS د هغه سند سره پای ته رسوي چې Tailscale د نوم لپاره ترلاسه کوي، او یوازې ځانګړي اورېدلو پورټونه ملاتړ کوي، لکه څنګه چې د Funnel اسناد بیانوي۔ که ستاسو خدمت په هغو پورټونو کې یو کې له HTTPS پرته بل پروتوکول تمه لري، Funnel غلط وسیله ده نه د ترتیباتو معما۔

حالت له پورټ نه، له کلاینټ څخه ولولئ

له هر څه شریکولو دمخه اوسنی حالت وګورئ، ځکه دواړه حالتونه کولی شي په بېلابېلو وختونو کې د یوې ځایي پورټ لپاره تنظیم شي۔ د حالت کمانډونه راپور ورکوي چې په رښتیا څه خپاره شوي او د چا لپاره۔ له دې حقیقت چې URL ځواب وایي لیدونکي مه اټکل کوئ۔

tailscale serve status
tailscale funnel status
tailscale status --json | head -40

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

که تولید لیدونکي ونوموي نه، ودروئ او حالت بیا ولولئ۔ پرته له اعلان شویو لیدونکو خپور شوی URL یوه انګېرنه ده، او انګېرنې هغه لار ده چې داخلي ډشبورډونه خلاص انټرنیټ ته رسیږي۔

له هغو لیدونکو سره ازموینه وکړئ چې په رښتیا مو نیت درلود

له tailnet بهر ازموینه وکړئ، نه له هغه ماشین چې خدمت یې خپور کړ۔ د tailnet وسیلې غوښتنه ثابتوي چې پروکسي کار کوي، خو دا نه ثابتوي چې یو پردی وتلی دی۔ هغه شبکه وکاروئ چې Tailscale کلاینټ نه لري او tailnet ته لار نه لري۔

curl -sI https://host.tailnet-name.ts.net
curl -sI https://host.tailnet-name.ts.net --resolve host.tailnet-name.ts.net:443:203.0.113.10

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

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

اړوندې مقالې