Tailscale Serve sau Funnel: cine poate deschide de fapt linkul?

Ambele comenzi publică un serviciu local printr-un nume HTTPS Tailscale, iar de pe mașina care le rulează par aproape identice. Diferența este cine poate ajunge la URL după aceea, iar această diferență decide ce controale mai are nevoie aplicația ta. Serve ține publicul în interiorul tailnetului, iar Funnel îl mută pe internetul deschis. Alege mai întâi publicul, apoi comanda care i se potrivește.

Serve răspunde la o întrebare în interiorul tailnetului tău

Serve face proxy către un port local sau servește conținut local dispozitivelor din tailnetul tău, iar regulile de acces ale tailnetului se aplică în continuare fiecărei cereri. Un panou pe portul 3000 devine accesibil la un nume HTTPS pe care doar dispozitivele tale îl pot rezolva și la care se pot conecta. Aceasta este setarea implicită corectă pentru instrumentele interne, pentru că publicul este deja autentificat de tailnet și nu adaugi o suprafață publică. URL-ul arată ca un site web obișnuit, și exact de aceea oamenii îl iau drept unul.

Serve poate atașa, de asemenea, antete de identitate care descriu utilizatorul tailnetului cererilor pe care le trimite mai departe. Dacă aplicația ta se bazează pe aceste antete ca autentificare, leagă backendul de localhost ca nimic altceva să nu îl poată atinge direct; un backend care ascultă pe o adresă rutabilă poate primi cereri care nu au trecut niciodată prin proxy.

Funnel schimbă publicul pe internetul deschis

Funnel publică un serviciu ales pentru oricine are URL-ul, iar vizitatorii nu au nevoie de client, de cont sau de calitatea de membru al tailnetului tău. Resursa are deci nevoie de autentificarea, limitarea ratei și patch-urile pe care le-ai aplica oricărui serviciu public. Cererile publice nu poartă antetele de identitate ale tailnetului de la Serve, așa că o aplicație care se baza pe ele nu are nicio identitate de utilizator sub Funnel. Alegerea unei alte comenzi de publicare nu răspunde în locul tău la întrebarea despre autentificare.

Funnel are și constrângeri pe care un tutorial dintr-o versiune mai veche poate să nu le menționeze. Încheie TLS cu un certificat pe care Tailscale îl obține pentru nume și acceptă doar anumite porturi de ascultare, cum descrie documentația Funnel. Dacă serviciul tău așteaptă un alt protocol decât HTTPS pe unul dintre acele porturi, Funnel este instrumentul greșit și nu un puzzle de configurare.

Citește modul din client, nu din port

Verifică starea actuală înainte de a partaja ceva, pentru că cele două moduri pot fi configurate pentru același port local la momente diferite. Comenzile de stare raportează ce este publicat de fapt și pentru cine. Nu deduce publicul din faptul că un URL răspunde.

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

Sintaxa comenzilor s-a schimbat între versiunile clientului, așa că o invocare copiată poate selecta un alt mod decât cel intenționat. Preferă forma documentată pentru versiunea pe care o rulezi și citește confirmarea tipărită de client în loc să o presupui. Dacă există atât o configurație Serve, cât și una Funnel, cea publică este cea care contează pentru expunere. Resetează configurația pe care nu ai intenționat-o în loc să adaugi alta peste ea.

Oprește-te și recitește starea dacă ieșirea nu numește publicul. Un URL publicat fără un public declarat este o presupunere, iar presupunerile sunt felul în care panourile interne ajung pe internetul deschis.

Testează cu publicul pe care chiar l-ai intenționat

Testează din afara tailnetului, nu de pe mașina care a publicat serviciul. O cerere de pe un dispozitiv din tailnet demonstrează că proxy-ul funcționează; nu demonstrează că un străin este exclus. Folosește o rețea fără client Tailscale și fără rută către 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

Pentru un panou intern, cererea externă ar trebui să eșueze la conectare sau să eșueze la autorizare, iar cererea internă ar trebui să reușească cu identitatea pe care o aștepți. Pentru un serviciu public, cererea externă ar trebui să reușească și aplicația ar trebui să își ceară propriile credențiale. Notează care dintre cele două rezultate le-ai observat, pentru că URL-ul singur nu îți spune. Dacă rezultatul este opusul intenției, elimină mai întâi configurația publică și investighează după aceea.

Publicarea unui serviciu nu este nici aceeași decizie ca alegerea unui nod de ieșire, care controlează pe unde iese traficul tău de ieșire. Serve și Funnel răspund la cine poate ajunge la ceva ce rulezi; un nod de ieșire răspunde la de unde par să vină propriile tale conexiuni. Ține cele două întrebări separate și comparația rămâne simplă.