Primul pas – decizia Tailscale vs Cloudflare Access

Am evaluat ambele soluții pe trei clienți de mărimi diferite. Iată cum se decantează decizia:

                    Tailscale                Cloudflare Access (ZTNA)
                    ─────────                ────────────────────────
Model               Mesh peer-to-peer        Reverse proxy în cloud CF
Conexiune           Direct între device-uri  Toată traficul prin CF edge
Aplicații suportate Orice (TCP/UDP)         HTTP/HTTPS + SSH/RDP
                                             (cu CF tunnel)
Identitate          Google/MS/GitHub/Okta    Google/MS/Okta/SAML
ACL                 Tailscale ACL (JSON)     CF Access policies (UI)
Latență             Foarte mică (mesh)       +20-50ms (edge proxy)
Cost                $5/user/lună (Premium)   $3/user/lună (Standard)
On-prem servers     Da, perfect              Da, prin Cloudflared tunnel

Concluzia practică: pentru clienți care vor RDP/SSH la servere on-prem și aplicații desktop legacy → Tailscale. Pentru clienți care expun mai mult web-app-uri interne (Confluence, GitLab self-hosted, dashboard-uri) → Cloudflare Access. Doi din cei trei clienți au mers pe Tailscale, unul pe Cloudflare.

Deznodământul – migrarea reală în 3 weekend-uri

La cel mai mare client (45 de utilizatori, 12 servere on-prem), planul a fost:

Week 1:
  - Tailscale tailnet creat, conectat la Google Workspace pentru SSO
  - 12 servere on-prem instalate cu tailscale + tailscale up --advertise-routes
  - ACL inițial: permite tot, doar pentru testat conectivitatea
  - 5 utilizatori pilot din IT testează 1 săptămână

Week 2:
  - ACL real implementat:
      * dev_team → acces la dev-* + git-server
      * finance → acces la sql-finance-* + file-share-finance
      * support → acces la jump-host + ticketing-server
      * admin → acces la tot (cu MFA mandatory)
  - 40 de utilizatori migrați în loturi de 10
  - VPN vechi rămâne paralel pentru fallback

Week 3:
  - Verificare log-uri Tailscale - acces real per resursă
  - 3 utilizatori care încă foloseau VPN-ul vechi - investigat de ce
    (răspuns: aplicație Java legacy care nu funcționa în Tailscale fără
     ajustări de MTU)
  - VPN-ul vechi oprit complet
  - Certificatele de pe pfSense revocate

Câteva surprize din producție:

1. Subnet routing nu e enable-by-default. Tailscale conectează device la device, nu device la rețea. Pentru a accesa servere care nu pot rula tailscale (printere, NAS-uri vechi, switch-uri), trebuie un subnet router cu –advertise-routes și approve manual în consola admin.

2. MagicDNS schimbă tot. În loc de “RDP la 10.0.5.42” devine “RDP la win-rdp-01”. Utilizatorii non-IT au înțeles imediat. ACL-ul devine mai citibil. Doar de asta merita migrarea, sincer.

3. ACL-ul Tailscale e JSON, nu UI. Pentru sysadmin OK, pentru clienți unde HR vrea să gestioneze accese – nu OK. Soluția: integrare cu Google Groups, ACL referențiază grupurile, HR adaugă/scoate utilizatori din grup ca pe orice altceva.

Beneficiul real – audit-ul

După 6 luni, primul audit ISO 27001 al clientului. Auditorul cere “log-uri de acces VPN pentru ultimele 90 de zile, granular per resursă”. În Tailscale: descarc CSV cu toate sesiunile, filtru pe utilizator, văd exact când s-a conectat la ce server, cu ce versiune de client, de pe ce IP public.

În VPN-ul vechi, același raport ar fi luat 2 zile de săpat în log-uri pe pfSense și corelat cu DHCP intern. Aici – 5 minute. Auditorul a fost foarte mulțumit, clientul și mai mulțumit. Zero Trust nu e un buzzword corporate, e o schimbare de filozofie: în loc de “ești în rețea, deci ai acces la tot”, devine “fiecare cerere e autentificată, autorizată și logată separat, indiferent de unde vine”. Pentru SMB-uri, Tailscale și Cloudflare Access fac asta accesibil fără echipe dedicate de network security.