Ambaŭ komandoj publikigas lokan servon per Tailscale HTTPS-nomo, kaj de la maŝino, kiu ilin rulas, ili aspektas preskaŭ idente. La diferenco estas, kiu poste povas atingi la URL-on, kaj tiu diferenco decidas, kiujn kontrolojn via aplikaĵo ankoraŭ bezonas. Serve tenas la publikon ene de la tailnet, dum Funnel movas ĝin al la malferma interreto. Unue elektu la publikon, poste elektu la komandon, kiu kongruas kun ĝi.

Serve respondas demandon ene de via tailnet

Serve prokuras lokan pordon aŭ servas lokan enhavon al aparatoj en via tailnet, kaj la aliraj reguloj de la tailnet daŭre validas por ĉiu peto. Panelo sur pordo 3000 fariĝas atingebla per HTTPS-nomo, kiun nur viaj aparatoj povas solvi kaj al kiu ili povas konektiĝi. Tio estas la ĝusta implicita agordo por internaj iloj, ĉar la publiko jam estas aŭtentikigita de la tailnet kaj vi ne aldonas publikan surfacon. La URL aspektas kiel ordinara retejo, kaj ĝuste tial homoj prenas ĝin kiel tian.

Serve ankaŭ povas aldoni identigajn kapliniojn, kiuj priskribas la tailnet-uzanton, al la petoj, kiujn ĝi plusendas. Se via aplikaĵo fidas tiujn kapliniojn kiel aŭtentikigon, ligu la malantaŭan servon al localhost, por ke nenio alia povu rekte atingi ĝin; malantaŭa servo aŭskultanta sur enkursigebla adreso povas ricevi petojn, kiuj neniam pasis tra la prokuro.

Funnel ŝanĝas la publikon al la malferma interreto

Funnel publikigas elektitan servon al ĉiu, kiu havas la URL-on, kaj vizitantoj ne bezonas la klienton, konton aŭ membrecon en via tailnet. La rimedo do bezonas la aŭtentikigon, rapidlimigon kaj flikaĵojn, kiujn vi aplikus al iu ajn publika servo. Publikaj petoj ne portas la tailnet-identigajn kapliniojn de Serve, do aplikaĵo, kiu fidis al ili, havas neniun uzantidentecon sub Funnel. Elekti alian publikigan komandon ne respondas la aŭtentikigan demandon anstataŭ vi.

Funnel ankaŭ havas limigojn, kiujn lernilo el pli malnova eldono eble ne mencias. Ĝi finas TLS per atestilo, kiun Tailscale akiras por la nomo, kaj ĝi subtenas nur certajn aŭskultajn pordojn, kiel priskribas la dokumentaro de Funnel. Se via servo atendas protokolon alian ol HTTPS sur unu el tiuj pordoj, Funnel estas la malĝusta ilo, ne konfigura enigmo.

Legu la reĝimon de la kliento, ne de la pordo

Kontrolu la nunan staton antaŭ ol kunhavigi ion, ĉar la du reĝimoj povas esti agorditaj por la sama loka pordo en malsamaj tempoj. La statkomandoj raportas, kio efektive estas publikigita kaj al kiu. Ne konkludu la publikon el la fakto, ke URL respondas.

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

La komanda sintakso ŝanĝiĝis inter klientaj versioj, do kopiita alvoko povas elekti alian reĝimon ol tiu, kiun vi intencis. Preferu la dokumentitan formon por la versio, kiun vi rulas, kaj legu la konfirmon, kiun la kliento presas, anstataŭ supozi ĝin. Se ekzistas kaj Serve- kaj Funnel-agordo, la publika estas tiu, kiu gravas por elmeto. Restarigu la agordon, kiun vi ne intencis, anstataŭ sterni alian sur ĝin.

Haltu kaj relegu la staton, se la eligo ne nomas la publikon. Publikigita URL sen deklarinta publiko estas konjekto, kaj konjektoj estas kiel internaj paneloj finiĝas sur la malferma interreto.

Testu kun la publiko, kiun vi efektive intencis

Testu de ekster la tailnet, ne de la maŝino, kiu publikigis la servon. Peto de tailnet-aparato pruvas, ke la prokuro funkcias, sed ĝi ne pruvas, ke fremdulo estas ekskludita. Uzu reton sen Tailscale-kliento kaj sen itinero en la 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

Por interna panelo, la ekstera peto devus malsukcesi konekti aŭ malsukcesi rajtigon, kaj la interna peto devus sukcesi kun la identeco, kiun vi atendas. Por publika servo, la ekstera peto devus sukcesi kaj la aplikaĵo devus peti siajn proprajn akreditaĵojn. Notu, kiun el tiuj du rezultoj vi observis, ĉar la URL sola ne diras ĝin al vi. Se la rezulto estas la malo de la intenco, unue forigu la publikan agordon kaj poste esploru.

Publikigi servon ankaŭ ne estas la sama decido kiel elekti elirnodon, kiu regas, de kie via elira trafiko forlasas. Serve kaj Funnel respondas, kiu povas atingi ion, kion vi funkciigas; elirnodo respondas, de kie viaj propraj konektoj ŝajnas veni. Tenu la du demandojn aparte kaj la komparo restas simpla.

Rilataj artikoloj