Il lento passaggio ad IPv6: cosa succede con il protocollo che avrebbe dovuto salvare Internet dalla fine degli indirizzi IP?

[Tasslehoff]

Originariamente inviato da gsorrentino

Dipende. Se i tuoi servizi richiedono altri servizi, in determinati settori, quello che dici NON funzionerebbe per nulla in quanto essendo servizi ad alta garanzia richiedono scambi di certificati e IP noti o, in alternativa, VPN IPSEC con regole molto rigide.

Aspetta, quello che ho scritto riguarda esclusivamente l'esposizione del servizio a web, poi quello che sta sul backend di Coudflare Tunnel (ovvero il mio servizio che espongo tramite Cloudflare Tunnel) non gli riguarda.

Io posso avere il backend collegato con una vpn site-so-site con tutte le regole più rigide del mondo, posso collegarmi ad un servizio di terze parti con mutua autenticazione con i certificati, posso fare quello che voglio.

Poi invece ti riferisci a qualcuno che si collega al mio servizio e si basa unicamente sull'ip per trustare la comunicazione (e quindi la CDN di Cloudflare gli rompe le scatole perchè l'hostname che uso per esporre il servizio viene risolto con millemila ip), beh allora in quel caso il problema è suo, non certo mio, perchè basarsi su qualcosa di inaffidabile come l'ip (leggasi ip spoofing) per trustare una comunicazione è una cosa che è passata di moda da vent'anni...

Poi signori, siamo nell'anno di grazia 2024, tutti i servizi più critici e utilizzati al mondo stanno dietro CDN, le linee guida stesse delle agenzie per la sicurezza raccomandano l'uso di CDN.

Spento un FW, acceso quello nuovo con la stessa configurazione del vecchio site, spostato i dns, migrato le VM in funzione da un site all'altro senza interrompere i servizi se non i 10 minuti dei FW e DNS.

Probabilmente la migrazione ha richiesto più tempo in background della tua, ma con un totale di oltre 80 VM e 100 TByte di datastore senza interrompere i servizi....

Aspetta, mi sa che hai riassunto un po' troppo velocemente alcuni passaggi.

La configurazione del FW non passa per magia da un dispositivo all'altro.
Quante gente sa mettere mano a un FW? Non dico roba enterprise o carrier grade, ma anche banalmente un PFSense o un Fortigate di fascia SOHO.

Il DNS, si fa in fretta a dire "spostato i dns", ma ammesso che sia un'operazione banale o indolore (e non lo è), è sempre qualcosa in più da fare, mentre invece nell'altro caso non ti poni proprio il problema.

E poi dipende, i servizi che stai hostando sono tutti esposti con hostname di domini che controlli tu? Perchè se non è questo il caso (es dominio X gestito da cliente Pippo, dominio Y gestito da cliente Pluto, dominio Z gestito da cliente Paperino) ti tocca fare il giro del cliente Pippo, Pluto e Paperino e chiedergli di cambiare il record X, Y o Z con il nuovo ip che gli fornirai, loro si prenderanno il loro tempo, magari dovranno ingaggiare qualcuno per farlo perchè non hanno il personale, etc etc etc... morale della favola: passano settimane.

E il reverse proxy? Ne avrai almeno uno sul nuovo site per pubblicare i servizi, mica farai nat su un ip pubblico diverso per ciascun server che ospita qualcosa, giusto? Eh pure su quello bisogna mettere mano.

Vedi? Son tanti i dettagli.

Con una esposizione mediante Cloudflare Tunnel è tutto molto più semplice, prendi la vm dove gira il servizio e cloudflared e la sposti, nel momento in cui è in rete e può fare traffico in outbound il servizio è ripristinato.

Puoi usare hostname di 100 domini diversi, in carico a Pippo, Pluto e Paperino, ma se il token di cloudflared non cambia tu il servizio lo puoi spostare ovunque e sarà sempre pubblicato con lo stesso hostname e con lo stesso certificato, anche se fosse il tuo portatile.

E' tanta roba eh...

Poi uno può anche rispondermi che non gli sta bene perchè tutte quelle attività di cui sopra danno lavoro a tanta gente, il tecnico di rete, lo specialista del FW, quello che deve cambiare i record sul DNS, etc etc...
Lo capisco eh, però non stiamo ragionando di questo, dal punto di vista tecnico con servizi come Cloudflare Tunnel tutte quelle attività sono di fatto inutili per la pubblicazione di servizi, serviranno sicuramente per altre attività ma non per pubblicare servizi online.

[lollo9]

la cosa dei tunnel CF, com'erano anche i vari ngrok ai tempi d'oro è ottima per certi ambienti, ma si può generalizzare solo finché si parla di determinati tipi di dispositivi in azione e solo in determinati scenari.

non è difficile trovarsi in situazioni nelle quali questo non sia proprio possibile, vuoi per requisiti di latenza, legislazione, dispositivi non programmabili a piacere, reti air-gapped e via dicendo.

esempio stupido: un'ambulanza ha dispositivi ECG e Echo doppler che producono risultati da caricare in tempo reale su un server DICOM presente in un pronto soccorso. 4-700 MB ad Echo, me la posso permettere la latenza di un tunnel? Il tunnel è E2E-atomic, come faccio un audit sugli accessi visto che è per definizione impossibile? che gli dico al legislatore prima ed al controllore poi? come imbastisco un tunnel su un diavolo di coso per l'elettrocardiogramma ha giusto un PIC-qualcosa e forse 32MB di ram? hai voglia di docker e VM...
In una catena complessa l'anello debole ci sarà per forza, ma mettersi in mano ad un terzo quando puoi evitare, in certi casi, vuol dire cercarsele proprio.
Per donare l'ordine di grandezza, dispositivi e personale interfacciati sono circa 500.000 ad oggi, nella sola Francia, con crescita a doppia cifra anno su anno. Non 40 dispositivi in croce nella loro nicchia.
Mettiamocene altri 2 milioni in mano alle FDO, in aumento.
ma pure l'automazione, industriale e non.
i semafori di tolosa, lione, parigi ed altre grandi città sono in rete con sensori e camere sul territorio per migliorare la fluidità del traffico. in aumento.
circa 12 milioni di veicoli sono dotati di black box connesse, in aumento.
e via via dicendo...

nel mondo IoT laddove la latenza sia ancora ancora tollerabile, si tira avanti coi NAT, ma già ora si cominciano a fare salti mortali per starci dentro. altroché "gira anche su un rasberryPi". grazie al c... che ci gira, ma quello è grasso che cola.
ma se già prendi scenari, nemmeno troppo "esotici", come tutti quelli real-time a partire dal mondo finance passando per i millemila servizi di monitoring, IPv6 ti risolve un problema in modo banale senza coinvolgere attori terzi, con annessi limiti, rischi, costi e faccende di non-compliance che possono derivarne.

quando hai letteralmente milionate di dispositivi che producono dati, in crescita vertiginosa, devi farci business intelligence sopra, rapidamente e con tutti i crismi del caso, il mondo ZT, ZTA e ZTNA mettono la loro pezza, e bene, sulla sicurezza E2E. ma lo scenario è molto più ampio, così come la sicurezza non può focalizzarsi solo sul E2E

lo dico da grande estimatore dei CF tunnel, che uso da qualche tempo anche io

[destroyer85]

Guarda che il tunnel lo metti sul server e nei due esempi che hai fatto il tunnel funzionerebbe, l'ECG lo puoi archiviare se il dispositivo supporta STOW-RS (un dispositivo portatile dovrebbe nel 2024), i dispositivi IOT se comunicano tramite web-service http possono funzionare tranquillamente.
Questo tipo di tunnel funziona solo se il traffico è HTTP (CloudFlare ha limitazioni sulle dimensioni del POST).

[gsorrentino]

Originariamente inviato da Tasslehoff

....Poi invece ti riferisci a qualcuno che si collega al mio servizio e si basa unicamente sull'ip per trustare la comunicazione (e quindi la CDN di Cloudflare gli rompe le scatole perchè l'hostname che uso per esporre il servizio viene risolto con millemila ip), beh allora in quel caso il problema è suo, non certo mio, perchè basarsi su qualcosa di inaffidabile come l'ip (leggasi ip spoofing) per trustare una comunicazione è una cosa che è passata di moda da vent'anni...

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...

La configurazione del FW non passa per magia da un dispositivo all'altro.
Quante gente sa mettere mano a un FW? Non dico roba enterprise o carrier grade, ma anche banalmente un PFSense o un Fortigate di fascia SOHO.

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.

Il DNS, si fa in fretta a dire "spostato i dns", ma ammesso che sia un'operazione banale o indolore (e non lo è)

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.

, è sempre qualcosa in più da fare, mentre invece nell'altro caso non ti poni proprio il problema.

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...
Ma ci sono casi in cui questo non lo puoi fare.

E poi dipende, i servizi che stai hostando sono tutti esposti con hostname di domini che controlli tu? Perchè se non è questo il caso (es dominio X gestito da cliente Pippo, dominio Y gestito da cliente Pluto, dominio Z gestito da cliente Paperino) ti tocca fare il giro del cliente Pippo, Pluto e Paperino e chiedergli di cambiare il record X, Y o Z con il nuovo ip che gli fornirai, loro si prenderanno il loro tempo, magari dovranno ingaggiare qualcuno per farlo perchè non hanno il personale, etc etc etc... morale della favola: passano settimane.

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.

E il reverse proxy? Ne avrai almeno uno sul nuovo site per pubblicare i servizi, mica farai nat su un ip pubblico diverso per ciascun server che ospita qualcosa, giusto? Eh pure su quello bisogna mettere mano.

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

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.

Vedi? Son tanti i dettagli.

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.

Con una esposizione mediante Cloudflare Tunnel è tutto molto più semplice, prendi la vm dove gira il servizio e cloudflared e la sposti, nel momento in cui è in rete e può fare traffico in outbound il servizio è ripristinato.

E se non puoi interromperlo?

o hostname e con lo stesso certificato, anche se fosse il tuo portatile.

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

Poi uno può anche rispondermi che non gli sta bene perchè tutte quelle attività di cui sopra danno lavoro a tanta gente

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.

[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.

[gsorrentino]

Originariamente inviato da Tasslehoff

...
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.

No, ci sono servizi su IP pubblici che puoi accedere solo se vieni riconosciuto da una VPN.

Ovvero sono su IP pubblico ma l'acceso è solo ed esclusivamente se passi da dentro il Firewall che ha quell'IP pubblico, non da internet dove hai esclusivamente la "Pagina di presenza".

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?

Non è applicabile a molti settori controllati...
PS: L'amministrazione pubblica che citi più avanti NON è un settore controllato.

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.

Ci sono settori dove quello che dici è un binario e non puoi uscire da questo.
Pertanto, il tuo esempio:

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

Infatti, per quanto mi sia capitato accade se non allo studio notarile...
Perché i tuoi clienti evidentemente non hanno a che fare con regole ferree dettate dal settore dove operano.

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ò.

Ecco appunto...ci sono settori dove non sono usabili...non perché non funzionerebbero, ma proprio per come funzionano.

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.

Se il tuo cliente ci mette 2 settimane per cambiare un CNAME sul dns e non sa cos'è il TTL che fai? Cambi cliente?

Sono obbligatorie...per questo non falliscono.

Se il tuo cliente ci mette 2 settimane per cambiare un CNAME sul dns e non sa cos'è il TTL che fai? Cambi cliente?

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.

Che è quello che è successo due volte senza mettere mano a modifiche proxy o altro e senza interrompere i servizi.

Come ho detto, causa le norme da adempiere, le strutture sono astratte rispetto a dove sono poste, pertanto si, la tipologia rimane la stessa...senza riavviare niente.

L'unico obbligo che abbiamo è sul tipo di virtualizzazione, non perché non sia possibile trasmigrarlo, ma perché in quel caso tutto quello che devi adempiere non te lo risolve CLOUDFARE...

Sposto l'applicazione X dal mio datacenter a Azure .... e il backend, niente, nulla di tutto questo.

Esattamente...Niente di tutto questo. Se fai questo significa che la rete non è stata pensata opportunatamente, e in alcuni settori questo NON te lo puoi permettere...Altro che sciocchezze da GDPR...

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...

Tutte cose che già evitiamo...Guasti HW compresi.

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?

No. A parte che i proxy sono in cluster per eventuale scalabilità e ridondanza, non è comunque necessario fare tali passaggi...Neanche con il recente passaggio fra due siti geografici separati da oltre 500 Km.

Anche nel caso che hai citato tu stesso del rinnovo di un certificato ...con Cloudflare Tunnel semplicemente te ne dimentichi, punto (beh quello già con Let's Encrypt, ma questo è un altro tema).

Ecco, per le regole su dette, in entrambi i casi non puoi e già questo taglia fuori il discorso.

Come detto, in alcuni settori, il GDPR e le relative multe sono noccioline.


Comunque, tutto questo a parte, convengo che la soluzione Cloudflare possa essere utile e salvarti il c**o, ma ci sono settori dove già la presenza del terzo (Cloudflare appunto) genera più problemi di quelli che risolve.