Tailscale Serve edo Funnel: nork dezake benetan esteka ireki?
Serve-k zerbitzu bat zure tailnet-ekin partekatzen du; Funnel-ek internet irekian erakusten du. Konparatu publikoa, identitate-goiburuak eta Funnel-ek onartzen dituen portuak.
Bi komandoek zerbitzu lokal bat argitaratzen dute Tailscale HTTPS izen baten bidez, eta exekutatzen dituen makinatik ia berdinak dirudite. Aldea da geroago nor irits daitekeen URL-ra, eta alde horrek erabakitzen du zure aplikazioak oraindik zein kontrol behar dituen. Serve-k publikoa tailnet barruan mantentzen du; Funnel-ek internet irekira eramaten du. Aukeratu lehenengo publikoa, eta gero harekin bat datorren komandoa.
Serve-k zure tailnet barruko galdera bati erantzuten dio
Serve-k portu lokal bat proxifikatzen du edo eduki lokala zerbitzatzen die zure tailnet-eko gailuei, eta tailnet-aren sarbide-arauak oraindik ere aplikatzen zaizkie eskaera guztiei. 3000 portuko panel bat HTTPS izen batean eskuragarri bihurtzen da, zure gailuek soilik ebatz eta konekta dezaketena. Hori da barne-tresnetarako balio lehenetsi egokia, publikoa tailnet-ek dagoeneko autentifikatu duelako eta ez duzulako gainazal publikorik gehitzen. URL-a webgune arrunt bat bezala agertzen da, eta horregatik hartzen du jendeak halakotzat.
Serve-k identitate-goiburuak ere erants diezazkioke birbidaltzen dituen eskakizunei, tailnet erabiltzailea deskribatzen dutenak. Zure aplikazioak goiburu horietan autentifikazio gisa fidatzen bada, lotu backend-a localhost-era, beste ezerk zuzenean iritsi ez dadin; helbide bideragarri batean entzuten duen backend-ak sekula proxy-tik igaro ez diren eskaerak jaso ditzake.
Funnel-ek publikoa internet irekira aldatzen du
Funnel-ek hautatutako zerbitzu bat argitaratzen du URL-a duen edonorentzat, eta bisitariek ez dute bezeroa, konturik edo zure tailnet-eko kidetzarik behar. Baliabideak, beraz, edozein zerbitzu publikori aplikatuko zeniokeen autentifikazioa, tasa-muga eta adabakiak behar ditu. Eskaera publikoek ez dituzte Serve-ren tailnet identitate-goiburuak eramaten, beraz, haietan oinarritzen zen aplikazioak ez du erabiltzaile-identitaterik Funnel-en pean. Argitaratzeko beste komando bat aukeratzeak ez dizu autentifikazio-galderari erantzuten.
Funnel-ek bertsio zaharrago bateko tutorialak aipa ez ditzakeen murrizketak ere baditu. TLS amaitzen du Tailscale-k izenerako lortzen duen ziurtagiri batekin, eta entzuteko portu jakin batzuk baino ez ditu onartzen, Funnel dokumentazioak deskribatzen duen bezala. Zure zerbitzuak HTTPS ez den protokolo bat espero badu portu horietako batean, Funnel tresna okerra da, ez konfigurazio-asetai bat.
Irakurri modua bezeroan, ez portuan
Egiaztatu uneko egoera ezer partekatu aurretik, bi moduak portu lokal bererako une desberdinetan konfigura baitaitezke. Egoera-komandoek benetan zer argitaratu den eta norentzat adierazten dute. Ez ondorioztatu publikoa URL batek erantzuten duenetik.
tailscale serve status
tailscale funnel status
tailscale status --json | head -40
Komandoen sintaxia aldatu egin da bezero-bertsioen artean, beraz, kopiatutako deialdi batek nahi ez zenuen modu bat hauta dezake. Hobetsi exekutatzen duzun bertsiorako dokumentatutako forma, eta irakurri bezeroak inprimatzen duen baieztapena, hura suposatu beharrean. Serve eta Funnel konfigurazioak badaude, publikoa da esposizioarentzat garrantzitsua dena. Berrezarri nahi ez zenuen konfigurazioa, haren gainean beste bat jarri beharrean.
Gelditu eta irakurri berriro egoera, irteerak publikoa izendatzen ez badu. Publiko adierazirik gabeko URL argitaratua susmo bat da, eta susmoak dira barne-panelak internet irekian amaitzeko bidea.
Probatu benetan nahi zenuen publikoarekin
Probatu tailnet-etik kanpotik, zerbitzua argitaratu zuen makinatik ez. Tailnet-eko gailu baten eskaerak proxy-a funtzionatzen duela frogatzen du, baina ez du frogatzen arrotz bat baztertuta dagoenik. Erabili Tailscale bezerorik eta tailnet-era biderik ez duen sare bat.
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
Barne-panel baterako, kanpoko eskaerak konexioan huts egin behar du edo autorizazioan huts egin behar du, eta barruko eskaerak zu espero duzun identitatearekin arrakasta izan behar du. Zerbitzu publiko baterako, kanpoko eskaerak arrakasta izan behar du eta aplikazioak bere kredentzialak eskatu behar ditu. Idatzi bi emaitzetatik zein ikusi duzun, URL-ak bakarrik ez baitizu esaten. Emaitza asmoaren kontrakoa bada, kendu lehenengo konfigurazio publikoa eta ikertu geroago.
Zerbitzu bat argitaratzea ez da irteera-nodo bat aukeratzearen erabaki bera, irteera-nodoak zure irteerako trafikoa nondik uzten duen kontrolatzen baitu. Serve-k eta Funnel-ek erantzuten dute nor irits daitekeen zuk exekutatzen duzun zerbaitetara; irteera-nodoak erantzuten du zure konexioak nondik datozela ematen duen. Eutsi bi galderak bereizita eta konparazioa sinplea izaten jarraitzen du.