How do I install the Servico Interno Tailscale skill?

Run npx skillmds@latest add slayer1dev/servico-interno-tailscale in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Servico Interno Tailscale safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Servico Interno Tailscale?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Servico Interno Tailscale free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Servico Interno Tailscale?

Slayer1Dev (@slayer1dev) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Servico Interno Tailscale by slayer1dev

Name: Servico Interno Tailscale
Rating: 4.2 (5 reviews)
Author: Slayer1Dev

Servico Interno Tailscale

Expõe um serviço que roda em casa ou no escritório com domínio e HTTPS válido, acessível só pela VPN privada, sem abrir porta no roteador. Use ao publicar dashboard, API ou app interno que não deve ficar na internet pública.

Slayer1Dev Updated Sep 22, 2026

File contents

Serviço interno com domínio e HTTPS

Para quando existe algo rodando numa máquina sua e você quer acessar de qualquer lugar — com domínio de verdade e cadeado no navegador — sem expor na internet.

A tentação é abrir porta no roteador e apontar um DNS. Isso coloca o serviço no alcance de qualquer varredura automatizada, e daí em diante você depende da autenticação da aplicação ser perfeita. Melhor não estar alcançável.

O que resolve isso

Uma VPN mesh (Tailscale, por exemplo) já dá a cada máquina um nome e um IP estáveis. Com o proxy embutido, você ganha HTTPS com certificado publicamente válido em um domínio que só resolve dentro da sua rede.

https://maquina.sua-rede.ts.net:8443  →  http://127.0.0.1:3051

Ninguém fora da VPN alcança. Não há porta aberta. O certificado é real, então o navegador não reclama.

Passos

1. Confirme que o DNS da VPN está ligado. O nome precisa resolver:

getent hosts maquina.sua-rede.ts.net

Sem isso, você só tem o IP — funciona, mas sem HTTPS válido.

2. Suba o serviço em 127.0.0.1, não em 0.0.0.0.

Este é o ponto que a maioria erra. Bind em 0.0.0.0 expõe na rede local inteira — Wi-Fi de visita, TV, qualquer coisa comprometida no mesmo roteador. O proxy da VPN alcança 127.0.0.1 normalmente; não há motivo para abrir mais.

3. Configure o proxy:

tailscale serve --bg --https=8443 http://127.0.0.1:3051
tailscale serve status

Portas HTTPS costumam ser limitadas a um conjunto fixo (443, 8443, 10000). Use uma por serviço.

4. Verifique do cliente, não do host:

curl -o /dev/null -w "%{http_code}\n" https://maquina.sua-rede.ts.net:8443/

Sem -k. Com -k você prova que existe TLS, não que o certificado é confiável.

Armadilhas

Frameworks de frontend recusam host desconhecido. Vite e similares checam o Host e respondem "Blocked request". Adicione o domínio em allowedHosts antes de testar, senão você depura o proxy à toa.
VPN em container precisa enxergar o host. Se o cliente da VPN roda em container, ele precisa de modo host na rede — senão 127.0.0.1 é o container, não a máquina.
O serviço precisa sobreviver a reboot. Coloque em systemd com enable, e habilite linger se for serviço de usuário, senão ele morre no logout.
Duas portas, dois serviços, um domínio. Frontend e API no mesmo host: sirva o frontend e deixe ele fazer proxy de /api. Um origin só evita CORS e simplifica o cookie.

Quando NÃO usar

Se o serviço precisa ser público (site, landing page, webhook de terceiro). Webhook de marketplace ou gateway de pagamento não alcança endereço de VPN.
Se pessoas de fora precisam acessar sem instalar a VPN.

Nesses casos é hospedagem pública com autenticação de verdade — e aí a proteção passa a ser a aplicação, não a rede.

---name: servico-interno-tailscaledescription: Expõe um serviço que roda em casa ou no escritório com domínio e HTTPS válido, acessível só pela VPN privada, sem abrir porta no roteador. Use ao publicar dashboard, API ou app interno que não deve ficar na internet pública.---# Serviço interno com domínio e HTTPSPara quando existe algo rodando numa máquina sua e você quer acessar de qualquer lugar — com domínio de verdade e cadeado no navegador — **sem** expor na internet.A tentação é abrir porta no roteador e apontar um DNS. Isso coloca o serviço no alcance de qualquer varredura automatizada, e daí em diante você depende da autenticação da aplicação ser perfeita. Melhor não estar alcançável.## O que resolve issoUma VPN mesh (Tailscale, por exemplo) já dá a cada máquina um nome e um IP estáveis. Com o proxy embutido, você ganha HTTPS com certificado publicamente válido em um domínio que **só resolve dentro da sua rede**.```https://maquina.sua-rede.ts.net:8443 → http://127.0.0.1:3051```Ninguém fora da VPN alcança. Não há porta aberta. O certificado é real, então o navegador não reclama.## Passos**1. Confirme que o DNS da VPN está ligado.** O nome precisa resolver:```bashgetent hosts maquina.sua-rede.ts.net```Sem isso, você só tem o IP — funciona, mas sem HTTPS válido.**2. Suba o serviço em `127.0.0.1`, não em `0.0.0.0`.**Este é o ponto que a maioria erra. Bind em `0.0.0.0` expõe na rede local inteira — Wi-Fi de visita, TV, qualquer coisa comprometida no mesmo roteador. O proxy da VPN alcança `127.0.0.1` normalmente; não há motivo para abrir mais.**3. Configure o proxy:**```bashtailscale serve --bg --https=8443 http://127.0.0.1:3051tailscale serve status```Portas HTTPS costumam ser limitadas a um conjunto fixo (443, 8443, 10000). Use uma por serviço.**4. Verifique do cliente, não do host:**```bashcurl -o /dev/null -w "%{http_code}\n" https://maquina.sua-rede.ts.net:8443/```Sem `-k`. Com `-k` você prova que existe TLS, não que o certificado é confiável.## Armadilhas- **Frameworks de frontend recusam host desconhecido.** Vite e similares checam o `Host` e respondem "Blocked request". Adicione o domínio em `allowedHosts` antes de testar, senão você depura o proxy à toa.- **VPN em container precisa enxergar o host.** Se o cliente da VPN roda em container, ele precisa de modo `host` na rede — senão `127.0.0.1` é o container, não a máquina.- **O serviço precisa sobreviver a reboot.** Coloque em `systemd` com `enable`, e habilite `linger` se for serviço de usuário, senão ele morre no logout.- **Duas portas, dois serviços, um domínio.** Frontend e API no mesmo host: sirva o frontend e deixe ele fazer proxy de `/api`. Um origin só evita CORS e simplifica o cookie.## Quando NÃO usar- Se o serviço precisa ser público (site, landing page, webhook de terceiro). Webhook de marketplace ou gateway de pagamento **não** alcança endereço de VPN.- Se pessoas de fora precisam acessar sem instalar a VPN.Nesses casos é hospedagem pública com autenticação de verdade — e aí a proteção passa a ser a aplicação, não a rede.

Frequently asked questions