Tailscale Serve vagy Funnel: ki tudja valójában megnyitni a hivatkozást?

Mindkét parancs egy helyi szolgáltatást tesz közzé egy Tailscale HTTPS-néven keresztül, és a futtató gépről nézve szinte azonosnak tűnnek. A különbség az, hogy utána ki érheti el az URL-t, és ez a különbség dönti el, milyen ellenőrzésekre van még szüksége az alkalmazásodnak. A Serve a tailneten belül tartja a közönséget, a Funnel a nyílt internetre viszi. Először a közönséget válaszd ki, aztán a hozzá illő parancsot.

A Serve a tailneteden belül válaszol egy kérdésre

A Serve proxyz egy helyi portot, vagy helyi tartalmat szolgál ki a tailneted eszközeinek, és a tailnet hozzáférési szabályai továbbra is minden kérésre érvényesek. A 3000-es porton lévő irányítópult egy olyan HTTPS-néven válik elérhetővé, amelyet csak az eszközeid tudnak feloldani és amelyhez csatlakozni. Ez a helyes alapértelmezés a belső eszközök számára, mert a közönséget már hitelesítette a tailnet, és nem adsz hozzá nyilvános felületet. Az URL úgy néz ki, mint egy szokásos webhely, és éppen ezért nézik az emberek annak.

A Serve identitásfejléceket is csatolhat a továbbított kérésekhez, amelyek a tailnet felhasználóját írják le. Ha az alkalmazásod hitelesítésként bízik ezekben a fejlécekben, kösd a backendet a localhosthoz, hogy semmi más ne érhesse el közvetlenül; egy útvonalazható címen figyelő backend olyan kéréseket is kaphat, amelyek soha nem mentek át a proxyn.

A Funnel a nyílt internetre változtatja a közönséget

A Funnel egy kiválasztott szolgáltatást tesz közzé mindenkinek, akinek megvan az URL, és a látogatóknak nem kell a kliens, fiók vagy tagság a tailnetedben. Az erőforrásnak ezért szüksége van a hitelesítésre, a sebességkorlátozásra és a javításokra, amelyeket bármely nyilvános szolgáltatásra alkalmaznál. A nyilvános kérések nem hordozzák a Serve tailnet-identitásfejléceit, így az az alkalmazás, amely rájuk támaszkodott, a Funnel alatt egyáltalán nem rendelkezik felhasználói identitással. Egy másik közzétételi parancs kiválasztása nem válaszol helyetted a hitelesítés kérdésére.

A Funnelnak vannak olyan korlátai is, amelyeket egy régebbi kiadásból származó útmutató talán nem említ. TLS-t azzal a tanúsítvánnyal zár le, amelyet a Tailscale szerez a névhez, és csak bizonyos figyelőportokat támogat, ahogy a Funnel dokumentációja leírja. Ha a szolgáltatásod a HTTPS-től eltérő protokollt vár az egyik ilyen porton, a Funnel a rossz eszköz, és nem egy konfigurációs rejtvény.

A módot a kliensből olvasd ki, ne a portból

Ellenőrizd az aktuális állapotot, mielőtt bármit megosztasz, mert a két mód ugyanahhoz a helyi porthoz különböző időpontokban is beállítható. Az állapotparancsok jelentik, mi van valójában közzétéve és kinek. Ne következtess a közönségre abból, hogy egy URL válaszol.

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

A parancsok szintaxisa kliensverziók között változott, ezért egy másolt hívás a szándékolt módtól eltérőt is választhat. Részesítsd előnyben a dokumentált formát a futtatott verzióhoz, és olvasd el a kliens által kiírt megerősítést ahelyett, hogy feltételeznéd. Ha Serve- és Funnel-konfiguráció is létezik, a nyilvános az, amelyik a kitettség szempontjából számít. Állítsd vissza a nem szándékolt konfigurációt, ahelyett hogy még egyet rétegeznél rá.

Állj meg és olvasd újra az állapotot, ha a kimenet nem nevezi meg a közönséget. A közzétett URL megadott közönség nélkül találgatás, és a találgatások azok, amelyeken keresztül a belső irányítópultok a nyílt internetre kerülnek.

Azzal a közönséggel tesztelj, amelyet valóban szándékoltál

A tailneten kívülről tesztelj, ne arról a gépről, amely közzétette a szolgáltatást. A tailnet-eszközről érkező kérés bizonyítja, hogy a proxy működik; nem bizonyítja, hogy egy idegen ki van zárva. Használj olyan hálózatot, amelynek nincs Tailscale-kliense és nincs útvonala a tailnetbe.

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

Belső irányítópult esetén a külső kérésnek csatlakozási vagy engedélyezési hibával kell meghiúsulnia, a belső kérésnek pedig a várt identitással kell sikerülnie. Nyilvános szolgáltatás esetén a külső kérésnek sikerülnie kell, és az alkalmazásnak a saját hitelesítő adatait kell kérnie. Jegyezd fel, a két eredmény közül melyiket figyelted meg, mert önmagában az URL nem mondja meg. Ha az eredmény ellentétes a szándékkal, először távolítsd el a nyilvános konfigurációt, és utána vizsgálódj.

A szolgáltatás közzététele nem ugyanaz a döntés, mint egy kilépési csomópont kiválasztása, amely azt szabályozza, honnan lép ki a kimenő forgalmad. A Serve és a Funnel arra válaszol, ki érheti el azt, amit futtatsz; egy kilépési csomópont arra válaszol, honnan látszanak érkezni a saját kapcsolataid. Tartsd külön a két kérdést, és az összehasonlítás egyszerű marad.