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

Tasslehoff

27-10-2024, 10:41

Ah una cosina proprio semplice semplice come un routing...
E poi quello è un servizio di protezione dagli attacchi, non un protocollo base.Non si tratta di creare o di inventarsi un protocollo nuovo, sempre si tratta di protocollo TCP/IP, è un modo diverso di esporre i servizi, molto più flessibile, molto più semplice e che permette di superare i limiti della classica pubblicazione basata su NAT (con tutte le sue rotture, nat, regole fw, dns) che in alcuni casi (es provider che non ti assegnano un ip pubblico perchè "nattano" a loro volta) non sono proprio utilizzabili.

Che poi aggiunga anche un layer di protezione dovuto a WAF e controlli di sicurezza della CDN Cloudflare è un altro paio di maniche, ma quello è un "di più" che non c'entra nulla con quello che stavo citando.

Se vuoi puoi aggiungerci (for free) anche Cloudflare Access per avere accesso autenticato (e con MFA) o federato (se hai già un tuo Identity Provider) anche ad applicazioni ad accesso anonimo, ma anche questo è fuori dal tema che stavamo trattando.

Già.. Se cerco su google mi dice direttamente di contattare il reparto vendite per un preventivo :mbe: Più devo mettermi a configurare tutta questa roba al posto del router, che necessita veramente di quattro click. Evidentemente non hai cercato bene, perchè se cerchi anche solo banalmente "cloudflare tunnel howto" il primo risultato dopo la documentazione di Cloudflare (giustamente in cima ai risultati, perchè sta gente sa come si lavora e sa cosa vuol dire SEO) è un sito che presenta un tutoria passo passo su come usare Cloudflare tunnel (LINK (https://www.crosstalksolutions.com/cloudflare-tunnel-easy-setup/)).

E' tutto free, poi se vuoi sottoscrivere i piani a pagamento sei libero di farlo, ma tutto quello che descrivo è free, l'unico costo è quello della registrazione di un dominio (che si può trovare anche al ridicolo costo di 0,99 €/anno)

Configuri i dns di Cloudflare come nameserver autoritativi per il tuo dominio (da fare una tantum per dominio, quindi una volta fatto te ne dimentichi) e usi Cloudflare come DNS per il tuo dominio (pannello di amministrazione top tra l'altro)
vai nella sezione Zero Trust, crei un tunnel e ottieni il token di quel tunnel (oltre alle istruzioni su come installare cloudflared o farlo girare come container con docker, consigliatissimo)
installi cloudflared (o lo fai girare come container) e lo configuri per usare il token che ti ha dato allo step precedente la procedura di creazione del tunnel; fai partire cloudflared e hai stabilito il tunnel
dal pannello di amministrazione del tunnel scegli un hostname a piacere del tuo dominio e gli dici a che indirizzo e porta trovare il servizio sulla tua lan che deve esporre a web tramite il tunnel

Punto, fine, non c'è altro.

Configurazione NAT sul router? Non serve
Configurazione regole firewall sul router? Non serve
Configurazione dns dinamico? Non serve
Configurazione record dns? Non serve
Acquisto certificato https o generazione con Let's Encrypt? Non serve, ci pensa Cloudflare creandoti automaticamente gratis un certificato https wildcard per il tuo dominio, e ti fa direttamente la riscrittura da http a https
Monitoraggio certificato e cron per aggiornare il certificato? Non serve, ci pensa Cloudflare e lo fa in automatico con la propria CA trustata da chiunque.
Se il tuo provider non ti da ip pubblico non devi chiedere nulla o sostenere alcun costo, pubblichi tutto in autonomia.

Aggiungo nel caso non fosse abbastanza evidente:

Cambi provider? Chissenefrega, automaticamente quello che esponi a web sarà automaticamente pubblicato anche col nuovo provider
Cambi router? Chissenefrega, non hai alcun nat o regola firewall da aggiungere al nuovo router o di cui ricordarti
Sposti il tuo servizio altrove (chessò su un VPS)? Chissenefrega, nel momento in cui configuri cloudflared con lo stesso token sul nuovo sistema hai tutto già perfettamente funzionante senza cambi DNS, spostamento di certificati https, riconfigurazione dei cron per rinnovare i certificati https, etc etc...
Sei un'azienda e ti sta sulle palle il tuo fornitore di sistemi attuale (es AWS, Azure o Google Cloud o i server in un rack nel bagno dell'ufficio) e vuoi spostarti su altro? Chissenefrega, sposti tutto fregandotene dei casini cosmici legati a cambi dns, tempi di propagazione, magheggi vari per rendere accessibili i servizi nel transitorio, regole firewall, stupide DMZ, reverse proxy, certificati da spostare... sposti i servizi + cloudflared e hai spostato tutto e tutto è raggiungibile sul nuovo provider senza porti tutti questi problemi, se poi gira tutto dentro dei container tutto diventa estremamente flessibile.

È stato più semplice contattare TIM e chiedere l'indirizzo IP pubblico, sulla mia SIM con giga "illimitati" e gestire tutto il resto direttamente dal router, impostando una VPN e rendendo Plex raggiungibile da remoto. Facile, veloce, sicuro e cifrato. Il fatto che sia cifrato non significa necessariamente che sia sicuo, certamente aggiunge uno strato di sicurezza ma da qui a lavarsene le mani e pensare di essere in una botte di ferro ce ne passa.
Stai sempre esponendo servizi direttamente dal tuo indirizzo ip pubblico attestato su un'interfaccia del tuo router (che in molti casi è un router ridicolo, spesso con buchi sw clamorosi, spesso con firmware arcaici o risorse così ridicole da mandarlo in freeze con un flood da anni '90).

Se oltre alla porta 80 o 443 (tipiche per i servizi con interfaccia web) stai esponendo via NAT altri servizi (chessò l'interfaccia di amministrazione del nas di casa, o la ip camera di turno o l'interfaccia web della stampante di casa) pensi che da web nessuno se ne accorga solo perchè anzichè porte standard stai usando porte fantasiose a piacere? Seriously? :rolleyes:
Siamo ancora al trito e ritrito "security by obscurity"? :doh:

Esporre i servizi via CDN è un enorme balzo in avanti dal punto di vista della sicurezza "per design".

Poi che c'entra la VPN?
Qui non stiamo parlando di VPN, se vuoi anche per quella è ormai diventato TOTALMENTE INUTILE avere un ip pubblico (statico o dinamico) e puoi benissimo collegarti in vpn a casa tua anche se hai un provider che ti piazza dietro nat, ti basta usare Tailscale.
Fa giusto eccezione IPSec, che però ormai è una tecnologia usata praticamente solo per le vpn site-to-site e che in tutti gli altri ambiti è stata soppiantata dalle ben più flessibili vpn ssl.

Anche qui, Tailscale è un servizio di ZTNA completamente free che ti permette di creare una mesh di vpn basate su Wireguard in modo trasparente e senza dover contattare direttamente l'ip dell'interfaccia pubblica del router.

Ragazzi, sia per l'esposizione dei servizi a web che per le vpn il mondo si è un cincinino evoluto, non è che ci sono solo supercazzole tipo AI in giro, c'è ancora gente che si da da fare e cerca di superare i limiti delle tecnologie esistenti proponendo qualcosa di migliore, di più flessibile e che non abbia i limiti delle vecchie tecnologie che girano da 40 anni...

E lo dice uno che è FORTEMENTE conservativo e tutt'altro che propenso a lanciarsi su ogni novità che viene presentata, e anzi, quando c'è una novità la guarda sempre con scetticismo e cerca di capire dov'è la fregatura e dove il marketing sta pompando.

Continuo a non vedere il NAT come una soluzione e preferirei mille volte un indirizzo IPv6 pubblico disponibile facilmente, piuttosto che dover lottare per un IPv4Non devi lottare per nessun IPv4, e il motivo è semplice: non ce n'è alcun bisogno.
I primi anni in cui ho iniziato a lavorare era appena uscito il protocollo HTTP 1.1 e ricordo con stupore (e anche molta ritrosia) l'ostinazione di certe cariatidi che trovavo dai clienti (aziende di prodotto, l'ostinazione e la ritrosia tecnologica sono sempre state una caratteristica tipica delle aziende di quel tipo) che si ostinava a pubblicare servizi ciascuno con il proprio ip pubblico, il nuovo protocollo aveva introdotto il concetto di virtualhost ma loro lo ignoravano e si opponevano dicendo che era "insicuro".

Già da allora fu piantato il primo chiodo nella bara di IPv6, potenzialmente una azienda poteva usare un solo ip pubblico che pubblicare quello che voleva, ovviamente non era così semplice perchè c'erano tanti altri servizi che ne richiedevano (smtp, ipsec etc etc), ma era già un balzo epocale.

Oggi in 10 minuti su AWS puoi tirar su un cluster Kubernetes con EKS dargli quanti nodi worker vuoi, anche migliaia, ed esporre tutto lo scibile possibile con un paio di ip pubblici di un load balancer AWS (almeno 2 per garantire un minimo di ridondanza usando due reti), e persino il traffico di outbound puoi farlo uscire TUTTO (per tutte le migliaia di worker nodes e le migliaia e migliaia di applicazioni che ci possono girare sopra) con 2 ip pubblici (usando i nat gateway, anche qui 2 per ridondanza sulle reti).

Ripeto, stiamo parlando di qualcosa che si tira su in mezz'ora massimo, e che può soddisfare le necessità anche di una mega azienda da migliaia e migliaia di dipendenti, il tutto con l'uso di 2 (max 4) ip pubblici, quando fino a qualche anno fa sarebbe stato necessario dotarsi di diverse classi C di ip pubblici, centinaia e centinaia o migliaia di ip pubblici.

E' questo il motivo per cui probabilmente nessuno di noi avrà mai bisogno di usare IPv6 in tutta la sua carriera lavorativa, e non mi riferisco solo alle cariatidi del forum come il sottoscritto, ma nemmeno il ragazzino adolescente che ha sentito parlare oggi di hwupgrade e si è iscritto oggi al forum...

barzokk

27-10-2024, 11:33

Stop a nuovi indirizzi IPv4 dopo il 2035 e miliardi di ecoincentivi per IPv6.

Anche Hybrid IPv6 va bene
Quoto la proposta, è tutta colpa degli NO-ipv6, e della narrazione dei giornalisti italiani pagati dai venditori di switch ipv4.
In Norvegia ormai nessuno usa più gli ipv4

matsnake86

27-10-2024, 14:28

@Tasslehoff Complimenti. Finalmente qualcuno che parla con cognizione di causa :)

Uso un tunnel sul mio personale server di casa. Inutile ripetere tutti i vantaggi che tu hai già esposto benissimo.

Bello&Monello

27-10-2024, 15:49

Fino a che ipv6 resta fuori dalle mie reti sono contento.. basta che si usi ip4 dentro alle reti private e poi ipv6 può andare dove vuole.. è una rottura e costringe a cambiare switch che funzionano per switch che fanno la stessa cosa di prima..

Ma lunga vita a ipv6 .. se paga pantalone..

Scusa ma che cos'ha a che fare IPv6 con degli switch?!
Non c'è nessun motivo per cui dovresti sostituire un apparato L2 adottando IPv6...

Bello&Monello

27-10-2024, 15:51

Il NAT non è mica gratis, devi avere un dispositivo molto performante che si tenga un botto di NAT table in memoria quando con Ipv6 basta uno switch o un router "stupido".
Non ho capito cosa c'entra il TLS.

Per fare NAT NON serve un dispositivo performante.
Ci sono degli ASA di almeno 15 anni con centinaia di NAT in pancia e funzionano ancora benissimo. Figuriamoci qualsiasi dispositivo moderno...

Bello&Monello

27-10-2024, 15:52

E' già da diversi anni che questo non è più un problema.
L'esigenza di "nattare" un servizio su un ip pubblico non serve più d quando esistono le CDN e i servizi di ZTNA.

Ne sei davvero così sicuro?!? :sofico:

Bello&Monello

27-10-2024, 16:01

Non si tratta di creare o di inventarsi un protocollo nuovo, sempre si tratta di protocollo TCP/IP, è un modo diverso di esporre i servizi, molto più flessibile, molto più semplice e che permette di superare i limiti della classica pubblicazione basata su NAT (con tutte le sue rotture, nat, regole fw, dns) che in alcuni casi (es provider che non ti assegnano un ip pubblico perchè "nattano" a loro volta) non sono proprio utilizzabili.

Mah insomma, parliamone... stai mettendo a confronto una tecnologia standard come il NAT, disponibile su qualsiasi apparato di rete e quindi utilizzabile senza nessun vincolo, con un servizio fornito da un unico operatore.
Dire che è "molto più flessibile e molto più semplice" è tutto da vedere. Visto che probabilmente col NAT hai la flessibilità di ruotare anche i santi su qualsiasi porta tu voglia e su un numero pressochè infinito di indirizzi ip.

Notturnia

27-10-2024, 16:15

Io me la vedo mia mamma e tutti i genitori di quelli che sono su questo forum che installano un router e creano NAT e altri servizi.. magari anche un proxy..

E perchè non una VPN ?..

Chissà perchè IPv6 non prende pieve così velocemente :sofico:

Proprio non capisco :rolleyes:

destroyer85

27-10-2024, 16:52

Forse non sai cosa fa il NAT...
Facciamo l'esempio del NAT in uscita:
Prende l'header del pacchetto e sostituisce l'indirizzo IP sorgente locale e la porta con quello pubblico e una porta tra quelle non usate, ricalcola il checksum dell'header e dell'intero pacchetto, scrive nella tabella l'associazione ip di destinazione, porta, indirizzo locale porta, manda il pacchetto, arriva la risposta, stessa operazione di prima su IP porta e checksum e lo consegna all'indirizzo locale.
Questo, oltre a "costare" molta CPU e RAM che viene quindi sottratta a quella disponibile per le cose importanti tipo firewall o VPN, riduce il throughput del 17 %.
Altra cosa il routing esiste senza NAT, ma non puoi avere NAT senza routing.

Il routing è "stupido" e si può implementare in hardware.

Per quanto riguarda l'ADV dei servizi di cloudflare, state mischiando due cose che non c'entrano niente.
È semplicemente un firewall in cloud che si basa sempre su Ipv4, ipv6 routing e NAT. Non c'è niente di magico

barzokk

27-10-2024, 18:23

ok bravi tutti, però

Anche qui, Tailscale è un servizio di ZTNA completamente free che ti permette di creare una mesh di vpn basate su Wireguard in modo trasparente e senza dover contattare direttamente l'ip dell'interfaccia pubblica del router.

io guardo qui
https://tailscale.com/use-cases/remote-access
c'è l'opzione $0per active user/month, clicco su Get started free
e mi propone
Sign up with your identity provider (google, Microsoft, ecc)
You’ll use this provider to log in to your network (more)
e già mi girano i marroni :rolleyes:

E cosa succede quando domani non sarà più 0$, ma lo mettono a pagamento ?
E se invece voglio usare OpenVpn ?

Ma non è più facile il solito IP statico che ci vuole 1 minuto, e non dipendo da troppi operatori? :mbe:

marcram

27-10-2024, 18:43

Ma non è più facile il solito IP statico che ci vuole 1 minuto, e non dipendo da troppi operatori? :mbe:
Dipende...
Io preferisco usare un servizio tipo TailScale, o ZeroTier, piuttosto che avere un indirizzo fisso che possa essere preso di mira...

fraussantin

27-10-2024, 19:50

Il NAT come soluzione pratica senza alternativa è ciò che rende problematici alcuni operatori telefonici, per chi deve accedere alla propria rete dall'esterno.
Preferirei avere un indirizzo pubblico IPv6 che stare sotto NAT IPv4.

Ma il nat supporta in qualche modo l'upnp?

Tasslehoff

27-10-2024, 22:56

ok bravi tutti, però

io guardo qui
https://tailscale.com/use-cases/remote-access
c'è l'opzione $0per active user/month, clicco su Get started free
e mi propone
Sign up with your identity provider (google, Microsoft, ecc)
You’ll use this provider to log in to your network (more)
e già mi girano i marroni :rolleyes:

E cosa succede quando domani non sarà più 0$, ma lo mettono a pagamento ?
E se invece voglio usare OpenVpn ?
Hai 3 opzioni:

Fai fermare i maroni che girano, perchè francamente nell'anno di grazia 2024 gli integralismi sulle Bad Corp non hanno più senso, e non avere nemmeno un account GitHub probabilmente significa non aver mai avuto uno straccio di partecipazione in nessun progetto opensource, non aver mai aperto nemmeno una issue per segnalare un problema, insomma aver solo "preso" senza aver mai "dato" nulla alla community.
Dico probabilmente, ma la percentuale di progetti che stanno su GitHub è talmente alta che si potrebbe anche sostituire con "sicuramente".
Ti metti in piedi un IdP OpenID (es Authentik) e lo federi con Tailscale
L'unica componente non opensource (ma free) è l'interfaccia di amministrazione, puoi metterti in piedi la tua usando Headscale (https://github.com/juanfont/headscale)

Se domani lo mettono a pagamento valuti il costo, se per te è eccessivo usi Headscale, non cambia nulla tranne il fatto che devi hostare il tuo control server, e per quello ti serve un ip pubblico.

Se vuoi usare OpenVPN devi per forza avere un ip pubblico (non importa se statico o dinamico), se il tuo operatore ti mette dietro NAT ti attacchi al tram e urli in curva, e OpenVPN non lo puoi usare.

Ma non è più facile il solito IP statico che ci vuole 1 minuto, e non dipendo da troppi operatori? :mbe:Come ho ampiamente descritto, l'ip pubblico (non necessariamente statico, può anche essere dinamico e non è un problema) non tutti gli operatori ti permettono di averlo.

A prescindere da ciò usare l'esposizione dei servizi mediante NAT è più complessa, occorre mettere mano a:

regole firewall
tabella di nat
risoluzione dns

Usare un meccanismo di ZTNA tipo Cloudflare tunnel per fare lo stesso richiede

una operazione banale sul pannello di Cloudflare
l'esecuzione di un eseguibile passandogli il token generato da Cloudflare

Vantaggi:

nessun firewall su cui mettere le mani
nessun router su cui mettere le mani
nessun dns su cui mettere le mani
nessun dannato certificato TLS da generare/manutenere
totale indipendenza dal provider
superamento di tutte le limitazioni di hosting con i provider che ti piazzano dietro nat.

Se ti sembra poco...

Già a livello domestico i vantaggi sono enormi, a livello lavorativo sono stratosferici, significa migrazioni da un provider all'altro o da un server all'altro in tempo praticamente zero e senza interruzioni, zero perdite di tempo su fw, dns, nat.
Significa pubblicare servizi senza dover fare il giro delle 7 chiese: l'ufficio rete che ti apre le porte da DMZ a LAN, l'ufficio sicurezza che ti configura il tal reverse proxy che nessuno sa mai usare bene e su cui nessuno sa mai installare un dannato certificato https per fare da terminatore, significa totale isolamento delle applicazioni senza loro raggiungibilità se non dalla CDN attraverso un canale sicuro, significa fare in 10 minuti quello che normalmente nelle grandi organizzazioni richiede settimane di richieste, cartaccia, mail, riunioni, etc etc...

Tasslehoff

27-10-2024, 23:16

Ne sei davvero così sicuro?!? :sofico:Di fatto sì, nell'anno di grazia 2024, con il protocollo http che è diventato omnipresente e di fatto governa qualsiasi servizio esista, di fatto sì.

Poi tu puoi anche esporre un server ssh o LDAP o un listener Oracle con Cloudflare se proprio vuoi farti male.

Certo, ci sarà sempre il servizio di nicchia che gira solo su protocollo UDP o quello che rompe perchè deve nattare il client Bittorrent su UDP per scaricare qualche scemenza, ma non sono esempi significativi.

Di fatto da vent'anni (con l'introduzione dei web services) il protocollo http è diventato lo strumento di comunicazione standard per qualsiasi cosa, e http significa protocollo tcp, punto.

Mah insomma, parliamone... stai mettendo a confronto una tecnologia standard come il NAT, disponibile su qualsiasi apparato di rete e quindi utilizzabile senza nessun vincolo, con un servizio fornito da un unico operatore.
Dire che è "molto più flessibile e molto più semplice" è tutto da vedere. Visto che probabilmente col NAT hai la flessibilità di ruotare anche i santi su qualsiasi porta tu voglia e su un numero pressochè infinito di indirizzi ip.Non è da vedere, è un dato di fatto.

Domani devo pubblicare un servizio, se voglio farlo senza Cloudflare Tunnel devo:

Mandare una richiesta al centro operazioni rete per far configurare un nuovo vip su F5 per fare da reverse proxy
Mandare una richiesta al gruppo sicurezza rete per farmi aprire le porte dall'interfaccia di DMZ del vip F5 di cu sopra la cui interfaccia pubblica è nattata su un ip pubblico di un router
Mandare una richiesta al centro operazioni rete per far creare il record dns di turno per risolvere l'hostname con l'ip del vip F5
Mandare una richiesta al centro operazioni rete per richiede un certificato https, attendere lungaggini per l'acquisto o se sono fortunato attendere che qualche "mago" lo generi con Let's Encrypt su F5
Organizzare meeting per spiegare a ciascuno di questi perchè e percome occorre quello che è stato inserito nei ticket di cui sopra
Attendere settimane che ciascuno di questi gruppi faccia il proprio dovere (operazioni da 5 min che richiedono settimane di attesa)
Sperare che nessuno sbagli qualcosa e nel caso indire riunioni per far notare l'errore e correggere

Settimane per fare tutto questo, settimane buttate, fiumi di mail, richieste su ServiceNow, call e alla fine di questo calvario finalmente il servizio è pubblicato.

Con Cloudflare Tunnel?
10 minuti a esagerare, nessun gruppo da coinvolgere o a cui richiede ticket, aperture porte, regole fw, configurazione reverse proxy.
Nessun certificato https da richiedere, o da rinnovare, o da monitorare.
In più la protezione di una CDN con gli attributi, con un WAF che fa impallidire i ridicoli WAF enterprise (stile Imperva), riscritture configurabili via un pannello web based in tempo zero, protezione dei servizi con autenticazione form based e MFA o federazione SAML o OpenID prima del golive.

Perdonami ma non voglio ripetermi, ma i vantaggi sono talmente evidenti che non dovremmo nemmeno discuterne.

baruk

28-10-2024, 08:08

Stop a nuovi indirizzi IPv4 dopo il 2035 e miliardi di ecoincentivi per IPv6.

Anche Hybrid IPv6 va bene

:D :D :D io mi faccio subito la colonnina IPv6 in giardino :D :D

barzokk

28-10-2024, 08:13

Hai 3 opzioni:
Fai fermare i maroni che girano, perchè francamente nell'anno di grazia 2024 gli integralismi sulle Bad Corp non hanno più senso,

...
Premessa, l'unica persona di cui mi fido è mia mamma. E pure lei ogni tanto mi dà dei ceffoni.
Corollario: ogni Corp diversa dalla mia, è Bad.

Detto questo, mi sembra che quando ci si vuole collegare, bisogna confermare visitando un loro link.
https://cdn.sanity.io/images/w77i7m8x/production/eb75c43829a2d68a9d65417e350d4a8c913704fa-802x450.svg

E se io devo automatizzare il tutto, per es per collegare un ufficio periferico a quello centrale ?
Magari con dei client-server che si connettono e sconnettono di frequente, oppure se manca tensione e il collegamento salta ?
Si paga
Meh

gd350turbo

28-10-2024, 08:14

nessun firewall su cui mettere le mani
nessun router su cui mettere le mani
nessun dns su cui mettere le mani
nessun dannato certificato TLS da generare/manutenere
totale indipendenza dal provider
superamento di tutte le limitazioni di hosting con i provider che ti piazzano dietro nat.

Se ti sembra poco...

Ottimo davvero !

destroyer85

28-10-2024, 08:36

http3 usa UDP
il tunnel richiede l'installazione di un software, quindi funziona solo su sistemi dove il software è installabile
cloudflare, agendo sostanzialmente da proxy, vede in chiaro tutto il traffico che ci passa di mezzo
reputo stupido utilizzare il NAT con IPv4 quando con IPv6 si potrebbe fare semplicemente un routing figurati se vado a complicare ulteriormente la rete con un tunnel https su protocollo tcp che passa attraverso un reverse-proxy il tutto semplicemente per far passare dei pacchetti

La cosa che è veramente da superare è l'uso degli IP. Molti si sentono "più fighi" utilizzando gli IP invece dei nomi DNS non capendo che così mandano a rane un eventuale banale load balancing.
L'IPv6 in questo ci aiuta perché è impossibile da ricordare e io lo adotterei solo per questo motivo. (che è il motivo per cui molti lo odiano)

matsnake86

28-10-2024, 10:01

il tunnel richiede l'installazione di un software, quindi funziona solo su sistemi dove il software è installabile

Praticamente ovunque. Gira anche su un raspberry talmente è leggero.
Con l'immagine docker poi è talmente facile da risultare imbarazzante. Quando generi il tunnel ti danno già il comando da eseguire su podman o docker che sia.

cloudflare, agendo sostanzialmente da proxy, vede in chiaro tutto il traffico che ci passa di mezzo

Di qualcuno ti dovrai fidare. Che sia un hosting, il tuo isp, il sistema operativo... Nella catena del software ci sarà sempre qualcosa al di fuori del tuo controllo di cui dovrai semplicemente fidarti.

reputo stupido utilizzare il NAT con IPv4 quando con IPv6 si potrebbe fare semplicemente un routing figurati se vado a complicare ulteriormente la rete con un tunnel https su protocollo tcp che passa attraverso un reverse-proxy il tutto semplicemente per far passare dei pacchetti
La cosa che è veramente da superare è l'uso degli IP. Molti si sentono "più fighi" utilizzando gli IP invece dei nomi DNS non capendo che così mandano a rane un eventuale banale load balancing.
L'IPv6 in questo ci aiuta perché è impossibile da ricordare e io lo adotterei solo per questo motivo. (che è il motivo per cui molti lo odiano)

Su questo sono parzialmente d'accordo. Per me potrebbero proibire ipv4 dall'anno prossimo e sarei sostanzialmente contento.

Certo la comodità di un tunnel rimane intaccata.
Tutti i vantaggi che sono stati già spiegati non cambiano.

Pensa solo ad eventuali attacchi ddos. Con cloudflare in mezzo che ha le spalle grosse puoi dormire sostanzialmente tranquillo.

DjLode

28-10-2024, 10:13

Detto questo, mi sembra che quando ci si vuole collegare, bisogna confermare visitando un loro link.

Puoi usare anche le Authkeys, quindi puoi automatizzare il tutto.
La chiave può essere settata come "never expiry" e te ne puoi dimenticare.

destroyer85

28-10-2024, 12:02

Praticamente ovunque. Gira anche su un raspberry talmente è leggero.
Con l'immagine docker poi è talmente facile da risultare imbarazzante. Quando generi il tunnel ti danno già il comando da eseguire su podman o docker che sia.

Quindi anche un PBX proprietario, il dispositivo di allarme, il telecontrollo del riscaldamento...

Di qualcuno ti dovrai fidare. Che sia un hosting, il tuo isp, il sistema operativo... Nella catena del software ci sarà sempre qualcosa al di fuori del tuo controllo di cui dovrai semplicemente fidarti.

L'hosting non c'entra perché stiamo parlando di una soluzione per esporre app su host interni, l'ISP può vedere al massimo il traffico http e non l'https checché ne dicano NordVPNisti, e il sistema operativo... va beh su questo non ti rispondo neanche...

Su questo sono parzialmente d'accordo. Per me potrebbero proibire ipv4 dall'anno prossimo e sarei sostanzialmente contento.

Certo la comodità di un tunnel rimane intaccata.
Tutti i vantaggi che sono stati già spiegati non cambiano.

Pensa solo ad eventuali attacchi ddos. Con cloudflare in mezzo che ha le spalle grosse puoi dormire sostanzialmente tranquillo.
Ma infatti, e lo ripeto, state confondendo due cose NAT routing e questo servizio che apparentemente fanno la stessa cosa ma non sono la stessa cosa.

Bello&Monello

28-10-2024, 16:58

Di fatto sì, nell'anno di grazia 2024, con il protocollo http che è diventato omnipresente e di fatto governa qualsiasi servizio esista, di fatto sì.

Poi tu puoi anche esporre un server ssh o LDAP o un listener Oracle con Cloudflare se proprio vuoi farti male.

Certo, ci sarà sempre il servizio di nicchia che gira solo su protocollo UDP o quello che rompe perchè deve nattare il client Bittorrent su UDP per scaricare qualche scemenza, ma non sono esempi significativi.

Di fatto da vent'anni (con l'introduzione dei web services) il protocollo http è diventato lo strumento di comunicazione standard per qualsiasi cosa, e http significa protocollo tcp, punto.

Non è da vedere, è un dato di fatto.

Domani devo pubblicare un servizio, se voglio farlo senza Cloudflare Tunnel devo:

Mandare una richiesta al centro operazioni rete per far configurare un nuovo vip su F5 per fare da reverse proxy
Mandare una richiesta al gruppo sicurezza rete per farmi aprire le porte dall'interfaccia di DMZ del vip F5 di cu sopra la cui interfaccia pubblica è nattata su un ip pubblico di un router
Mandare una richiesta al centro operazioni rete per far creare il record dns di turno per risolvere l'hostname con l'ip del vip F5
Mandare una richiesta al centro operazioni rete per richiede un certificato https, attendere lungaggini per l'acquisto o se sono fortunato attendere che qualche "mago" lo generi con Let's Encrypt su F5
Organizzare meeting per spiegare a ciascuno di questi perchè e percome occorre quello che è stato inserito nei ticket di cui sopra
Attendere settimane che ciascuno di questi gruppi faccia il proprio dovere (operazioni da 5 min che richiedono settimane di attesa)
Sperare che nessuno sbagli qualcosa e nel caso indire riunioni per far notare l'errore e correggere

Settimane per fare tutto questo, settimane buttate, fiumi di mail, richieste su ServiceNow, call e alla fine di questo calvario finalmente il servizio è pubblicato.

Con Cloudflare Tunnel?
10 minuti a esagerare, nessun gruppo da coinvolgere o a cui richiede ticket, aperture porte, regole fw, configurazione reverse proxy.
Nessun certificato https da richiedere, o da rinnovare, o da monitorare.
In più la protezione di una CDN con gli attributi, con un WAF che fa impallidire i ridicoli WAF enterprise (stile Imperva), riscritture configurabili via un pannello web based in tempo zero, protezione dei servizi con autenticazione form based e MFA o federazione SAML o OpenID prima del golive.

Perdonami ma non voglio ripetermi, ma i vantaggi sono talmente evidenti che non dovremmo nemmeno discuterne.

Perdonami ma mi sembra che tu stia andando a prendere degli esempi un po' "forzati" col solo scopo di dare supporto alla tua tesi.

Non sto dicendo che sia sbagliato quello che dici, ma fai esempi in infrastrutture parecchio burocratizzate come potrebbe essere un carrier o una grossa multinazionale.

Per fortuna non è sempre così. E non sempre devi per forza usare un F5.

Puoi anche avere clienti che lavorano in ambienti virtualizzati (ad esempio un VDC su un cluster NSX-T) che hanno davanti al loro ambiente un firewall che è collegato direttamente alla pubblica e su quel firewall gestisci comodamente i NAT.

Che con l'hardware di oggi non sono dispendioni in termini di CPU e RAM. Per nulla.

Tasslehoff

28-10-2024, 23:27

Perdonami ma mi sembra che tu stia andando a prendere degli esempi un po' "forzati" col solo scopo di dare supporto alla tua tesi.

Non sto dicendo che sia sbagliato quello che dici, ma fai esempi in infrastrutture parecchio burocratizzate come potrebbe essere un carrier o una grossa multinazionale.

Per fortuna non è sempre così. E non sempre devi per forza usare un F5.

Puoi anche avere clienti che lavorano in ambienti virtualizzati (ad esempio un VDC su un cluster NSX-T) che hanno davanti al loro ambiente un firewall che è collegato direttamente alla pubblica e su quel firewall gestisci comodamente i NAT.

Che con l'hardware di oggi non sono dispendioni in termini di CPU e RAM. Per nulla.No, chiaro che ho fatto un esempio estremo, però è per dire che usare una cosa del genere per l'esposizione di un servizio permette di risparmiare un sacco di tempo, un sacco di rogne e di concentrarsi su quello che è strategico, ovvero il servizio, non tutto il cucuzzaro di roba che ci sta attorno.

Non voglio passare per il PM di turno che parla per supercazzole, ma se io devo pubblicare un servizio mi interessa quello, firewall, appliance di sicurezza, nat, dns sono solo perdite di tempo, richiedono risorse specifiche, dispositivi specifici e quindi costi maggiori.

Ti faccio un esempio molto banale, se io sono una PMI e ho il classico rack nell'antibagno, mi basta avere connettività in outbound tale e quale a quella che ha chiunque di noi a casa (anche senza ip pubblico e dietro nat del provider in stile Iliad), e usando Cloudflare tunnel posso hostare servizi a piacimento senza bisogno di prendermi una appliance perimentrale, senza bisogno di qualcuno che la sappia configurare e metterci le mani, mi libero di tutte queste cose e mi concentro su quello che mi serve: pubblicare i miei servizi.

Mi libero perfino dell'onere di gestire i certificati https guarda, lo fa in automatico Cloudflare con la sua CDN.

Altro esempio (che mi è capitato non più di 6 mesi fa): migrazione di vm da Vmware presso un provider ignobile a Proxmox hostato su host baremetal da Hetzner.

migrato l'esposizione di tutti i servizi da configurazione classica con reverse proxy + nat (AS + reverse proxy Apache o Nginx, o Ingress Controller Nginx su K8s + reverse proxy Apache o Nginx di frontend) a Cloudflare Tunnel (bloccando nel frattempo l'accesso alle applicazioni in LAN, non serve --> maggiore sicurezza)
setup vpn site-to-site tra vecchio site con Vmware e nuovo su Hetzner
migrato le vm da Vmware a Proxmox
accese le vm e riconfigurato la rete affinchè potessero raggiungere i nuovi dns e default gateway della rete su Proxmox

FINE, tutti i servizi online dall'istante in cui le vm nuove hanno potuto fare traffico in outbound e cloudflared ha ripreso a contattare la CDN Cloudflare.

La migrazione più indolore che abbia mai affrontato, letteralmente la pace dei sensi, e sfido chiunque a fare qualcosa del genere in modo così indolore.

E se dovessi migrare ancora? Stop, sposto le vm, le rimetto in rete e tutto funziona sul nuovo site.

Capisci cosa voglio dire? E' un approccio talmente flessibile e che permette di tagliare tempi e costi in modo tale da far sembrare letteralmente preistorica la pubblicazione di servizi via nat + reverse proxy + risoluzione dns.

E la facilità con cui si può fare è mostruosa.

Puoi letteralmente pubblicare servizi da un container che gira sul tuo pc in tempo zero, fare una demo con hostname pubblici, certificati https e tutto quello che può avere un servizio in produzione in 5 minuti, letteralmente.

gsorrentino

29-10-2024, 16:57

Di qualcuno ti dovrai fidare. Che sia un hosting, il tuo isp, il sistema operativo... Nella catena del software ci sarà sempre qualcosa al di fuori del tuo controllo di cui dovrai semplicemente fidarti.

Appunto. Se ho un IP pubblico mi fido solo del sistema operativo.

Nel caso citato mi fido (molto ma molto) pure di altra società che legge il mio traffico...

Non voglio passare per il PM di turno che parla per supercazzole, ma se io devo pubblicare un servizio mi interessa quello, firewall, appliance di sicurezza, nat, dns sono solo perdite di tempo, richiedono risorse specifiche, dispositivi specifici e quindi costi maggiori.

Ti faccio un esempio molto banale, se io sono una PMI e ho il classico rack nell'antibagno,
........

mi libero di tutte queste cose e mi concentro su quello che mi serve: pubblicare i miei servizi.

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.

Altro esempio (che mi è capitato non più di 6 mesi fa): migrazione di vm da Vmware presso un provider ignobile a Proxmox hostato su host baremetal da Hetzner.

........

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

gsorrentino

29-10-2024, 17:05

Dipende...
Io preferisco usare un servizio tipo TailScale, o ZeroTier, piuttosto che avere un indirizzo fisso che possa essere preso di mira...

Mi sembrano una specie di Hamachi evoluto e (troppo) semplificato o sbaglio?

Tasslehoff

29-10-2024, 18:49

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

31-10-2024, 15:11

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

31-10-2024, 16:08

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

22-11-2024, 12:18

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

22-11-2024, 22:57

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.

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.

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.

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.

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

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

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.

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.

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.

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

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

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

10-02-2025, 17:44

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