Tailscale Serve apo Funnel: kush mund ta hapë vërtet lidhjen?

Të dy komandat publikojnë një shërbim lokal përmes një emri HTTPS të Tailscale, dhe nga makina që i ekzekuton ato duken pothuajse identike. Dallimi është kush mund ta arrijë URL-në më pas, dhe ky dallim vendos se cilat kontrolle i duhen ende aplikacionit tënd. Serve e mban publikun brenda tailnet-it, ndërsa Funnel e zhvendos atë në internetin e hapur. Zgjidhni fillimisht publikun, pastaj komandën që i përshtatet.

Serve i përgjigjet një pyetjeje brenda tailnet-it tënd

Serve bën proxy të një porte lokale ose shërben përmbajtje lokale për pajisjet në tailnet-in tënd, dhe rregullat e aksesit të tailnet-it vazhdojnë të zbatohen për çdo kërkesë. Një panel në portën 3000 bëhet i arritshëm në një emër HTTPS që vetëm pajisjet e tua mund ta zgjidhin dhe të lidhen me të. Ky është parazgjedhja e saktë për mjetet e brendshme, sepse publiku tashmë është autentikuar nga tailnet-i dhe nuk po shton një sipërfaqe publike. URL-ja duket si një faqe interneti normale, dhe pikërisht për këtë njerëzit e marrin për të tillë.

Serve mund t'u bashkëngjitë kërkesave që përçon edhe tituj identiteti që përshkruajnë përdoruesin e tailnet-it. Nëse aplikacioni yt u beson këtyre titujve si autentikim, lidhe backend-in me localhost që asgjë tjetër të mos mund ta arrijë drejtpërdrejt; një backend që dëgjon në një adresë të rrugëtueshme mund të marrë kërkesa që nuk kanë kaluar kurrë përmes proxy-t.

Funnel e ndryshon publikun në internetin e hapur

Funnel publikon një shërbim të zgjedhur për këdo që ka URL-në, dhe vizitorët nuk kanë nevojë për klientin, një llogari ose anëtarësi në tailnet-in tënd. Prandaj burimi ka nevojë për autentikimin, kufizimin e ritmit dhe arnimet që do të zbatoje për çdo shërbim publik. Kërkesat publike nuk mbajnë titujt e identitetit të tailnet-it të Serve, kështu që një aplikacion që mbështetej tek ata nuk ka fare identitet përdoruesi nën Funnel. Zgjedhja e një komande tjetër publikimi nuk i përgjigjet pyetjes së autentikimit në vendin tënd.

Funnel ka edhe kufizime që një udhëzues nga një version më i vjetër mund të mos i përmendë. Ai e përfundon TLS me një certifikatë që Tailscale e merr për emrin, dhe mbështet vetëm porta të caktuara dëgjimi, siç përshkruan dokumentacioni i Funnel. Nëse shërbimi yt pret një protokoll tjetër përveç HTTPS në një nga ato porta, Funnel është mjeti i gabuar dhe jo një enigmë konfigurimi.

Lexoje modalitetin te klienti, jo te porta

Kontrollo gjendjen aktuale përpara se të ndash diçka, sepse të dy modalitetet mund të konfigurohen për të njëjtën portë lokale në kohë të ndryshme. Komandat e statusit raportojnë çfarë është publikuar vërtet dhe për kë. Mos e nxirr publikun nga fakti që një URL përgjigjet.

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

Sintaksa e komandave ka ndryshuar midis versioneve të klientit, kështu që një thirrje e kopjuar mund të zgjedhë një modalitet tjetër nga ai që keni synuar. Prefero formën e dokumentuar për versionin që ekzekutoni dhe lexo konfirmimin që shtyp klienti në vend që ta supozosh. Nëse ekzistojnë të dyja konfigurimet, Serve dhe Funnel, ajo publike është ajo që ka rëndësi për ekspozimin. Rivendos konfigurimin që nuk e kishe synuar në vend që të shtresosh një tjetër mbi të.

Ndal dhe rilexo statusin nëse dalja nuk e emërton publikun. Një URL e publikuar pa publik të deklaruar është një hamendje, dhe hamendjet janë mënyra se si panelet e brendshme përfundojnë në internetin e hapur.

Testo me publikun që kishe vërtet në mendje

Testo nga jashtë tailnet-it, jo nga makina që publikoi shërbimin. Një kërkesë nga një pajisje në tailnet provon që proxy funksionon; nuk provon që një i huaj është përjashtuar. Përdor një rrjet pa klient Tailscale dhe pa rrugë drejt tailnet-it.

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

Për një panel të brendshëm, kërkesa e jashtme duhet të dështojë në lidhje ose të dështojë në autorizim, dhe kërkesa e brendshme duhet të ketë sukses me identitetin që pret. Për një shërbim publik, kërkesa e jashtme duhet të ketë sukses dhe aplikacioni duhet të kërkojë kredencialet e veta. Shëno cilin nga këto dy rezultate vëzhgove, sepse URL-ja vetëm nuk ta thotë. Nëse rezultati është i kundërt me qëllimin, hiq fillimisht konfigurimin publik dhe heto më pas.

Publikimi i një shërbimi nuk është as i njëjti vendim si zgjedhja e një nyje daljeje, e cila kontrollon nga del trafiku yt dalës. Serve dhe Funnel përgjigjen se kush mund të arrijë diçka që ekzekuton ti; një nyje daljeje përgjigjet se nga duken se vijnë lidhjet e tua. Mbaji të dyja pyetjet të ndara dhe krahasimi mbetet i thjeshtë.