[Tasslehoff]

Originariamente inviato da gsorrentino

L'80% dei siti amministrativi europei funziona così, e richiede che TU abbia l'IP fisso per collegarti a loro, cosa che tu puoi fare solo con una VPN...
Considera che nel mondo bancario tu ti colleghi ad un ip pubblico loro che fa passare i dati solo se usi una VPN con IP pubblico tuo fisso.
Praticamente per usare il loro ip pubblico i tuoi pacchetti devono girare su una connessione privata fra di voi, dove il tuo IP deve corrispondere anche all'indirizzo su cui dai servizio.
Il privato è più semplice...

Aspetta, se parliamo di VPN è un altro tema, è chiaro che se fai un site-to-site IPSec l'endpoint deve essere raggiungibile su un ip pubblico, ma non stiamo parlando di questo.

Io mi riferivo a coloro che si illudono di poter trustare un servizio solo perchè è in ascolto su un indirizzo ip specifico o una specifica subnet, è follia.

Originariamente inviato da gsorrentino

Entrambi passano la configurazione...
E sul mettere le mani, se sei una piccola entità o hai un FW preso da Amazon su consiglio "dell'esperto" o hai chi te lo gestisce, magari lo stesso provider che ti dà la connettività e quindi puoi avere ritardi problemi.
Se stai gestendo una struttura grande lo sai per forza fare o hai dei collaboratori che lo sanno.
Per darti un'idea, lo studio professionisti (avvocati, geometri, etc.) probabilmente ha questo problema, un'azienda da 30 dipendenti che si occupa di gestire il traffico di spedizioni con gli aerei cargo decisamente no.

Tu stai dando per scontate troppe cose, e tra queste c'è il fatto che un'organizzazione grande abbia le risorse per fare una cosa del genere, quella piccola no, oppure quella che si affida a un certo tipo di gestione sia gente raffazzonata che si affida al primo che passa.

Non è così, e le aziende non sono rimaste congelate agli anni '90 dove c'era necessariamente il Centro Operazioni Rete o il tecnico di datacenter, per carità ci sono ancora ma non è scontato che sia così.

Io ad esempio lavoro per una realtà del genere, e ti assicuro che pur non avendo alcuna infrastruttura fisica (giusto il routerino ethernet per le ftth delle nostre sedi) abbiamo una infrastruttura decisamente più complessa dei nostri clienti da 10 o 20k dipendenti e datacenter a non finire.

A prescindere da questo tu pensi che chi invece ha ancora il datacenter, router, bilanciatori F5 sparsi ovunque e tutto il cucuzzaro hw che si porta dietro non possa beneficiare di una CDN e un servizio tipo Cloudflare Tunnel?

Io ho schiere di direttori e funzionari di PA che farebbero carte false per liberarsi di tutto il circo volante del datacenter, e pian piano lo stanno facendo, perchè se devi pubblicare un servizio, tra farlo con 3 click e Cloudflare Tunnel e dover passare settimane di riunioni per definire, regole fw, reverse proxy, modifiche dns, compilare modulistica, comprare i certificati (e trovare il modo di pagarli), far fare ai moduli il giro delle 7 chiese per le firme di rito, poi moduli che rimbalzano indietro perchè qualcuno non li ha capiti o non si è inteso su chi deve fare il terminatore ssl, e rifare call... etc etc... solo un pazzo preferirebbe la seconda opzione rispetto alla prima.

Originariamente inviato da gsorrentino

Il 90% delle volte se sei appoggiato a DNS seri è una cosa banale.
Ovviamente richiede che tu sappia i concetti di come funzioni un DNS.

No mi spiace, ma anche qui stai banalizzando qualcosa che non è banale.
Non si tratta di sapere o non sapere cos'è e come funziona un DNS, non si tratta di rocket science, il problema non è il DNS in se ma è il casino organizzativo che comporta una modifica al DNS.

Guarda ti faccio un esempio banalissimo che mi è successo nelle scorse settimane.

Migrazione di un portale da una istance a un cluster K8s, cambia l'ip pubblico da quello della instance al load balancer davanti agli ingress K8s.
Il portale rispondeva a diversi hostname di diversi domini, per alcuni di questi domini la gestione era nostra (lavoro fatto in 3 min + tempi di propagazione ridicoli grazie a TTL abbassato appositamente nei giorni precedenti), in altri no.

Risultato: la migrazione che doveva essere completata in 1h max si è conclusa dopo più di 2 settimane, perchè chi doveva modificare i record su alcuni domini non si svegliava, questo ha creato una coesistenza dei portali sui due ambienti, casino di riallineamento contenuti, redattori nel panico, etc etc...

Come vedi le criticità non sono solo tecniche, sono anche organizzative e logistiche.

Se questi portali fossero stati sotto Cloudflare Tunnel la migrazione sarebbe stata pressochè istantanea, e nessuno, ma proprio NESSUNO avrebbe dovuto nemmeno preoccuparsi del DNS, nel momento in cui partiva il deployment con cloudflared sul cluster K8s tutto avrebbe preso ad girare sulla nuova infrastruttura, seplice e pulito.

Originariamente inviato da gsorrentino

Non ti poni il problema perché la parte DNS e certificati la fanno loro...
Pure il nas che ho a casa lo fa da solo...

Chiaro, ma non è tanto questione di chi lo fa, la questione è: da una parte hai un processo manuale, che coinvolge N pezzi ciascuno con le proprie criticità, strumenti, che richiede le proprie competenze, etc etc... dall'altra hai un processo automatizzato e gestibile da una console e una procedura precisa e che non richiede accessi o modifiche ai dispositivi che compongono l'infrastruttura.

Originariamente inviato da gsorrentino

Ma ci sono casi in cui questo non lo puoi fare.

Ma certo, ci saranno sempre casi limiti, ma visto che questi strumenti Deo Gratias ci sono... beh usiamoli almeno nei casi in cui si può.

Originariamente inviato da gsorrentino

Di norma, se gestisco io ho il controllo di tutti i clienti.
Per quei pochi che non ho questa facoltà le cose sono pianificate e i tempi di risposta sono più corti dei TTL del DNS.

E' chiaro che ti occupi di clienti piccoli o molto stazionari.

Al contrario, dalla mia esperienza sono proprio i clienti più grossi quelli dove ci sono più complicazioni, perchè sono quelli con le procedure più arzigogolate e assurde.

Ma a prescindere da questo capisci anche tu che c'è una bella differenza tra "da me fila tutto liscio perchè i miei clienti sono bravi" a "uso un servizio che non richiede l'intervento del cliente e intervengo direttamente dalla console".

Se i tuoi clienti sono skillati, pazienti, efficienti, veloci, buon per te... ma non è scontato che sia così, e anzi nella gran parte dei casi non è così.
Se i tuoi clienti non sono skillati, pazienti, efficienti e veloci casca tutto il castello di carte, non sei d'accordo? Se il tuo cliente ci mette 2 settimane per cambiare un CNAME sul dns e non sa cos'è il TTL che fai? Cambi cliente?

Gli puoi anche chiedere di passarti la gestione del DNS, ma se non vuole non puoi certo costringerlo...

Originariamente inviato da gsorrentino

Si vede che non lo hai mai usato, o lo usi male.

Può essere, sono solo più di vent'anni che lavoro su ogni tipo di reverse proxy, da quelli enterprise tipo IBM ISAM (ex Tivoli Access Manager) o F5 o Netscaler ai classici reverse proxy fatti con i soliti webserver fino ai vari HAProxy alle ultime novità tipo Traefik o Caddy.

Originariamente inviato da gsorrentino

I reverse proxy, lato LAN, puntano sempre ad indirizzi interni che se sposti tutto (come l'esempio che ti ho fatto) non viene toccato.
In tutta la mia vita i reverse proxy li ho toccati solo per aggiungere nuovi servizi o togliere quelli deprecati. Mai toccati anche nel caso di cambio completo della connettività del site.

Anzi, ti dirò di più. Con le attuali configurazioni dei DNS e dei server, non li tocchi neanche se salta tutto e devi andare sul Disaster Recovery posizionato in un site geografico diverso e che ha per forza un'altra classe LAN.

Ovviamente solo per quei clienti che non hanno un "Alvays On" su due site geografici diversi, perchè sennò il problema di configurazione non esiste neanche.

Anche qui, stai facendo un esempio che prende come caso tipico quello che ti ritrovi a lavorare tu, per carità magari a te non interesserà ma il mondo è un po' più vario.

Ti faccio un esempio, metti che il tuo datacenter viene smantellato e tutti i servizi migrati su un provider cloud, o migrati su un mega cluster K8s.
Pensi che la topologia della tua rete resterebbe la stessa? Pensi di non dover toccare la configurazione del tuo reverse proxy?
Ma senza arrivare a questi estremi (estremi mica tanto visto che sono ormai casistiche abbastanza comuni...) se cambia il backend del tuo VIP lo dici tu stesso, devi mettere mano al reverse proxy e dirgli di bilanciare su questo nuovo ip piuttosto che sul vecchio.

Ci vuole tanto a fare questo operazione? Ci vuole poco? Chissenefrega, non è importante, quello che è importante è che per farlo ci devi essere tu o un tuo collega, con accessi amministrativi sul reverse proxy, chi chiede la modifica deve aprirvi un ticket, il ticket magari deve essere approvato dal vostro manager, etc etc etc...

Con un servizio tipo Cloudflare tunnel, come ho ampiamente descritto, sparisce tutto questo.
Sposto l'applicazione X dal mio datacenter a Azure o a una istance su AWS o un cluster K8s su Google Cloud o su un server fisico su Hetzner?
Benissimo, nel momento in cui faccio partire cloudflared sul nuovo site il servizio è online e raggiungibile, punto, senza aprire ticket, senza avere accessi amministrativi sul reverse proxy, senza far aprire la tal porta dalla DMZ dove sta il reverse proxy verso la LAN dove sta il nuovo backend, senza trustare certificati sul reverse proxy per cifrare il traffico tra lo stesso e il backend, niente, nulla di tutto questo.

Originariamente inviato da gsorrentino

Se fai le cose da piccolo si, se le fai da medio grande no perchè sei tenuto ad avere tante di quelle procedure di sicurezza che i "dettagli" che dici tu sono la èparte minore e scorrono come un fiume dopo che hai aperto una diga.

Ma la procedura puoi anche implementarla anche per la modifica su un tunnel Cloudflare, semplicemente la semplifichi all'inverosimile, riduci il numero di persone coinvolte e quindi i possibili errori.

Con una infrastruttura classica una modifica banale coinvolge magari 2, 3, 4 o più persone, ciascuna che deve fare il suo pezzettino, che ha bisogno della sua autorizzazione, e che può fare il suo piccolo errore.
Con una infrastruttura che fa uso di Cloudflare Tunnel, la modifica la fa dalla console direttamente il responsabile tecnico, approvata dal manager di turno o dal responsabile del servizio, la fa una persona sola, al vertice, che controlla l'architettura e nessun altro, e non c'è il tizio del reverse proxy che fa l'errore di battitura, quello del firewall che apre la porta sbagliata, quello del dns che crea il record sbagliato perchè ha battuto a mano anzichè fare copy&paste.

Le procedure si possono applicare anche in quel caso, ma c'è un solo step, anzichè N, c'è un solo controllo anzichè N, c'è una sola persona che può commettere l'errore e non N, è palese che sia un approccio più efficiente e meno rischioso.

Originariamente inviato da gsorrentino

E se non puoi interromperlo?

Ma nessun problema, di modi per non creare interruzioni ce ne sono a bizzeffe.
Crei un tunnel nuovo sul nuovo site o dove hai spostato la vm, quando entrambi sono attivi sposti l'esposizione del servizio da un tunnel all'altro e la CDN di Cloudflare smisterà il traffico sul nuovo tunnel.

Io ho lavorato per più di 15 anni su servizi critici che in caso di interruzione configuravano reati e avrebbero fatto scattare articoli in prima pagina sui principali quotidiani, e ho perso il conto delle interruzioni causate da eccessiva complessità, apparati gestiti da gente incompetente o per cattiva gestione delle risorse, tutte quelle cose che sono presenti in architetture tradizionali con il classico datacenter, firewall enterprise, reverse proxy enterprise, disaster recovery con tutti i crismi, etc etc...

Tutte cose che se fossero stati disponibili servizi come Cloudflare Tunnel si sarebbero potuti evitare, e con esse le figuracce di sindaci, presidenti di regioni, ministri e amministratori delegati di turno...

Originariamente inviato da gsorrentino

Mai cambiato un certificato se non per rinnovo...Sposti il site o cambi la connettività, mica cambi il dominio del cliente.

No, mi sa che non hai capito l'esempio che ho fatto. Se sposti un servizio da un site all'altro e sul nuovo hai un altro reverse proxy, sul quel nuovo reverse proxy che dovrà fare da endpoint https dovrai spostare il certificato, la chiave privata e relativa ca, giusto?
Ecco con Cloudflare Tunnel no.

Poi tu mi dirai che voi avete una batteria di reverse proxy su site differenti che si allineano e si portano dietro anche i certificati, ma per l'ennesima volta ti invito ad astrarre dal tuo caso particolare a un caso generale.

E non c'entra grande o piccolo, perchè ti assicuro che ci sono organizzazioni molto grandi e con grandi budget che questi problemi li hanno eccome.

Poi chi ha parlato di cambio di dominio?

Anche nel caso che hai citato tu stesso del rinnovo di un certificato (già il fatto di doverlo fare a manazza nell'era del protocollo ACME non è una indicazione di grande solidità), con Cloudflare Tunnel semplicemente te ne dimentichi, punto (beh quello già con Let's Encrypt, ma questo è un altro tema).

Originariamente inviato da gsorrentino

No perchè hai norme che con le ultime novità Europee puoi evitare solo se gestisci clienti che hanno il giardino solo in Italia e hanno attività dove NON registrano nulla del cliente.

Spiegati.
Perchè se ti riferisci a questioni legate a GDPR e simili Cloudflare fornisce anche i regional services, e a prescindere da questo quelle norme riguardano esclusivamente il site dove vengono conservati i dati di accesso, non il transito di connessioni TCP cifrate.