Tailscale Serve і Funnel: хто насамрэч можа адкрыць спасылку?

Абедзве каманды публікуюць лакальны сэрвіс праз HTTPS-імя Tailscale, і з машыны, якая іх запускае, яны выглядаюць амаль аднолькава. Розніца ў тым, хто зможа адкрыць URL пасля гэтага, і менавіта гэтая розніца вызначае, якія сродкі кантролю ўсё яшчэ патрэбны вашай праграме. Serve трымае аўдыторыю ўнутры tailnet, а Funnel пераносіць яе ў публічны інтэрнэт. Спачатку выбірайце аўдыторыю, а потым каманду, якая ёй адпавядае.

Serve адказвае на пытанне ўнутры вашага tailnet

Serve праксіруе лакальны порт або аддае лакальны кантэнт прыладам вашага tailnet, і правілы доступу tailnet па-ранейшаму дзейнічаюць для кожнага запыту. Панэль кіравання на порце 3000 становіцца даступнай па HTTPS-імені, якое могуць развязаць і да якога могуць падключыцца толькі вашыя прылады. Гэта правільнае значэнне па змаўчанні для ўнутраных інструментаў, бо аўдыторыя ўжо аўтэнтыфікавана праз tailnet, і вы не дадаяце публічную паверхню. URL выглядае як звычайны вэб-сайт, і менавіта таму людзі прымаюць яго за такі.

Serve таксама можа далучаць загалоўкі ідэнтычнасці, якія апісваюць карыстальніка tailnet, да запытаў, якія ён перасылае. Калі ваша праграма давярае гэтым загалоўкам як аўтэнтыфікацыі, прывяжыце бэкенд да localhost, каб нішто іншае не магло дабрацца да яго напрамую, бо бэкенд, які слухае на маршрутызаваным адрасе, можа атрымліваць запыты, якія ніколі не праходзілі праз проксі.

Funnel мяняе аўдыторыю на адкрыты інтэрнэт

Funnel публікуе выбраны сэрвіс для ўсіх, у каго ёсць URL, і наведвальнікам не патрэбны кліент, уліковы запіс або членства ў вашым tailnet. Таму рэсурсу патрэбныя аўтэнтыфікацыя, абмежаванне хуткасці і абнаўленні, якія вы ўжывалі б да любога публічнага сэрвісу. Публічныя запыты не нясуць загалоўкаў ідэнтычнасці Serve, таму праграма, якая на іх спадзявалася, пад Funnel зусім не мае ідэнтычнасці карыстальніка. Выбар іншай каманды публікацыі не адказвае на пытанне аўтэнтыфікацыі за вас.

Funnel мае таксама абмежаванні, пра якія падручнік са старэйшага выпуску можа не згадваць. Ён завяршае TLS сертыфікатам, які Tailscale атрымлівае для імені, і падтрымлівае толькі пэўныя порты праслухоўвання, як апісвае дакументацыя Funnel. Калі ваш сэрвіс чакае пратакол, адрозны ад HTTPS, на адным з гэтых портаў, Funnel — гэта няправільны інструмент, а не галаваломка з наладамі.

Чытайце рэжым у кліенце, а не ў порце

Праверце бягучы стан, перш чым нечым дзяліцца, бо абодва рэжымы могуць быць наладжаны для аднаго і таго ж лакальнага порта ў розны час. Каманды стану паведамляюць, што насамрэч апублікавана і каму. Не рабіце выснову пра аўдыторыю з таго, што URL адказвае.

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

Сінтаксіс каманд змяняўся паміж версіямі кліента, таму скапіяваны выклік можа выбраць іншы рэжым, чым вы мелі на ўвазе. Аддавайце перавагу дакументаванай форме для вашай версіі і чытайце пацвярджэнне, якое друкуе кліент, замест таго каб меркаваць. Калі існуюць абедзве налады — Serve і Funnel, — публічная з іх і мае значэнне для экспазіцыі. Скіньце наладу, якую вы не мелі на ўвазе, замест таго каб накладаць зверху яшчэ адну.

Спыніцеся і перачытайце стан, калі вывад не называе аўдыторыю. Апублікаваны URL без указанай аўдыторыі — гэта здагадка, а здагадкі — гэта тое, як унутраныя панэлі трапляюць у публічны інтэрнэт.

Тэстуйце з той аўдыторыяй, якую вы насамрэч мелі на ўвазе

Тэстуйце звонку tailnet, а не з машыны, якая апублікавала сэрвіс. Запыт з прылады tailnet даказвае, што проксі працуе, але ён не даказвае, што старонні чалавек выключаны. Выкарыстоўвайце сетку без кліента Tailscale і без маршруту ў 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

Для ўнутранай панэлі знешні запыт павінен не змагчы падключыцца або не прайсці аўтарызацыю, а ўнутраны запыт павінен паспяхова выканацца з той ідэнтычнасцю, якую вы чакаеце. Для публічнага сэрвісу знешні запыт павінен паспяхова выканацца, а праграма павінна запатрабаваць свае ўласныя ўліковыя даныя. Запішыце, які з гэтых двух вынікаў вы назіралі, бо адзін URL пра гэта не скажа. Калі вынік супрацьлеглы задуме, спачатку выдаліце публічную наладу, а потым разбірайцеся.

Публікацыя сэрвісу — гэта не тое ж рашэнне, што выбар вузла выхаду, які кантралюе, адкуль выходзіць ваш зыходны трафік. Serve і Funnel адказваюць, хто можа дабрацца да таго, што вы запускаеце, а вузел выхаду адказвае, адкуль выглядаюць вашыя ўласныя злучэнні. Трымайце гэтыя два пытанні асобна, і параўнанне застанецца простым.