Tailscale Serve o Funnel: sino talaga ang makakabukas ng link?

Parehong naglalathala ang dalawang command ng lokal na serbisyo sa pamamagitan ng isang Tailscale HTTPS na pangalan, at mula sa makina na nagpapatakbo sa kanila ay halos magkapareho ang hitsura nila. Ang pagkakaiba ay kung sino ang makakaabot sa URL pagkatapos, at ang pagkakaibang iyon ang nagtatakda kung anong mga kontrol ang kailangan pa ng iyong aplikasyon. Pinapanatili ng Serve ang audience sa loob ng tailnet, habang inililipat ito ng Funnel sa bukas na internet. Piliin muna ang audience, pagkatapos ay piliin ang command na tumutugma rito.

Sinasagot ng Serve ang isang tanong sa loob ng iyong tailnet

Nagpo-proxy ang Serve ng lokal na port o naghahain ng lokal na nilalaman sa mga device sa iyong tailnet, at nalalapat pa rin ang mga patakaran sa pag-access ng tailnet sa bawat kahilingan. Ang dashboard sa port 3000 ay nagiging maabot sa isang HTTPS na pangalan na tanging ang iyong mga device lang ang makakaresolba at makakakonekta. Ito ang tamang default para sa mga panloob na tool, dahil ang audience ay na-authenticate na ng tailnet at hindi ka nagdaragdag ng pampublikong surface. Ang URL ay mukhang ordinaryong website, at iyon mismo ang dahilan kung bakit napagkakamalang ganoon ito ng mga tao.

Maaari ring maglakip ang Serve ng mga identity header na naglalarawan sa tailnet user sa mga kahilingang ipinapasa nito. Kung ang iyong aplikasyon ay nagtitiwala sa mga header na iyon bilang authentication, itali ang backend sa localhost upang walang ibang makakaabot dito nang direkta; ang backend na nakikinig sa isang nairurout na address ay maaaring makatanggap ng mga kahilingang hindi kailanman dumaan sa proxy.

Binabago ng Funnel ang audience tungo sa bukas na internet

Inilalathala ng Funnel ang piniling serbisyo sa sinumang may URL, at hindi kailangan ng mga bisita ang client, account o pagiging miyembro sa iyong tailnet. Kaya naman kailangan ng resource ang authentication, rate limiting at mga patch na ilalapat mo sa anumang pampublikong serbisyo. Ang mga pampublikong kahilingan ay hindi nagdadala ng tailnet identity header ng Serve, kaya ang aplikasyong umasa sa mga iyon ay walang anumang user identity sa ilalim ng Funnel. Ang pagpili ng ibang publishing command ay hindi sumasagot sa tanong ng authentication para sa iyo.

May mga limitasyon din ang Funnel na maaaring hindi banggitin ng tutorial mula sa mas lumang release. Tinatapos nito ang TLS gamit ang certificate na nakukuha ng Tailscale para sa pangalan, at sinusuportahan lamang nito ang ilang partikular na listening port, gaya ng inilalarawan ng dokumentasyon ng Funnel. Kung inaasahan ng iyong serbisyo ang ibang protocol bukod sa HTTPS sa isa sa mga port na iyon, ang Funnel ay maling tool at hindi isang palaisipan sa configuration.

Basahin ang mode mula sa client, hindi mula sa port

Suriin ang kasalukuyang estado bago magbahagi ng anuman, dahil ang dalawang mode ay maaaring i-configure para sa parehong lokal na port sa magkaibang oras. Ang mga status command ay nag-uulat kung ano ang aktwal na nailathala at para kanino. Huwag maghinuha ng audience mula sa katotohanang tumutugon ang isang URL.

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

Nagbago ang syntax ng command sa iba't ibang bersyon ng client, kaya ang kopyadong invocation ay maaaring pumili ng mode na iba sa nilayon mo. Piliin ang dokumentadong anyo para sa bersyong pinapatakbo mo, at basahin ang confirmation na ipinapakita ng client sa halip na ipagpalagay ito. Kung may parehong configuration ng Serve at Funnel, ang pampubliko ang mahalaga para sa exposure. I-reset ang configuration na hindi mo nilayon sa halip na magpatong ng isa pa.

Huminto at basahin muli ang status kung hindi pinapangalanan ng output ang audience. Ang nailathalang URL na walang nakasaad na audience ay isang hula, at ang hula ang paraan kung paano napupunta sa bukas na internet ang mga panloob na dashboard.

Subukan kasama ang audience na talagang nilayon mo

Subukan mula sa labas ng tailnet, hindi mula sa makinang naglathala ng serbisyo. Ang kahilingan mula sa device sa tailnet ay nagpapatunay na gumagana ang proxy; hindi nito pinatutunayan na naibukod ang isang estranghero. Gumamit ng network na walang Tailscale client at walang ruta papasok sa 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

Para sa panloob na dashboard, dapat mabigo ang panlabas na kahilingan sa pagkonekta o mabigo sa authorization, at dapat magtagumpay ang panloob na kahilingan gamit ang identity na inaasahan mo. Para sa pampublikong serbisyo, dapat magtagumpay ang panlabas na kahilingan at dapat hingin ng aplikasyon ang sarili nitong credentials. Itala kung alin sa dalawang resultang ito ang naobserbahan mo, dahil ang URL lamang ay hindi nagsasabi nito. Kung ang resulta ay kabaligtaran ng layunin, alisin muna ang pampublikong configuration at mag-imbestiga pagkatapos.

Ang paglathala ng serbisyo ay hindi rin katulad ng pagpili ng exit node, na kumokontrol kung saan lumalabas ang iyong outgoing traffic. Sinasagot ng Serve at Funnel kung sino ang makakaabot sa isang bagay na pinapatakbo mo; sinasagot ng exit node kung saan lumilitaw na nagmumula ang iyong sariling mga koneksyon. Paghiwalayin ang dalawang tanong at mananatiling simple ang paghahambing.