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 отговарят кой може да достигне нещо, което вие управлявате, а изходният възел отговаря откъде изглежда, че идват собствените ви връзки. Дръжте двата въпроса отделно и сравнението остава просто.