Tailscale Serve чи Funnel: хто насправді може відкрити посилання?

Serve ділиться сервісом із вашим tailnet, а Funnel виставляє його у відкритий інтернет. Порівняйте аудиторію, заголовки ідентичності та порти, які дозволяє Funnel.

Обидві команди публікують локальний сервіс через HTTPS-ім'я Tailscale, і з машини, яка їх виконує, вони виглядають майже однаково. Різниця в тому, хто згодом може дістатися URL, і ця різниця визначає, які засоби контролю вашій програмі ще потрібні. Serve тримає аудиторію всередині tailnet, а Funnel переносить її у відкритий інтернет. Спершу виберіть аудиторію, а потім команду, що їй відповідає.

Serve відповідає на питання всередині вашого tailnet

Serve проксіює локальний порт або віддає локальний вміст пристроям у вашому tailnet, і правила доступу tailnet і далі діють для кожного запиту. Панель на порту 3000 стає доступною за HTTPS-іменем, яке можуть розв'язати й до якого можуть підключитися лише ваші пристрої. Це правильне значення за замовчуванням для внутрішніх інструментів, адже аудиторія вже автентифікована tailnet і ви не додаєте публічної поверхні. URL виглядає як звичайний вебсайт, і саме тому люди сприймають його за такий.

Serve також може прикріплювати до запитів, які пересилає, заголовки ідентичності, що описують користувача tailnet. Якщо ваша програма довіряє цим заголовкам як автентифікації, прив'яжіть backend до localhost, щоб ніщо інше не могло дістатися до нього напряму; backend, що слухає на маршрутизованій адресі, може отримувати запити, які ніколи не проходили через проксі.

Funnel змінює аудиторію на відкритий інтернет

Funnel публікує вибраний сервіс для кожного, хто має URL, і відвідувачам не потрібні клієнт, обліковий запис чи членство у вашому tailnet. Тому ресурсу потрібні автентифікація, обмеження швидкості та виправлення, які ви застосували б до будь-якого публічного сервісу. Публічні запити не несуть заголовки ідентичності 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 відповідають, хто може дістатися до того, що ви запускаєте; вихідний вузол відповідає, звідки нібито надходять ваші власні з'єднання. Тримайте ці два питання окремо, і порівняння залишається простим.

Схожі статті